Problem with datatype=invocation in the socket connector MBe

[reverbel]

I have an MBean that depends on one or more connectors:

<mbean code="org.jboss.tm.remoting.server.DistributedTransactionManager"
 name="jboss:service=DistributedTransactionManager">
 <depends-list optional-attribute-name="Connectors">
 <depends-list-element>jboss.remoting:service=Connector,transport=socket</depends-list-element>
 </depends-list>
</mbean>

In its startService method, the MBean issues addInvocationHandler calls to add a new invocation handler (for the "DTM" subsystem) to each of those connectors. However, the DTM subsystem does not use the unified invoker marshaller, which is specified by the "datatype=invocation" parameter appended to the invoker locator URI of the connector MBean for the socket transport:

<!-- excerpt from jboss-service.xml -->
<mbean code="org.jboss.remoting.transport.Connector"
 xmbean-dd="org/jboss/remoting/transport/Connector.xml"
 name="jboss.remoting:service=Connector,transport=socket"
 display-name="Socket transport Connector">

 <attribute name="InvokerLocator">[CDATA[socket://localhost:4446/?datatype=invocation]]</attribute>

 <attribute name="Configuration">
 <handlers>
 <handler subsystem="invoker">jboss:service=invoker,type=unified</handler>
 </handlers>
 </attribute>
 <depends>jboss.remoting:service=NetworkRegistry</depends>
</mbean>

The problem is that the return value of connector.getLocator() does not make sense for the DTM subsystem, as it includes the "datatype=invocation" parameter. Everything works fine if I remove the "datatype=invocation" part of the locator.

Should it be possible to use a single connector for multiple subsystems, each with its own marshaller? In that case, perhaps the "datatype=xxx" parameter could be added by the client side (which must specify the subsystem it wants to interact with anyway), rather than being kept in a global attribute of the connector MBean. In the case of the unified invoker, the client-side proxy could specify "datatype=invocation".

Or perhaps I should simply add another socket connector MBean (without the "datatype=xxx") just for myself? I noticed that Bill did that for AOP remoting. Adding another connector defeats the idea of having one connector per transport, though. One connector per transport (and multiple subsystems per connector) sounds like a good thing to me.

[reverbel]

Noticed that not only my own code works fine with no "datatype=invocation" parameter in the socket connector MBean, but EJB testcases work too. To me this was surprising, as those testcases perform EJB calls through the unified invoker. (Maybe EJB calls work with no "datatype=invocation" because UnifiedInvokerProxy.init explicitly sets the invocation marshaller?) Anyway, by now I have just removed the "datatype=invocation" parameter from the locator URI in the socket connector MBean.

Francisco

[tom.elrod]

There are a couple of issues here (I am actually working through a few of them currently due to a bug submitted recently). As it is now a Connector can have one and only one invoker, but can have multiple handlers.

The invoker has to have its marshaller/unmarshaller explicitly set for it (either via datatype=XXX in the locator url or by using its default one) when it starts. This is because the unmarshaller will be the one that is actually reading from the server invoker's transport's input stream (so no way to bind this dynamically based on client's preference as is no way to establish the initial handshake between client and server). This means that there is an associated constraint that all users of the Connector (and thus the associated server invoker) will have to use the same marshaller/unmarshaller.

The reason that the EJBs using the unified invoker work without the datatype=invocation, as you have noted, is because I have explicitly hardcode the adding of the InvocationMarshaller/InvocationUnmarshaller in the UnifiedInvokerProxy and UnifiedInvoker. This was a hack, because at the time, I had no way to dynamically load marshallers. I have added this feature to remoting (explanation at http://www.jboss.org/wiki/Wiki.jsp?page=Remoting_Marshaller_Configuration), but have not made the fix to the UnifiedInvokerProxy and UnifiedInvoker. When I do make the fix (jira issue JBREM-62), I will need the datatype=invocation back in the locator (plus a few other parameters).

So for now, probably best to define a new connector for the DTM. Another fix I can make pretty quickly is to update the InvocationMarshaller/InvocationUnMarshaller is to allow default marshalling behavior if is not of type org.jboss.Invocation (the EJB payload type). In essence, would mean any other users besides the ejb users, would see the exact same behavior as the SerializableMarshaller/SerializableUnMarshaller.

I will be thinking about better long term solution for this problem (where can bind marshallers/unmarshaller dynamically).

[tom.elrod]

Have made the change so InvocationMarshaller/InvocationUnMarshaller will support standard (non org.jboss.Invocation) payloads. So should be able to use the datatype=invocation for any Serializable payloads (see jira issue JBREM-83).

[reverbel]

Hey Tom, that was pretty quick. Thanks a lot.

Regards,

Francisco