Synchronous Messaging

[amsmota]

Hi all:

I just started testing SI, and never worked with any other Spring modules before. First, my congratulations to the developers, I'm normally very suspicious about everything that has "framework" on it's name (they tend to be bloated, over-complex and tend to hide things that shouldn't be hidden). Until now I didn't find any of these pitfalls with SI.

Until now (one day and a half!) my tests went very well and I'm about to recommend the use of SI over other similar "frameworks".

The only thing I didn't catch in my tests until now is the way to do "synchronous messages", or at least to force a process to wait for a response to a previous sent message.

Basically, what I have now is a "adapter" (http for now, i.e. a servlet, to be extended to other adaptor protocols), that invoke a "resource" that dispatch messages to "services" that finally put some "responses" back in a queue.

All this is working ok asynchronously, but now I wanted a way for my servlet to wait for the "service" response.

What's the best way to do this?

Thanks for your help.

[Mark Fisher]

The feature you are describing is currently in-progress: http://jira.springframework.org/browse/INT-86

This will be included in the Milestone 2 release (next week). However, the first cut should be available in SVN later today if you would like to try it out.

-Mark

[amsmota]

Hi. Thanks for that. I will check it.

If you think I can be of assistance, either testing or developing it, please let me know.

Cheers.

[amsmota]

Actually, if I do just

responseChannel.doReceive(-1).getPayload()

wouldn't I get a synchronous response?

[Mark Fisher]

That's the general idea

My plan is to also implement the MessageHandler interface. So, it would be something like this:

MessageHandler handler = new SynchronousHandler(channelToSendTo);
Message reply = handler.handle(messageToSend);

(internally, that would set the replyChannel and then wait for a response)
Also, the timeouts could be set...
handler.setSendTimeout(..)
handler.setReceiveTimeout(..)

How does that look?

-Mark

[amsmota]

But that will take care of "temporary replyChannel" only, right? How about "shared channel with correlationId"? That can not be dealt with a BloquingQueue, meaning you have to make major changes in SimpleChannel or write another type of channel.

And that second access is very important for not having response messages waiting for other tasks to finish.

I'm going to do some more testing.

Cheers.

[Mark Fisher]

Even a shared channel can still be based on the BlockingQueue internally, the synchronous handler would simply receive in a loop. When a message arrives, it will check the correlationId and return to the correct caller (still likely using individual SynchronousQueues to block each caller). The main advantage I see with the shared channel approach is the ability to use interceptors, set a capacity, etc. Are there any other ideas or use-cases that you can foresee here?

Thanks,
-Mark

[amsmota]

Well, for our situation we're going to need at least some way of doing prioritization of messages, auditing and persistence.

Persistence will only be needed on a future instalment (the first will be intra vm only and will need no persistence). And probably will rely on JMS and transactional support that I see you already working on.

Auditing will probably be doable with interceptors/filters.

Prioritizing messages, however, and as I see it now, will probably need some sort of unsynchronized, non-blocking queue, like a PriorityQueue.

Please note that I'm not a expert on these issues, so I can probably be wrong on this.

Once you have something on SVN please let me know, I can probably develop something on it to test my use cases.

Cheers.

[Mark Fisher]

There is a PriorityBlockingQueue - the main difference (other than prioritization) is that it is unbounded whereas the current "SimpleChannel" allows configuration of a capacity. A priority-based channel is definitely going to be a necessary addition, but I think the queue will need to be wrapped and combined with a semaphore so that capacity can be limited. We don't want the limit to be enforced by OutOfMemoryExceptions

-Mark

[amsmota]

But a PriorityBlockingQueue is synchronized and blocking. In my first tests (without using SI yet) I hadn't be able to correctly implement priority *and* synchronous messages using synchronized, blocking queues.

I'll try to put up a simple case scenario tomorrow and test it again.

Thanks for your prompt replies.