The C code isn't in my wheelhouse, but it sounds like a bug. 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.

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.

Robbie

On 22 March 2018 at 21:23, Christopher Morgan
<christopher.mor...@solace.com> wrote:
> Hi all,
>
> I'm trying to write a failover, with a host list, example application for a 
> solace amqp broker using the qpid-proton-python using the example code from 
> http://qpid.2158936.n2.nabble.com/About-failover-td7649247.html as a base. 
> When I ran the application I got a lot transport errors from pn_do_transfer 
> in transport.c:
> <code>
> if (id_present && id != state->id) {
>       return pn_do_error(transport, "amqp:session:invalid-field",
>                          "sequencing error, expected delivery-id %u, got %u",
>                          state->id, id);
> }
> </code>
>
> The errors occurred on the new connection on the first transfer frame with 
> the delivery id 1. The solace amqp broker begins its delivery id sequence at 
> 1. But, on the reconnected session the ssn->state.incoming->next value seems 
> to set to 0. I noticed there is code to set the ssn->state.incoming->next 
> value to the first incoming transfer base on the flag 
> ssn->state.incoming_init. When I added some extra logs around that value I 
> noticed the ssn->state.incoming_init flag is not reset when reconnecting and 
> is set to 0 as a part of the transport unbind process. I also modified the 
> pn_session_unbind function in engine.c to set the ssn->state.incoming_init to 
> false and it seemed to fix my issue.
>
> I'm somewhat new to using the proton-c source and was curious if this is a 
> bug? If not, why wouldn't the incoming_init be reset? If so, is there a 
> better place to reset the flag? Are there more places?
>
> Thanks
>
> Chris Morgan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Reply via email to