Architecture advice about managing UDP calls

I would like to have an advice for this issue: I am using Jbos 5.1.0, EJB3.0

I have system, which sending requests via UDP'S to remote modems, and suppose to wait for an answer from the target modem. the remote modems support only UDP calls, therefor I o design asynchronous mechanism. (also coz I want to request X modems parallel)

this is what I try to do:

all calls are retrieved from Data Base, then each call will be added as a message to JMS QUE. let's say i will set X MDB'S on that que, so I can work asyn开发者_Python百科chronous. now each MDB will send UDP request to the IP-address(remote modem) which will be parsed from the que message.

so basicly each MDB, which takes a message is sending a udp request to the remote modem and [b]waiting [/b]for an answer from that modem.

[u]now here is the BUG:[/u]

could happen a scenario where MDB will get an answer, but not from the right modem( which it requested in first place).

that bad scenario cause two wrong things:

a. the sender which sent the message will wait forever since the message never returned to him(it got accepted by another MDB). b. the MDB which received the message is not the right one, and probablly if it was on a "listener" mode, then it supposed to wait for an answer from diffrent sender.(else it wouldnt get any messages)

so ofcourse I can handle everything with a RETRY mechanisem. so both mdb's(the one who got message from the wrong sender, and the one who never got the answer) will try again, to do thire operation with a hope that next time it will success.

This is the mechanism, mybe you could tell me if there is any design pattren, or any other effective solution for this problem?

Thanks,

ray.

It's tough to define an exacting solution without knowing the details, but I will assume that when a response is received from a modem (either the correct one or not), it is possible to determine which exact modem the request came from.

If this is the case, I would separate out the request handler from the response handler:

• RequestMDB receives a message from the [existing] queue, dispatches the request and returns.
• A new component (call it the ResponseHandler) handles all incoming responses from the modems. The response sender is identified (a modem ID ?) and packages the response into a JMS message which is sent to a JMS Response Queue.
• A new MDB (ResponseMDB) listens on the JMS Response Queue and processes the response for which the modem ID is now known.

In short, by separating concerns, you remove the need for the response processing MDB to only be able to process responses from a specific modem and can now process any response that is queued by the ResponseHandler.

The ResponseHandler (listening for responses from the modems) would need to be a multithreaded service. You could implement this as a JBoss ServiceMBean with some sort of ThreadPool support. It will need a reference to the JMS QueueConnectionFactory and the JMS response queue.

In order to handle request timeouts, I propose you create a scheduled task, one for each modem, named after the modem ID. When a request is sent, the task is scheduled for execution after a delay of the timeout period. When a response is received by the ResponseHandler, the ResponseHandler queues the response and then cancels the named task. If the timeout period elapsed without a cancellation, the scheduled task executes and queues another request (an reschedules the timeout task).

Easier said than done, I suppose, but I hope this helps.

//Nicholas