Hi Seumas,
I'm sorry to reply your mail so late, please check out my comments in
the mail.
Seumas Soltysik wrote:
There are a couple of elements in the JMSConduit code on the trunk
that are troublesome.
First of all there is the use of the outstandingAsync data member.
Effectively it keeps track of outstanding async calls. If the number
of outstanding async calls is 0 then it proceeds to shutdown the asyn
JMSListener. So if a client were to make a series of async call that
did not overlap, each call would result in the creation and
destruction of the JMSListener which seems a bit excessive. I am not
sure why this counter was introduced but I think it may have to do
with trying to avoid conflicts with the jmsTemplate.receiveSelected()
call for synchronous invocations. I think the idea was to try to
avoid having two listeners open that might interfere with each other
if an async and sync call were made consecutively. Just a guess.
I think we can try to stop the JmsListenerContainer instead shutdown it,
as creating the JmsListenerContainer takes lots time and resource.
BTW, cxf trunk share this same code with cxf 2.2.x and cxf 2.1.x.
The other issue relates to when the MessageID is used as the
CorrelationID. The following code determines whether the MessageID
will be used or not: } else if
(!jmsConfig.isSetConduitSelectorPrefix() && (exchange.isSynchronous()
|| exchange.isOneWay()) && (!jmsConfig.isSetUseConduitIdSelector() ||
!jmsConfig.isUseConduitIdSelector())) { messageIdPattern = true; }
It turns out that with absolutely no client config set,
messageIdPattern resolves to true. This means that the default case
is to use the MessageID as the CorrelationID as opposed to a
generated CorrelationID. I am not sure that this is a bad thing but I
am just checking whether it is intentional or not.
Yes, You are right.
I just recalled why we set the CorrelationID with the value of MessageID
by default after have a quick look at the SOAP/JMS specification[1].
To ensure we still support CXF 2.1.x, and 2.2.x configuration, we uses
lots if here.
[1]http://www.w3.org/TR/soapjms/
This may have been on purpose because as a result of this logic, most
of the time jmsTemplate.receiveSelected() is using the messageID in
the selection string. This ensures that if a JMSListener is active
because of an ongoing async call, the JMSListener which is looking
for a JMS messages with a specific prefix, will not grab the message
away from the JMSTemplate receiving thread. However, in the event
that the JMSTemplate is using a message selector based upon the
conduit ID and there is a JMSListener active, that the listener could
grab the returning message first.
At this point it all "works" but it does seem a bit convoluted. To
ensure that there is no conflict between the two listeners, I think
that the MessageID should always be used as the CorrelationID except
when the user specifies a correlation ID and with async calls. This
assumes that MessageIDs are truly unique.
+1 for this.
Willem
