Error in "session_destroy" in eh_sender_with_sas_token_sample

[ahmedawad1]

Hi,
I tested "eh_sender_with_sas_token_sample" in samples and it is working fine and it sends to the Eventhub except when session_destroy(session) is executed, then the call back function "on_cbs_error" is executed and shows CBS error.

Please what is the reason for this error? I cannot understand it.

[dcristoloveanu]

CBS uses 2 links (a sender link and a receiver link) to have a message request/response pattern which is then used to execute basic RPCs like put_token.

The working draft for CBS is here: https://lists.oasis-open.org/archives/amqp/201307/msg00002/amqp-cbs-v1.0-wd01_2013-07-08.pdf

Note that it has never been ratified, but since it is used in MS Azure services (EH, SB, IotHub), it is provided with uAMQP.

The 2 links I mentioned are created in the context of a session.
If that session is ended (calling destroy will end the session anyhow), then the error is propagated up to the links and to the CBS layer.

I hope this helps understanding it. Basically the error you see is because the session layer gets destroyed before the CBS object that relies on it.

It seems the sample is missing a cbs_destroy call, which should cleanly destroy the CBS layer before the session is destroyed in order to not display any error.

Cheers,
/Dan

[ahmedawad1]

Thanks Dan for the reply. I actually tried to put cbs_destroy(cbs) before messagesender_destroy and it didn't work.
cbs_destroy(cbs)
messagesender_destroy(message_sender);
link_destroy(link);
session_destroy(session);

I think also I tried to put it before session_destroy(session) and the same error appeared but I am not so sure so I will try it tomorrow and give you the feedback.
Thanks again.

[ahmedawad1]

I tried it after link_destroy but the same error comes up!

[dcristoloveanu]

Hi @ahmedawad1

I was able to repro this and indeed after adding the cbs_destroy the print with the error is still hit.
The reason is that CBS does not differentiate between an error and a regular close of the underlying message sender and receiver.

So it will treat this as an error and report it.
Essentially another callback is needed to indicate nicely a disconnect if the user needs to differentiate between the 2 cases.

I can see there would be some cases where the user application wants to know that it was a close initiated by the user application.
A workaround until a disconnect callback gets implemented is that the user application knows that it initiated the close or an error really happened and it needs to react to it.

I hope this helps you,
/Dan

[dcristoloveanu]

Marking this as an enhancement to add a disconnect callback to CBS.