Hi Gerald
Has anyone successfully used JMSSender for one-way messages?
My set-up is really simple:
-----------------------
<proxy name="proxy" transports="http">
<target endpoint="jms_endpoint" />
<wsdl key="wsdl_with_one_way_op" />
</proxy>
-----------------------
The only special thing is that the operation defined in the WSDL and
invoked by the client is one-way (an in-only MEP).
The problem here is that you do not define to Synapse which operation to
invoke with the WSDL, or if its IN only or IN-OUT. I guess we could
specify this within the endpoint definition, or maybe even set the
replyTo header to none to indicate that the message is not expecting a
reply?
I experience that a one-way message (to an in-only MEP) that is sent
to a JMS destination via JMSSender causes JMSSender to wait for a
response message on a reply
queue. Of course this does not make sense, and indeed the blocking JMS
receive of that reply message ultimately times out with this error:
-----------------------
DEBUG [13 Mar 20:33:13] JMSSender - JMSSender invoke()
DEBUG [13 Mar 20:33:13] JMSSender - [Client]Sending message to
destination : TOPIC.T_INT_CLIENT_EVT
DEBUG [13 Mar 20:33:13] JMSSender - Waiting for a maximum of 30000ms
for a response message to destination : QUEUE.JMS_TQ3
WARN [13 Mar 20:33:43] JMSSender - Did not receive a JMS response
within 30000 ms to destination : TOPIC.T_INT_CLIENT_EVT
-----------------------
Very briefly looking at the code for
org.apache.axis2.transport.jms.JMSSender in the trunk it indeed seems
that JMSSender sets the flag "waitForResponse" to true regardless of
whether the messages is one-way (to an in-only MEP) or not.
Can anybody confirm my understanding of the behaviour of JMSSender?
Yes, you are correct. It is time we updated the JMS transport with the
current open issues.
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
