You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by Matthew Lovett <ML...@uk.ibm.com> on 2007/02/02 20:30:49 UTC
Message serialization changes committed
Hi all,
I've just dropped in the message serialization changes (r502698). The
final checkin is a bit larger than I planned, so I thought I'd better send
in this note to explain a few things.
There is currently a bit of a bug, where the sync reply channel for
application messages gets marked with a HTTP 202 instead of a 200. That
means that the requestor code ignores the data that we put into the http
response, and we have to get the message via polling or retransmission.
You could argue that this a neat demonstration of RM working, since the
retransmissions get us there! If you run the new testcase with tcpmon in
the way you will see what I mean.
Along the way I found quite a few bugs in the sync-2-way with RM 1.0 code.
Essentially, if the first channel fails, the retransmissions we not quite
working right. The message would be redelivered, but it would never stop!
Fixing all those led to some cascading changes, which is why the patch
grew.
- I changed the code so that we return an Ack message if we get sent
duplicate messages (as this seems like a helpful thing to do)
- Made sure that we clean up the retransmitter beans when we have got the
response we were looking for
- Check if the outbound sequence can be terminated, if the only reason it
was there was to keep trying for the replies
- I also fixed up the SequenceReports so that they correctly report the
ack status, even when we are restransmitting messages in order to get the
response.
To make the return-and-ack for duplicate messages work I moved the
duplicate detection into the SequenceProcessor, as we need access to the
AxisService in order to build and send the Ack. That actually cleans
things up, as we used to have a narrow timing gap between the
GlobalInHandler and the SandeshaInHandler, and ended up checking in both
places anyway.
Finally there was a daft bug in the RMDBean, and you really don't want to
know how long that took to find!
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org