Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.4.0
    • Component/s: spec
    • Labels:
      None

      Description

      It might be useful to have a standard mechanism in Avro for transmitting messages that receive no response, not even an acknowledgement.

      1. AVRO-285.patch
        42 kB
        Doug Cutting
      2. AVRO-285.patch
        36 kB
        Doug Cutting
      3. AVRO-285.patch
        23 kB
        Doug Cutting

        Issue Links

          Activity

          Hide
          Doug Cutting added a comment -

          This might be specified in a protocol with a message that lists no response or errors, e.g.:

          messages: [
            "sendInt" : { "request": [{"name":"x", "type": "int"}]}
             ...
          ]
          

          In the handshake, only the client's protocol hash would be examined.

          Show
          Doug Cutting added a comment - This might be specified in a protocol with a message that lists no response or errors, e.g.: messages: [ "sendInt" : { "request" : [{ "name" : "x" , "type" : " int " }]} ... ] In the handshake, only the client's protocol hash would be examined.
          Hide
          Philip Zeyliger added a comment -

          This would work. I think it would be a bit more self-descriptive if there was a '"oneway": true' (or similar) in there.

          Show
          Philip Zeyliger added a comment - This would work. I think it would be a bit more self-descriptive if there was a '"oneway": true' (or similar) in there.
          Hide
          Bruce Mitchener added a comment -

          I'd very much like to see this ... any chance? What needs to be done to bring this closer to fruition?

          Show
          Bruce Mitchener added a comment - I'd very much like to see this ... any chance? What needs to be done to bring this closer to fruition?
          Hide
          Doug Cutting added a comment -

          > What needs to be done to bring this closer to fruition?

          An implementation or two?

          Show
          Doug Cutting added a comment - > What needs to be done to bring this closer to fruition? An implementation or two?
          Hide
          Doug Cutting added a comment -

          I've started looking into implementing this. We still need a handshake to take place, so that client and server versions need not match exactly. But, without a response, there's no way to make a piggybacked handshake. So, I think, to implement this, we need to factor the handshake logic out of every request and response.

          This can be done compatibly. HTTP always sends a response, so with that transport there will always be a handshake response, and that's the only transport specified today.

          For the Java implementation of this I thus intend to refactor handshaking. I'll use a non-standard transport to test unidirectional messages, like SocketTransciever and SocketServer.

          Show
          Doug Cutting added a comment - I've started looking into implementing this. We still need a handshake to take place, so that client and server versions need not match exactly. But, without a response, there's no way to make a piggybacked handshake. So, I think, to implement this, we need to factor the handshake logic out of every request and response. This can be done compatibly. HTTP always sends a response, so with that transport there will always be a handshake response, and that's the only transport specified today. For the Java implementation of this I thus intend to refactor handshaking. I'll use a non-standard transport to test unidirectional messages, like SocketTransciever and SocketServer.
          Hide
          Doug Cutting added a comment -

          Here's the first version of a patch that adds one-way message support to Java.

          The JSON syntax is that, instead of a response type and an error list, a one way message specifies '"one-way" true'. When this is specified, no response or error are transmitted, although a handshake response still may be, depending on the transport and its connection status. This is an incompatible extension to protocols: if a client or server adds a one-way message then existing implementations may fail to parse the remote protocol even if the one-way message is never called.

          With the HTTP transport, a handshake response is still always sent, as before, so existing protocols work identically with existing implementations.

          The previously non-standard socket transport is altered so that a handshake is now only sent with requests until a successful handshake response is received. Thereafter, as long as the connection remains open, requests and responses contain no handshakes. Thus, for one-way messages, no response data at all is transmitted once a connection is established.

          The socket transport and one-way messages will be used to implement AVRO-512, so the socket protocol must be now standardized and documented in the spec.

          To do:

          • add more unit tests
          • document this in the spec, including the socket transport
          • perhaps move the handshake test message from the Simple protocol to a new protocol, so this change does not break other languages.
          Show
          Doug Cutting added a comment - Here's the first version of a patch that adds one-way message support to Java. The JSON syntax is that, instead of a response type and an error list, a one way message specifies '"one-way" true'. When this is specified, no response or error are transmitted, although a handshake response still may be, depending on the transport and its connection status. This is an incompatible extension to protocols: if a client or server adds a one-way message then existing implementations may fail to parse the remote protocol even if the one-way message is never called. With the HTTP transport, a handshake response is still always sent, as before, so existing protocols work identically with existing implementations. The previously non-standard socket transport is altered so that a handshake is now only sent with requests until a successful handshake response is received. Thereafter, as long as the connection remains open, requests and responses contain no handshakes. Thus, for one-way messages, no response data at all is transmitted once a connection is established. The socket transport and one-way messages will be used to implement AVRO-512 , so the socket protocol must be now standardized and documented in the spec. To do: add more unit tests document this in the spec, including the socket transport perhaps move the handshake test message from the Simple protocol to a new protocol, so this change does not break other languages.
          Hide
          Jeff Hodges added a comment -

          Isn't this a backwards incompatible change? Don't we have to wait til 2.0 for those or were the comments in AVRO-530 incorrect?

          Show
          Jeff Hodges added a comment - Isn't this a backwards incompatible change? Don't we have to wait til 2.0 for those or were the comments in AVRO-530 incorrect?
          Hide
          Doug Cutting added a comment -

          > Isn't this a backwards incompatible change?

          Good point.

          So maybe the change should be that, when:

          • the message response type is null
          • no message errors are specified
          • the previously-non-standard socket transport is used
          • a connection has been established with a handshake, and
          • "one-way": true is specified (which existing implementations should ignore)
            then no response data is written at all.

          In other words, one-way only has a special meaning for stateful transports, and previously the spec defined no stateful transports. For "stateless" transports like HTTP, one-way is ignored.

          Show
          Doug Cutting added a comment - > Isn't this a backwards incompatible change? Good point. So maybe the change should be that, when: the message response type is null no message errors are specified the previously-non-standard socket transport is used a connection has been established with a handshake, and "one-way": true is specified (which existing implementations should ignore) then no response data is written at all. In other words, one-way only has a special meaning for stateful transports, and previously the spec defined no stateful transports. For "stateless" transports like HTTP, one-way is ignored.
          Hide
          Doug Cutting added a comment -

          Here's a version that is compatible. In particular,

          • one-way messages specify a response type of "null" so they're parseable by older impls. (the java parser is lenient in that it does not require this, but the java printer will always include this response type.)
          • "stateless" transports like HTTP always return a response for one-way messages

          The socket transport is now "stateful", meaning:

          • requests and responses are only prefixed with handshakes until a successful handshake response is returned
          • once a successful handshake response has been returned, a one-way message has no response data

          More tests have been added. Still need to add a documentation to the spec.

          I also fixed the RPC unit tests to no longer create a new client and server for each request but rather to reuse them.

          Show
          Doug Cutting added a comment - Here's a version that is compatible. In particular, one-way messages specify a response type of "null" so they're parseable by older impls. (the java parser is lenient in that it does not require this, but the java printer will always include this response type.) "stateless" transports like HTTP always return a response for one-way messages The socket transport is now "stateful", meaning: requests and responses are only prefixed with handshakes until a successful handshake response is returned once a successful handshake response has been returned, a one-way message has no response data More tests have been added. Still need to add a documentation to the spec. I also fixed the RPC unit tests to no longer create a new client and server for each request but rather to reuse them.
          Hide
          Doug Cutting added a comment -

          Here's a new version that updates the spec to describe one-way messages and to distinguish between "stateless" and "stateful" transports. The only fully-specified transport remains HTTP, which is stateless.

          Show
          Doug Cutting added a comment - Here's a new version that updates the spec to describe one-way messages and to distinguish between "stateless" and "stateful" transports. The only fully-specified transport remains HTTP, which is stateless.
          Hide
          Doug Cutting added a comment -

          I'd like to commit this so that I can start work on AVRO-512, which requires it. This makes no incompatible changes, only adding a "one-way" declaration to messages that may be ignored by existing implementations.

          Show
          Doug Cutting added a comment - I'd like to commit this so that I can start work on AVRO-512 , which requires it. This makes no incompatible changes, only adding a "one-way" declaration to messages that may be ignored by existing implementations.
          Hide
          Doug Cutting added a comment -

          I just committed this.

          Show
          Doug Cutting added a comment - I just committed this.

            People

            • Assignee:
              Doug Cutting
              Reporter:
              Doug Cutting
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development