Design options for throttling the sending of xml messages
I have 4 different xml message types that I must post to a service. 3 of these message types can be sent asynchronously but 1 must be sent synchronously:
These types can be sent asynchronously:
Create
Update
Delete
This type must be sent synchronously:
Retrieve
Now the problem is I must throttle the sending of these messages because I am only allowed to send x create/update/delete messages a second and y retrieve messages a second (where y > x).
Options I can think of are:
Some kind of jms queue where the queue subscriber throttles the number of messages sent by only taking that number off the queue. I would have 1 queue for create/update/delete messages and 1 queue for retrieve messages.
Writing the xml to physical files and having a process poll the directories at set intervals to throttle the sending. I would have an outbound/inbound directory for create/update/delete messages and an outbound/inbound directory for retrieve messages.
Using some kind of cache.
Using a database.
But one big thing I have to consider is the order the messages are sent. For example if a client sends a delete, create and then a retrieve to me for the same account these need to be processed in the correct order, otherwise the retrieve may return the information that should have been deleted and not the new information that should have been created (if you can see my problem). So I don't know if I must somehow group these messages by account number.
[1539 byte] By [
jakain2a] at [2007-11-26 18:10:05]
# 1
> Writing the xml to physical files and having a
> process poll the directories at set intervals to
> throttle the sending. I would have an
> outbound/inbound directory for create/update/delete
> messages and an outbound/inbound directory for
> retrieve messages.
>
> Using some kind of cache.
>
> Using a database.
I'm not sure how using a cache or using a DB solves the problem. I'm going to guess that these values are low enough to allow one thread to maximize the throughput to the throttled setting.
The most straight forward way that I can think to do this is to use a queue listener with a single long to hold a time and a counter variable. Then as each message is processed, you do the following:
set a local variable to the current time minus the last saved time
if the current time minus the last saved time is less than a second:
if the counter is less that the limit: send a message, increment counter
else: sleep for the balance of the second
else
divide the time since the last send by 1 second (i.e. 1000) and do not retain
the remainder and add this to the last saved time
send message, set counter to 1
> But one big thing I have to consider is the order the
> messages are sent. For example if a client sends a
> delete, create and then a retrieve to me for the same
> account these need to be processed in the correct
> order, otherwise the retrieve may return the
> information that should have been deleted and not the
> new information that should have been created (if you
> can see my problem). So I don't know if I must
> somehow group these messages by account number.
The best way to approach this, I think, is to have a transaction ID and sequence number on the messages. If you process a message out of sequence for a transaction, you can delay it until the previous messages are processed.
But really, you are going to have to think about this design a little. What happens when two clients are making changes to an account simutaneously? What happens when the asynchronous requests are delayed and hold up the synchronous requests. Whoever is making these requirements should have considered and addressed these issues.
