How to read from a message-driven-channel-adapter

[w2m]

Hi Again,

I made all the changes and the code is working half way. With the gateway, I can send a message and the server picks it up and generates a reply. However, the gateway never picks up the reply and instead times out. I increased the receive-timeout but that had no impact. In fact, after several attempts, the reply queue had several messages in it so the gateway would not have had to wait at all to pick the first one off the queue.

Here is the relevant code:

<gateway id="authenticationGateway" service-interface="com.xyz.MyAuthenticationGateway" default-request-channel="toMarshaller"	/>

<channel id="toMarshaller"/>
	
<transformer id="object-to-xml" ref="marshaller" input-channel="toMarshaller" method="marshal" output-channel="jmsoutputchannel"/>	    
	
<channel id="jmsoutputchannel" />
	
<jms:outbound-gateway request-channel="jmsoutputchannel" request-destination="requestJmsQueue" 
	                      reply-channel="toUnmarshaller"     reply-destination="replyJmsQueue"/>
	
<channel id="toUnmarshaller" />
	
<transformer id="xml-to-object" ref="marshaller" input-channel="toUnmarshaller"  method="unmarshal" />

Notice that I used transformer elements as opposed to marshalling-transformer, etc. The former I was already using on the server and the latter I did not know how to configure.

Also, autowiring the gateway did not work, I had to use getBean on the application context.

Do you have any suggestions as to what I should try?

Thanks!

[Gary Russell]

How does your server correlate a reply to a request?

When the reply arrives, the gateway needs to know which outbound message to correlate the response to.

If you use an inbound-gateway on the server, this will all be taken care of for you. If you are using disjoint adapters on the server (like you were trying to do on the client), you need to provide correlation information by giving the outbound gateway a correlation key.

The easiest thing to do would be to look at using an inbound-gateway on the server.

In any case, DEBUG logs are your friend; they provide lots of information.

[w2m]

Disjoint adapters are being used on the server.

To replace these with an inbound gateway, would I use the same approach to configuring it as I used with the outbound gateway? Is there a need to define a service-interface as was done with the outbound gateway?

On the server the same two transformers are used and are connected to a service activator. Would this piece have to change? I don't have the existing code at hand to show you.

I imagine that the new code would be the complement of the code that I listed in my previous post (#11) except as follows: The outbound-gateway becomes an inbound-gateway, the gateway with the service-interface attribute is replaced with the service activator and the input-channel and output-channel of both transformers are fully connected.

Does this seem correct?

[Gary Russell]

Yes, the configuration would be a complement of the client...

inbound-gateway->unmarshaller->service-activator->marshaller

1. No output-channel on the marshaller, SI will automatically route the output to the gateway
2. No reply destination required on the inbound gateway (the oubound gateway puts the reply-destination in the JMS replyTo header). There is a default-reply-destination attribute for messages that don't have a replyTo header.
3. No need to define any service-interface

There is another timeout you need to worry about - this time, the default timeout of the inbound gateway is 1 second.

To summarize, there are 3 timeouts involved...

1. Timeout on programmatic gateway (interface); default infinity.
2. Timeout on outbound gateway; default 5 seconds for JMS.
3. Timeout on inbound gateway; default 1 second for JMS (actually, all inbound-gateways).

These need to be set to appropriate values for your application.

[w2m]

Beautiful. I followed your steps and everything worked the first time! You gave a number of insights that were essential to solving the problem but perhaps the most important key was in your post #12 about correlating requests with replies. So, besides working code, you've given me much food for thought! Thanks so very much for all your help.