2 Replies Latest reply on Jan 28, 2008 9:52 AM by timfox

    New transport: Determining oneway messages

    timfox

      Several messages, e.g. acknowledge or cancel etc, can be sent wither oneWay or blocking depending on the particular use case.

      Currently when such is processed on the server, there is currently no generic way to know whether a response is required to be sent.

      SendMessage currently does this by checking whether the message is durable.

      I think we need some generic way of a packet knowing whether a response is required (e.g. a oneway flag in AbstractPacket) rather than having to rely on application semantics to determine whether a response should be sent.

      Currently I am just always sending a response even for one way calls (since I don't know they are oneway), this gives me lots of:

      
      Thread-168 10:22:12,758 ERROR [PacketDispatcher] Packet is not handled, it has no targetID: PACKET[type=NULL, version=0, correlationID=-1, targetID=NO_ID_SET, callbackID=NO_ID_SET]
      


        • 1. Re: New transport: Determining oneway messages
          jmesnil

           

          "timfox" wrote:
          Several messages, e.g. acknowledge or cancel etc, can be sent wither oneWay or blocking depending on the particular use case.

          Currently when such is processed on the server, there is currently no generic way to know whether a response is required to be sent.

          SendMessage currently does this by checking whether the message is durable.

          I think we need some generic way of a packet knowing whether a response is required (e.g. a oneway flag in AbstractPacket) rather than having to rely on application semantics to determine whether a response should be sent.


          Good suggestion.

          I'll add a oneWay boolean attribute to AbstractPacket.
          In the packet handler, before leaving the handle() method, I check if there is a response to send or if the oneWay boolean is set to false on the request.
          If the boolean is set to false, I'll send a NullPacket() to "unblock" the client side.


          • 2. Re: New transport: Determining oneway messages
            timfox

            Ok good.

            One more thing - if a packet can be sent one way or blocking, it doesn't really make sense to call the packets XXXRequest any more.

            We should probably rename all the XXRequest and XXResponse classes just to XXXMessage