Externalization evolution of a non-version serialiation form

[adrian.brock]

So AcknowledgeRequestMsg is externalized with no version.

Which means I can't just add a boolean flag to the message without potentially
corrupting the stream.
The boolean is to say whether the message requires a reply.

Unless somebody knows a way to do this (or can think of something clever :-),
I'm going to have to send replies to NACKs all the time (to support old clients)
even though new clients just ignore it:

ServerSocketManagerHandler

 case m_acknowledge:
 AcknowledgementRequestMsg ackmsg = (AcknowledgementRequestMsg) msg;
 AcknowledgementRequest ack = ackmsg.getAck();
 server.acknowledge(connectionToken, ack);
 // We send the reply although on newer clients it is ignored.
 socketMgr.sendReply(msg);
 break;

UILClientILService:

 case m_acknowledge:
 // We have to ignore NACK replies because of backwards compatibility
 break;

I would have preferred to do something like:

 if (msg.isOneWay() == false)
 socketMgr.sendReply(msg);

With newer clients setting "OneWay" to true on the original send of the message.

[starksm64]

I went through this excercise with the pooled invoker. The approach I used is described here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=66365

It relies on specific behavior in the rmi remoting layer, that the pooled invoker actually broke by trying to override the objectinputstream/objectoutputstream to avoid writing the class description that is required for the rmi layer to understand the object boundaries.

[adrian.brock]

So you just catch the two types of exceptons and ignore?
I looked at those exceptions and methods, but didn't see it documentated
that that is how it worked? Are you sure it isn't Sun specific?
i.e an undocumented feature ;-)

[starksm64]

The problem is the rmi wire protocol and behavior around it although documented in the rmi spec, its not adequately defined and consistently implemented according to stuff I have read about others trying to implement it, so interop with rmi implementations other than Sun are likely to be suspect.

[adrian.brock]

This isn't RMI anyway. It is plain sockets with Object[Input/Output]Stream

[adrian.brock]

I think I'll just stick with sending the redundant reply.

[starksm64]

Yes, the reliance is just on the java object serialization details. I was lumping this spec into RMI.