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