channel always 0. Should it increment?

[anthonyvercolano]

I create a container.
I then create a connection under that container.
After I have the connection object I then do a mySession = myConnection.create_session();
mySession.open();

I then do an mySession.open_sender({target: '$cbs'});

I get the following logs:

rhea:frames [connection-1] PENDING: '{"channel":0,"type":0,"performative":["9ebe2971-4f1d-0c40-9a17-2fcb742eaf61",0,false,null,null,[],["$cbs"],null,null,0,null,null,null,["com.microsoft:client-version","azure-iot-device/1.4.1"]]}' +2s
rhea:raw [connection-1] SENT: <Buffer 00 00 00 99 02 00 00 00 00 53 12 d0 00 00 00 89 00 00 00 0e a1 24 39 65 62 65 32 39 37 31 2d 34 66 31 64 2d 30 63 34 30 2d 39 61 31 37 2d 32 66 63 62 ... > +2s
rhea:io [connection-1] read 162 bytes +2s
rhea:io [connection-1] got frame of size 162 +1ms
rhea:frames [connection-1] RECV: '{"size":162,"type":0,"channel":0,"performative":{"type":"attach#12","name":"9ebe2971-4f1d-0c40-9a17-2fcb742eaf61","role":true,"source":[null,null,null,null,null,null,null,null,null,null,null],"target":["$cbs",null,null,null,null,null,null],"max_message_size":1048576,"properties":{"com.microsoft:client-version":"azure-iot-device/1.4.1"}}}' +40ms

Shouldn't the creation of the session have caused a new channel to be allocated? Shouldn't the performatives associated with the sender link be using a new channel number?

I am trying to track a problem down. I am comparing the differences in traffic between rhea and amqp10.

When doing the same sequence in amqp10 these new links utilize channel 1.

[grs]

0 is a valid channel and is used for the first session created. Any subsequent sessions on the same connection should indeed use a separate channel. In your example above you only create one session. If however you see the same channel being used for different sessions on the same connection, that would indeed be a bug.

[grs]

Is there any detail you can give regarding the problem you are tracking down in case I can suggest anything?

[anthonyvercolano]

Sure. When I go to open a second receiver within a session, I get an error from the peer which it amqp:illegal-state. What I have now determined is that this new receiver is getting the same name (a uuid) as the previously (first) created/opened receiver in the session. This looks like it is happening around line 452 of session.js. We are re-using the previously calculated name in default_args.

[grs]

My apologies! That was a bug introduced by me in the implementation of the default options feature. I have committed a fix and a test for it now.