> Its probably just been expected it would start at 0 as it does elsewhere, > but I dont see anything in the spec requiring that and it isnt > negotiated.
I was hoping that was the case :) > You can raise JIRAs at https://issues.apache.org/jira/browse/PROTON. > If you wanted you could even try a patch, or raise a PR. Include the > JIRA key in the PR title and commit messages and theyll get lined up > for some bot handling later (comments etc), e.g see an existing PR > such as https://github.com/apache/qpid-proton/pull/134. Thanks I'll raise a jira issue. aconway.rh wrote > Are you re-using the same pn_transport_t for the new connection? I don't > think pn_transport_t was designed with the expectation of being re-used, > so > I wouldn't be surprised if it doesn't work. > I'd throw away the old transport and create a new one to re-connect. I > believe that's what the C++ reconnect code does - you may find that useful > for inspiration, it's based on the C library. > > https://github.com/alanconway/qpid-proton/blob/ruby-schedule/proton-c/bindings/cpp/src/proactor_container_impl.cpp#L1 My sample is in python using the python-proton binding. As far as I can tell the python-binding code just sets the next uri on the connection and reuses the connection struct (as well as the session struct) not the transport. I'm not sure but, wouldn't connection.open() create a new transport? Also thank you for the reconnect code. I will be making samples using proton-c direct eventually. And the cpp code seems to handle amqp:connection:forced conditions where the python-bindings reconnect logic does not which concerned me about the python binding. This might be another issue. Chris Morgan -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
