Andrew Kennedy wrote:
Ok,

So, the result of what I changed is that the 0-10 session expiry is
correctly propagated via sessionRequestTimeout and sessionTimeout
messages, however you are saying that this will not work correctly? If
I understand things correctly, when the client creates a session and
negotiates an N > 0 second expiry (or timeout) with the broker, this
successful negitiation will mislead a well-behaved client into
thinking it can resume a session in a way that is currently not
possible?

I can certainly revert the change if it is likely to cause any issues;
I think I was misled by there not being a handy test case that I could
look at, and I'm not sure it would be possible to create one using the
Java broker. As people have mentioned, more CI would certainly make
this kind of thing easier - It took me longer than I would have
expected just to get the Java client tests running against the C++
broker...

I'm not suggesting that it was entirely correct the way it was before either. At the very least the code was/is confusing. I'm just saying that the client never does frame replay and so should never advertise a non-zero session timeout.

It does however still end up going into the detached state prior to doing a semantic resume. This is purely a client side state though, and does not imply that the session still exists on the server.

Really expiry as it is currently used is just a boolean that indicates whether semantic resume is enabled. I think a proper fix might be to rename expiry to resume and change the type to boolean. With that done you could (re)introduce a timeout/expiry field that corresponds to the protocol value if needed for your original fix. I'm not sure exactly why this would be necessary though given that it should never have a non-zero value, but I don't know the details of the bug you're trying to fix.

--Rafael


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[email protected]

Reply via email to