2 Replies Latest reply on Mar 31, 2006 9:00 AM by timfox

    Uisng the HTTP Remoting Transport Connector with Messagaing

    apwalker Mar 30, 2006 7:39 AM

      There are currently two main issues with using the HTTP.

      The firstly issue is that currently when using the socket transport with the org.jboss.jms.server.remoting.JMSWireFormat marshaller there is an inconsistence in the type of stream passed to the marshaller. This is a pretty straightforward fix for the remoting guys. See JIRA is http://jira.jboss.org/jira/browse/JBREM-371

      The second issue is not trivial. Currently when a client calls receive() if there are no messages the call returns but this triggers the server to push messages asynchronously to the client when they arrive.

      The issue is that the currently remoting implementation doesn't transparently support server to client communication. I feel that this issue should be addressed in the long term by the remoting guys. In the short term I think it would be useful to implement some kind of client side polling mechanism so we can support the http connector.

      Any input or feedback on these issues would be much appreciated

      Cheers,

      Aaron Walker


      • 1743 Views
      • Tags:
        • 1. Re: Uisng the HTTP Remoting Transport Connector with Messaga
          starksm64
          starksm64 Mar 30, 2006 11:01 AM (in response to apwalker)

          We need the http usecases pushed to the remoting project to as unit tests to move this forward. The first testcase should illustrate the required client poll. A second usecase should flesh out the desired behavior.

            • Actions
          • 2. Re: Uisng the HTTP Remoting Transport Connector with Messaga
            timfox
            timfox Mar 31, 2006 9:00 AM (in response to apwalker)

            I agree the base remoting abstraction should be a bi-directional Client (currently is unidirectional), and it's then up to the specific transport to implement that bidirectionality how it wants, either by polling or connections from server to client or whatever.

            Bottom line is this should be transparent to the user, which it currently isn't.

            I've discussed the second issue with Tom (there is a remoting JIRA task for it already) and we want to get the messaging and remoting teams together so we can align some more and get to a common understanding of requirements etc.

            This won't happen for a while, so for messaging 1.0.1 when the HTTP transport is due to be supported for JBoss Messaging we will have to work around this at our level.

            Actually this isn't too hard (although not trivial) but definitely in the long term this should be handled by remoting.

              • Actions