On Thursday, November 10, 2011 4:39:22 PM Jesse Pangburn wrote:
> Hi Dan,
> So I've read over this more and now see that the partial response stuff is
> definitely for asynchronous processing, so the check with the WS-Addressing
> relatesTo header makes sense. The problem (I think) appears in your
> checkin revision 705446 for ClientImpl.java in this section: synchronized
> (message.getExchange()) {
> if (!isPartialResponse(message) && callback == null) {
> message.getExchange().put(FINISHED, Boolean.TRUE);
> message.getExchange().setInMessage(message);
> message.getExchange().notifyAll();
> }
> }
>
> You added the "&& callback == null" test, but I think what is needed is "||
> callback == null". The idea here (again, as I'm reading it) is regarding
> these two cases: - it's an asynchronous response which is not a partial
> response
> - there is no callback, meaning it's a synchronous response
>
> In either of these cases you want to tell the exchange that it's finished
> and the message you just got is the inbound message. I think this worked
> for a long time without anyone running into this because in the synchronous
> case (callback == null), the only way you get a partialResponse==true is
> when WS-Addressing is engaged AND the server that you're connecting to
> doesn't return the optional (but almost always used) relatesTo header.
> Probably in the vast majority of cases either WS-Addressing isn't used or
> the relatesTo header is present in a response.
>
> If you agree, I can create a defect and describe this. Since the change is
> just && to ||, obviously it won't help to send you a patch file :-)
That SOUNDS likely from the description, but I'd definitely need to run all
the tests and such again to make sure. Can you file a JIRA with all this so
I don't forget about it and to make sure it's tracked?
Thanks!
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
