i.e. provide for simple one-line execution of all examples

• If not specified the default should be zero as per the spec.

Converting some code to utilize rhea.

With our other amqp transport we could specify properties on the amqp client constructor for default properties on the attach for sender and receiver links:

senderLink: {
attach: {
properties: {
'client-version': '1.0'
},
maxMessageSize: 0,
},

So that whenever we created a actual server link it would have at least the 'client-version' property. When actually creating a sender link later on, we could optionally send further properties so that the link would have on the attach

properties: {
'client-version': '1.0',
'api-version': '2018',
'channel-correlation': 'abc'
}

Is there a straight forward way of setting up the initial default property prior to actually creating the senderlink?

Thanks,
Tony

Hi, i'm trying to figure out a way to "force" the library to decode the correlation_id property of a message I'm receiving as a UUID. Right now i only get a Buffer (UInt8Array) - i'm trying to make my way through the type system but i get a bit lost in there.... any pointers or suggestions?

Thanks!

[edit] I'm able to "read" the uuid from the buffer by using this package: https://www.npmjs.com/package/uuid-buffer
but I also need to send it "re-encoded" as a uuid - and in that case it looks like I fall into this "todo" item

Feels like either one would need a way to "force" the type of the property OR you'd need to "detect" uuids from strings or buffers and encode them with the proper type (might be expensive).

thoughts?

This is not a bug report. This is a request for support. I need to be able to detect when reconnect_limit has been reached so that I can send an email out to alert people that the link to the server has been broken. But I simply have not been able to figure out how to detect this. I've been looking in the context for the disconnected event, but nothing stands out to me. How would I detect this? Thanks.

It seems that dynamic property on source and target is wrongly encoded.
From Wireshark I see 0x00 for false and 0x01 for true and not the right AMQP type boolean encoding 0x42 for false and 0x41 for true.

Utilizing the amqp10 library the links had a method called forceDetach.

We found it useful when doing error recovery to invoke on link. Essentially it caused the local state of the link to go to detached without actually performing a network operation to inform the remote. This is helpful when having detected an actual networking issue, we no longer wish to perform network operations that we know will fail.

Is there anyway that we can mimic this activity with rhea? In cursory looking at detach, it does look like that it will initiate a network send.

Thank you for your time,
Tony

Hi, I'm trying to use the rhea library with angular 2 + webpack.
I get an exception when I run the following code:

import * as _ from 'rhea';
_.on('connection_open', function (context) {
context.connection.open_receiver('examples');
context.connection.open_sender('examples');
});
_.on('message', function (context) {
console.log(context.message.body);
context.connection.close();
});
_.once('sendable', function (context) {
context.sender.send({ body: payload });
});
_.connect({'host': 'localhost', 'port': 61616, 'user' : 'admin','password': 'admin', 'reconnect': true });

vendor.bundle.js:83229 Angular is running in the development mode. Call enableProdMode() to enable the production mode.
main.bundle.js:397 o payload é undefined
ng:///ClientsMessageModule/ProducerComponent.ngfactory.js:220 ERROR TypeError: get_connect_fn(...) is not a function
at Connection.webpackJsonp.../../../../rhea/lib/connection.js.Connection.connect (vendor.bundle.js:25781)
at Connection.webpackJsonp.../../../../rhea/lib/connection.js.Connection.connect (vendor.bundle.js:25763)
at Container.webpackJsonp.../../../../rhea/lib/container.js.Container.connect (vendor.bundle.js:26262)
at AmqpService.webpackJsonp.../../../../../src/app/clients-message/services/amqp.service.ts.AmqpService.put (main.bundle.js:504)
at ProducerService.webpackJsonp.../../../../../src/app/clients-message/producer/producer.service.ts.ProducerService.send (main.bundle.js:456)
at ProducerComponent.webpackJsonp.../../../../../src/app/clients-message/producer/producer.component.ts.ProducerComponent.OnClick (main.bundle.js:398)
at Object.eval [as handleEvent] (ng:///ClientsMessageModule/ProducerComponent.ngfactory.js:226)
at handleEvent (vendor.bundle.js:92351)
at callWithDebugContext (vendor.bundle.js:93810)
at Object.debugHandleEvent [as handleEvent] (vendor.bundle.js:93398)
View_ProducerComponent_0 @ ng:///ClientsMessageModule/ProducerComponent.ngfactory.js:220
proxyClass @ vendor.bundle.js:67538
webpackJsonp.../../../core/@angular/core.es5.js.DebugContext.logError @ vendor.bundle.js:93750
webpackJsonp.../../../core/@angular/core.es5.js.ErrorHandler.handleError @ vendor.bundle.js:81384
(anonymous) @ vendor.bundle.js:89578
(anonymous) @ vendor.bundle.js:104101
webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invokeTask @ polyfills.bundle.js:2838
onInvokeTask @ vendor.bundle.js:84228
webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invokeTask @ polyfills.bundle.js:2837
webpackJsonp.../../../../zone.js/dist/zone.js.Zone.runTask @ polyfills.bundle.js:2605
ZoneTask.invoke @ polyfills.bundle.js:2900
ng:///ClientsMessageModule/ProducerComponent.ngfactory.js:220 ERROR CONTEXT DebugContext_
View_ProducerComponent_0 @ ng:///ClientsMessageModule/ProducerComponent.ngfactory.js:220
proxyClass @ vendor.bundle.js:67538
webpackJsonp.../../../core/@angular/core.es5.js.DebugContext_.logError @ vendor.bundle.js:93750
webpackJsonp.../../../core/@angular/core.es5.js.ErrorHandler.handleError @ vendor.bundle.js:81389
(anonymous) @ vendor.bundle.js:89578
(anonymous) @ vendor.bundle.js:104101
webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invokeTask @ polyfills.bundle.js:2838
onInvokeTask @ vendor.bundle.js:84228
webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invokeTask @ polyfills.bundle.js:2837
webpackJsonp.../../../../zone.js/dist/zone.js.Zone.runTask @ polyfills.bundle.js:2605
ZoneTask.invoke @ polyfills.bundle.js:2900

3.2.4    Properties
Immutable properties of the message.
<type name="properties" class="composite" source="list" provides="section">
<descriptor name="amqp:properties:list" code="0x00000000:0x00000073"/>
<field name="message-id" type="*" requires="message-id"/>
<field name="user-id" type="binary"/>
<field name="to" type="*" requires="address"/>
<field name="subject" type="string"/>
<field name="reply-to" type="*" requires="address"/>
<field name="correlation-id" type="*" requires="message-id"/>
<field name="content-type" type="symbol"/>
<field name="content-encoding" type="symbol"/>
<field name="absolute-expiry-time" type="timestamp"/>
<field name="creation-time" type="timestamp"/>
<field name="group-id" type="string"/>
<field name="group-sequence" type="sequence-no"/>
<field name="reply-to-group-id" type="string"/>
</type>
The properties section is used for a defined set of standard properties of the message. The properties section is
part of the bare message; therefore, if retransmitted by an intermediary, it MUST remain unaltered.

As per the AMQP 1.0 specification, I thought that the predefined message properties should be sent inside a property named properties as follows in an amqp message object:

const request: any = {
         body: tokenObject.token,
        properties: { //properties object..
           message_id: uuid(),
           reply_to: this.replyTo,
           to: this.endpoint,
        },
        application_properties: {
          operation: Constants.operationPutToken,
          name: audience,
          type: tokenObject.tokenType
        }

Usually the service would send back a message which has correlation_id in it. However that did not happen.
Instead when I sent those predefined properties as top level properties as described below then the service did send me a message with correlation_id in it.

const request: any = {
        body: tokenObject.token,
        message_id: uuid(), // Top level property
        reply_to: this.replyTo, // Top level property
        to: this.endpoint, // Top level property
        application_properties: {
          operation: Constants.operationPutToken,
          name: audience,
          type: tokenObject.tokenType
        }
      };

Thus it seems to me like all the predefined properties need to be sent as top level properties.

I am not sure if the service is doing something wrong over here. However, wanted to know if rhea was expecting all the predefined properties as top level properties inside the AMQP message.

I've run "istanbul cover rhea/lib/*js" to get the test coverage of rhea:
=============================== Coverage summary ===============================
Statements : 29.79% ( 558/1873 )
Branches : 3.67% ( 27/736 )
Functions : 3.72% ( 12/323 )

Lines : 30.59% ( 558/1824 )

I think it'd be great to increase the coverage.

The documentation says:

credit_window - A 'prefetch' window controlling the flow of messages over this receiver. Defaults to 500 if not specified. A value of 0 can be used to turn of automatic flow control and manage it directly.

Side note: Btw, reading the source code it looks like the default value is 1000 and not 500 (doc should be updated).

Further down for receiver the doc says:

add_credit(n)
By default, receivers have a prefetch window that is moved automatically by the library. However if desired the application can set the prefecth to zero and manage credit itself. Each invocation of add_credit() method issues credit for a further 'n' messages to be sent by the peer over this receiving link. [Note: flow()is an alias for add_credit()]

So it seems that,
While creating the receiver, the credit_window can be set to 0 and then we can say receiver.add_credit(n) to receive n messages. However,

• is it possible for us to create a receiver with default credit_window of 1000 and some time later set the window to 0 to manage it on my own? Will this cause any messages to be dropped?
• OR vice-versa - Create the receiver with credit_window of 0 and then set the window to 1000, will this indicate rhea to manage credits automatically? Or do we have to make sure to replenish the credits once they are exhausted?

Scenario:

The receiver is busy receiving messages and some time later it decides that it wants to close itself.
With debug logs on, what i noticed was: Between closing the receiver and the close actually happening, close to ~1000 messages were received by rhea but were never sent to my app.

Here are the debug logs..

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Closing receiver.
  rhea:frames [connection-1] PENDING: '{"channel":1,"type":0,"performative":[0,true]}' +12ms
  rhea:raw [connection-1] SENT: <Buffer 00 00 00 16 02 00 00 01 00 53 16 d0 00 00 00 06 00 00 00 02 43 41> +12ms
  rhea:io [connection-1] read 16355 bytes +94ms
  rhea:io [connection-1] got frame of size 562 +0ms
  rhea:frames [connection-1] RECV: '{"size":562,"type":0,"channel":1,"performative":{"type":"transfer#14","delivery_id":2022,"delivery_tag":{"type":"Buffer","data":[]},"settled":true,"batchable":true},"payload":{"type":"Buffer","data":[0,83,113,193,150,8,163,29,108,97,115,116,95,101,110,113,117,101,117,101,100,95,115,101,113,117,101,110,99,101,95,110,117,109,98,101,114,129,0,0,0,0,0,4,138,110,163,20,108,97,115,116,95,101,110,113,117,101,117,101,100,95,111,102,102,115,101,116,161,10,56,54,50,50,54,52,57,51,50,48,163,22,108,97,115,116,95,101,110,113,117,101,117,101,100,95,116,105,109,101,95,117,116,99,131,0,0,1,98,213,174,174,184,163,31,114,117,110,116,105,109,101,95,105,110,102,111,95,114,101,116,114,105,101,118,97,108,95,116,105,109,101,95,117,116,99,131,0,0,1,98,218,46,195,236,0,83,114,193,89,6,163,21,120,45,111,112,116,45,115,101,113,117,101,110,99,101,45,110,117,109,98,101,114,129,0,0,0,0,0,3,63,153,163,12,120,45,111,112,116,45,111,102,102,115,101,116,161,10,56,53,57,48,54,49,51,57,56,52,163,19,120,45,111,112,116,45,101,110,113,117,101,117,101,100,45,116,105,109,101,131,0,0,1,98,110,206,229,157,0,83,115,69,0,83,119,209,0,0,1,15,0,0,0,2,161,4,98,111,100,121,176,0,0,1,0,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90]}}' +82ms
  rhea:io [connection-1] got frame of size 562 +0ms
  rhea:frames [connection-1] RECV: '{"size":562,"type":0,"channel":1,"performative":{"type":"transfer#14","delivery_id":2023,"delivery_tag":{"type":"Buffer","data":[]},"settled":true,"batchable":true},"payload":{"type":"Buffer","data":[0,83,113,193,150,8,163,29,108,97,115,116,95,101,110,113,117,101,117,101,100,95,115,101,113,117,101,110,99,101,95,110,117,109,98,101,114,129,0,0,0,0,0,4,138,110,163,20,108,97,115,116,95,101,110,113,117,101,117,101,100,95,111,102,102,115,101,116,161,10,56,54,50,50,54,52,57,51,50,48,163,22,108,97,115,116,95,101,110,113,117,101,117,101,100,95,116,105,109,101,95,117,116,99,131,0,0,1,98,213,174,174,184,163,31,114,117,110,116,105,109,101,95,105,110,102,111,95,114,101,116,114,105,101,118,97,108,95,116,105,109,101,95,117,116,99,131,0,0,1,98,218,46,195,236,0,83,114,193,89,6,163,21,120,45,111,112,116,45,115,101,113,117,101,110,99,101,45,110,117,109,98,101,114,129,0,0,0,0,0,3,63,154,163,12,120,45,111,112,116,45,111,102,102,115,101,116,161,10,56,53,57,48,54,49,52,51,50,48,163,19,120,45,111,112,116,45,101,110,113,117,101,117,101,100,45,116,105,109,101,131,0,0,1,98,110,206,229,157,0,83,115,69,0,83,119,209,0,0,1,15,0,0,0,2,161,4,98,111,100,121,176,0,0,1,0,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90]}}' +1ms
  rhea:io [connection-1] got frame of size 562 +1ms

. . . . and many more like that...

  rhea:frames [connection-1] RECV: '{"size":562,"type":0,"channel":1,"performative":{"type":"transfer#14","delivery_id":3014,"delivery_tag":{"type":"Buffer","data":[]},"settled":true,"batchable":true},"payload":{"type":"Buffer","data":[0,83,113,193,150,8,163,29,108,97,115,116,95,101,110,113,117,101,117,101,100,95,115,101,113,117,101,110,99,101,95,110,117,109,98,101,114,129,0,0,0,0,0,4,138,110,163,20,108,97,115,116,95,101,110,113,117,101,117,101,100,95,111,102,102,115,101,116,161,10,56,54,50,50,54,52,57,51,50,48,163,22,108,97,115,116,95,101,110,113,117,101,117,101,100,95,116,105,109,101,95,117,116,99,131,0,0,1,98,213,174,174,184,163,31,114,117,110,116,105,109,101,95,105,110,102,111,95,114,101,116,114,105,101,118,97,108,95,116,105,109,101,95,117,116,99,131,0,0,1,98,218,46,205,145,0,83,114,193,89,6,163,21,120,45,111,112,116,45,115,101,113,117,101,110,99,101,45,110,117,109,98,101,114,129,0,0,0,0,0,3,67,121,163,12,120,45,111,112,116,45,111,102,102,115,101,116,161,10,56,53,57,48,57,52,55,50,57,54,163,19,120,45,111,112,116,45,101,110,113,117,101,117,101,100,45,116,105,109,101,131,0,0,1,98,110,206,230,26,0,83,115,69,0,83,119,209,0,0,1,15,0,0,0,2,161,4,98,111,100,121,176,0,0,1,0,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90,90]}}' +0ms
  rhea:io [connection-1] got frame of size 17 +0ms
>>  rhea:frames [connection-1] RECV: '{"size":17,"type":0,"channel":1,"performative":{"type":"detach#16","closed":true}}' +0ms
>>  rhea:events Link got event: receiver_close +3s
  rhea-promise Resolving the promise as the amqp receiver has been closed. +13s
  azure:event-hubs:receiver Deleted the receiver "5334b21b-b629-4e18-ae52-4c21c6de49e7" from the client cache. +12s
  azure:event-hubs:receiver [connection-1] Receiver "5334b21b-b629-4e18-ae52-4c21c6de49e7" has been closed. +0ms
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Closing client.
  rhea:frames [connection-1] PENDING: '{"channel":0,"type":0,"performative":[]}' +2ms
  rhea:raw [connection-1] SENT: <Buffer 00 00 00 0c 02 00 00 00 00 53 17 45> +3s
  rhea:io [connection-1] read 15 bytes +96ms
  rhea:io [connection-1] got frame of size 15 +0ms
  rhea:frames [connection-1] RECV: '{"size":15,"type":0,"channel":0,"performative":{"type":"end#17"}}' +94ms
  rhea:events Session got event: session_close +96ms
  rhea-promise Resolving the promise as the amqp session has been closed. +96ms
  azure:event-hubs:cbs Successfully closed the cbs session. +14s
  rhea:frames [connection-1] PENDING: '{"channel":0,"type":0,"performative":[]}' +2ms
  rhea:raw [connection-1] SENT: <Buffer 00 00 00 0c 02 00 00 00 00 53 18 45> +96ms
  rhea:io [connection-1] read 15 bytes +96ms
  rhea:io [connection-1] got frame of size 15 +1ms
  rhea:frames [connection-1] RECV: '{"size":15,"type":0,"channel":0,"performative":{"type":"close#18"}}' +95ms
  rhea:events Connection got event: connection_close +96ms
  rhea-promise Resolving the promise as the connection has been successfully closed. +97ms
  azure:event-hubs:client Closed the amqp connection "connection-1" on the client. +0ms
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Closed receiver and client...

For reference these are the options that I provided while creating the receiver:

rhea:events Link got event: receiver_open +639ms
  rhea-promise Resolving the promise with amqp receiver "5334b21b-b629-4e18-ae52-4c21c6de49e7". +638ms
  azure:event-hubs:receiver Promise to create the receiver resolved. Created receiver with name:  5334b21b-b629-4e18-ae52-4c21c6de49e7 +638ms
  azure:event-hubs:receiver [connection-1] Receiver '5334b21b-b629-4e18-ae52-4c21c6de49e7' created with receiver options: { name: '5334b21b-b629-4e18-ae52-4c21c6de49e7',
  azure:event-hubs:receiver   autoaccept: true,
  azure:event-hubs:receiver   source: { address: 'xxxxx/ConsumerGroups/$default/Partitions/0' },
  azure:event-hubs:receiver   credit_window: 0,
  azure:event-hubs:receiver   desired_capabilities: 'com.microsoft:enable-receiver-runtime-metric',
  azure:event-hubs:receiver   target: undefined } +0ms

The title pretty much says it all. I have been up and down the library but I can't seem to figure out how I do this with rhea. The examples all use 'example' as the address so it makes it difficult to tell if it is just using a queue or a topic.

Any help would be appreciated. 😄

stack trace

Exception has occurred: Error
Error: Invalid handle null
    at Session._get_link (d:\sdk\rhea\lib\session.js:641:15)
    at Session.on_flow (d:\sdk\rhea\lib\session.js:626:14)
    at Connection.(anonymous function) [as on_flow] (d:\sdk\rhea\lib\connection.js:646:30)
    at c.dispatch (d:\sdk\rhea\lib\types.js:904:33)
    at Transport.read (d:\sdk\rhea\lib\transport.js:95:36)
    at SaslClient.read (d:\sdk\rhea\lib\sasl.js:252:26)
    at Connection.input (d:\sdk\rhea\lib\connection.js:424:35)
    at emitOne (events.js:116:13)
    at TLSSocket.emit (events.js:211:7)
    at addChunk (_stream_readable.js:263:12)

This condition failure causes the exception.

frame.handle is null and the if condition is checking if(frame.handle != undefined)

Here is how the frame object looks like in the debug window

Object {size: 35, type: 0, channel: 0, performative: c}
VM255:1
channel:0
performative:c {value: Array(11)}
available:null
delivery_count:null
drain:null
echo:true
handle:null
incoming_window:5000
link_credit:null
next_incoming_id:1
next_outgoing_id:1
outgoing_window:2048
properties:null
value:Array(11) [Typed, Typed, Typed, …]
length:11
__proto__:Array(0) [, …]
0:Typed {type: TypeDesc, value: 1}
1:Typed {type: TypeDesc, value: 5000}
2:Typed {type: TypeDesc, value: 1}
3:Typed {type: TypeDesc, value: 2048}
4:Typed {type: TypeDesc, value: null}
5:Typed {type: TypeDesc, value: null}
6:Typed {type: TypeDesc, value: null}
7:Typed {type: TypeDesc, value: null}
8:Typed {type: TypeDesc, value: null}
9:Typed {type: TypeDesc, value: true}
10:Typed {type: TypeDesc, value: null}
__proto__:Object {dispatch: , next_incoming_id: <accessor>, incoming_window: <accessor>, …}
size:35
type:0
__proto__:Object {constructor: , __defineGetter__: , __defineSetter__: , …}

and you can rightly see that handle is null

What could be possibly happening?

Getting these random frame sequence errors?

debug: Error: frame sequence error: expected 15, got 56
    at Incoming.on_transfer (D:\home\site\wwwroot\node_modules\rhea\lib\session.js:337:19)
    at Session.on_transfer (D:\home\site\wwwroot\node_modules\rhea\lib\session.js:661:19)
    at Connection.(anonymous function) [as on_transfer] (D:\home\site\wwwroot\node_modules\rhea\lib\connection.js:650:30)
    at c.dispatch (D:\home\site\wwwroot\node_modules\rhea\lib\types.js:904:33)
    at Transport.read (D:\home\site\wwwroot\node_modules\rhea\lib\transport.js:95:36)
    at Connection.input (D:\home\site\wwwroot\node_modules\rhea\lib\connection.js:428:35)
    at emitOne (events.js:116:13)
    at TLSSocket.emit (events.js:211:7)
    at addChunk (_stream_readable.js:263:12)
    at readableAddChunk (_stream_readable.js:250:11)
    at TLSSocket.Readable.push (_stream_readable.js:208:10)
    at TLSWrap.onread (net.js:594:20) 'Error: frame sequence error: expected 15, got 56\n    at Incoming.on_transfer (D:\\home\\site\\wwwroot\\node_modules\\rhea\\lib\\session.js:337:19)\n    at Session.on_transfer (D:\\home\\site\\wwwroot\\node_modules\\rhea\\lib\\session.js:661:19)\n    at Connection.(anonymous function) [as on_transfer] (D:\\home\\site\\wwwroot\\node_modules\\rhea\\lib\\connection.js:650:30)\n    at c.dispatch (D:\\home\\site\\wwwroot\\node_modules\\rhea\\lib\\types.js:904:33)\n    at Transport.read (D:\\home\\site\\wwwroot\\node_modules\\rhea\\lib\\transport.js:95:36)\n    at Connection.input (D:\\home\\site\\wwwroot\\node_modules\\rhea\\lib\\connection.js:428:35)\n    at emitOne (events.js:116:13)\n    at TLSSocket.emit (events.js:211:7)\n    at addChunk (_stream_readable.js:263:12)\n    at readableAddChunk (_stream_readable.js:250:11)\n    at TLSSocket.Readable.push (_stream_readable.js:208:10)\n    at TLSWrap.onread (net.js:594:20)'

It would be fine if I had to temporarily adjust the source.

Hi

taking a look at the sasl-specific portion of the code i'm trying to understand what a client needing a custom sasl mechanism could do.

it looks like the sasl_mechanism interface is synchronous - meaning the init() and next() APIs have to return results and cannot use callbacks/promises, is that correct? in the case where the sasl mechanism relies on external async APIs (for example using a hardware TPM to sign a SASL challenge key with a secret stored in the hardware), how would that work?

also it looks like the PlainClient and AnonymousClient aren't exported? in the case where we want to build a client that supports multiple SASL mechanisms, do we have to rewrite them? or are the sasl_mechanisms collections (the default one and the user-provided one) merged?

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.

Hello,

I was looking at the node-amqp10 library and this one. I wanted to know

• if rhea is AMQP 1.0 compliant?
• how is this different from node-amqp10?
• Can this be used with Azure ServiceBus? Are there any examples?

Utilizing amqp10 we can impose a type on our uuid properties message_id and correlation_id.

We assign the property in the message object before sending it to amqp like so:

if (typeof uuidString === 'string' && uuidString.match(uuidRegEx)) {
uuid = (amqp10).Type.uuid(uuidString);
}

When amqp10 serializes the data it will utilize the amqp uuid type.

Any thoughts on how this can be (or could be) accomplished with rhea?

Users will likely end up trying DEBUG=rhea and failing, because that's what the primary docs on the web suggest. I did this, and it produces no output. I recommend mentioning DEBUG=* and DEBUG=rhea:$aspect.

If you send before there is credit, then close the sender (or connection) the messages don't get sent correctly as the close is issued first.

I see this error in the EnMasse subscription service log. Not sure if this is an error on my behalf, but at first sight it looks like an internal library issue.

/node_modules/rhea/lib/session.js:274
data = Buffer.concat([current.data, frame.payload], current.data.size() + f
^
TypeError: undefined is not a function
at Incoming.on_transfer (/node_modules/rhea/lib/session.js:274:78)
at Session.on_transfer (/node_modules/rhea/lib/session.js:586:19)
at Connection.(anonymous function) [as on_transfer] (/node_modules/rhea/lib/connection.js:549:30)
at c.dispatch (/node_modules/rhea/lib/types.js:793:33)
at Transport.read (/node_modules/rhea/lib/transport.js:88:36)
at SaslClient.read (/node_modules/rhea/lib/sasl.js:246:26)
at Connection.input (/node_modules/rhea/lib/connection.js:370:31)
at Socket.emit (events.js:107:17)
at readableAddChunk (_stream_readable.js:163:16)
at Socket.Readable.push (_stream_readable.js:126:10)
at TCP.onread (net.js:540:20)

$ node simple_send.js --help
module.js:471
throw err;
^

Error: Cannot find module './options.js'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (/home/dkornel/redhat/repos/rhea/examples/simple_send.js:22:20)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)

Hi, I get an exception when I run the following code:

`const container = require('rhea');

container.on('connection_open', function (context) {
context.connection.open_receiver('TEST');

});

container.on('message', function (context) {
console.log(context.message.body);
});

container.connect({'port':5672});`

The exception message conveys that the buffer is out of range. The exception error is the following:
`buffer.js:821
throw new RangeError('Index out of range');
^

RangeError: Index out of range
at checkOffset (buffer.js:821:11)
at Buffer.readUInt32BE (buffer.js:895:5)
at Transport.read (/home/vlima/Documents/development/nodejs/node-stomp-ws/node_
modules/rhea/lib/transport.js:74:33)
at Connection.input (/home/vlima/Documents/development/nodejs/node-stomp-ws/nod
e_modules/rhea/lib/connection.js:370:31)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
at readableAddChunk (_stream_readable.js:176:18)
at Socket.Readable.push (_stream_readable.js:134:10)
at TCP.onread (net.js:548:20)`

My use of rhea depends on uniform application output to stdout, and things such as connection errors on stdout pose a problem.

[jross@localhost quiver (master)]$ fgrep -r "console.log" javascript/node_modules/rhea/lib
javascript/node_modules/rhea/lib/terminus.js: console.log('Unknown terminus: ' + field.descriptor);
javascript/node_modules/rhea/lib/ws.js: console.log('ERROR: Attempt to set unrecognised handler on websocket wrapper: ' + event);
javascript/node_modules/rhea/lib/connection.js: console.log('[' + this.options.id + '] error: ' + e);
javascript/node_modules/rhea/lib/connection.js: console.log('[' + this.options.id + '] disconnected');
javascript/node_modules/rhea/lib/session.js: console.log('ERROR: Next pending delivery not found: ' + this.next_pending_delivery);
javascript/node_modules/rhea/lib/rpc.js: console.log('no request pending for ' + id + ', ignoring response');
javascript/node_modules/rhea/lib/link.js: if (frame.performative.link_credit > 0) console.log('ERROR: received flow with drain set, but non zero credit');
javascript/node_modules/rhea/lib/message.js: console.log("WARNING: did not recognise message section with descriptor " + s.descriptor);
javascript/node_modules/rhea/lib/message.js: console.log("WARNING: expected described message section got " + JSON.stringify(s));
javascript/node_modules/rhea/lib/message.js: console.log('unrecognised outcome: ' + JSON.stringify(outcome));

Using Rhea in a browser, I've seen occasions when the supplied "properties" were not present in the sent message. In my case, there were "properties", "application_properties", and a null body. Intermittently, the sent message would only contain the application-properties and the body.

Description:
While running the TCs in Jenkins, the "link fields source as nested object" test case fails.

Steps to reproduce:

1. mocha -g nested $rhea_inst_root/test/links.js

Actual results:
[connection-3] error: Error: connect ECONNRESET
[connection-3] disconnected
Scheduled reconnect in 100ms
․․

3 passing (37ms)
1 failing

1. link fields source as nested object:
   Uncaught TypeError: value is out of bounds
   at TypeError ()
   at checkInt (buffer.js:705:11)
   at Buffer.writeUInt32BE (buffer.js:748:5)
   at Function.write_ulong as write
   at types.Writer.write_fixed_width (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:584:14)
   at types.Writer.write_value (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:626:14)
   at types.Writer.write (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:618:10)
   at types.Writer.write_constructor (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:608:14)
   at types.Writer.write (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:617:10)
   at types.Writer.write_compound (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:653:18)
   at types.Writer.write_value (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:630:14)
   at types.Writer.write (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:618:10)
   at types.Writer.write_compound (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:653:18)
   at types.Writer.write_value (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:630:14)
   at types.Writer.write (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:618:10)
   at types.Writer.write_compound (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:653:18)
   at types.Writer.write_value (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:630:14)
   at types.Writer.write (/home/jprajzne/nodejs/node_modules/rhea/lib/types.js:618:10)
   at Object.frames.write_frame (/home/jprajzne/nodejs/node_modules/rhea/lib/frames.js:105:16)
   at Transport.encode (/home/jprajzne/nodejs/node_modules/rhea/lib/transport.js:43:25)
   at Connection._write_frame (/home/jprajzne/nodejs/node_modules/rhea/lib/connection.js:438:25)
   at Session.output (/home/jprajzne/nodejs/node_modules/rhea/lib/session.js:373:21)
   at link._process (/home/jprajzne/nodejs/node_modules/rhea/lib/link.js:89:26)
   at Session._process (/home/jprajzne/nodejs/node_modules/rhea/lib/session.js:459:27)
   at Connection._process (/home/jprajzne/nodejs/node_modules/rhea/lib/connection.js:429:39)
   at process._tickCallback (node.js:442:13)

Expected results:
The TC passes.

Note:
This TC fails with and without JBoss A-MQ 6.2.0 GA running with AMQP transport.

I'm trying to track down what appears to be a double invocation of the event handler for 'accepted' event on the link object.

I have the code: self._linkObject.on('accepted', self._acceptedHandler.bind(this))

A bit further on in the code I have:

let sendDeliveryObject = this._linkObject.send(message);

It would appear as thought the event handler is invoked before the call to .send returns. It is then invoked AGAIN when the actual message is accepted by the remote peer.

Is this expected behavior?

This avoids users having to create a link where they don't want to.

which is annoying!

I'm sending messages that should have a property that is an http-ish status code (200, 404...)

here's my message object (that I pass "as is" to sender.send()):

{
  correlation_id: context.message.correlation_id,
  body: {
    'key': 'value'
  },
  application_properties: {
    'status': 200
  }
}

it looks like on the service side the property is either not received, or not received as an Int32 - am i doing anything wrong? is the number type coerced to a smaller integer type? can I force it to Int32?

[edit] typos

We are trying to wrap events inside promises. So far the experience has been good. However at one place I was not able pass the options for setting the receiver.

May be I am doing something wrong over here (should be using some other method). Any help/guidance would be awesome.

Here is the script.

I want to use the createReceiver() like this, where I can pass in the options along with the endpoint.

const rxopt = { name: replyTo, target: { address: replyTo }};
await amqp.createReceiver(session, endpoint, rxopt);

Should this line have arguments instead of args.

When encoding an AmqpSequence with proton-j and decoding it in rhea, the following log message is displayed:

WARNING: did not recognise message section with descriptor 118

Attached is a junit test that runs a proton-j server passing the desired value to a client opening a receiver. Requires vertx-proton to build.

unittest.zip

Description:
the client connects to the server even while the credentials are incorrect

Steps to reproduce:

1. start the server with amqp connector and enabled authentication
2. provide wrong credentials: node rhea/examples/sasl/simple_sasl_client.js

Expected results:
The authentication fails

Actual results:
The connection is established without any authentication failed message:
2015-11-02 16:29:07,808 | WARN | -1, empty queue] | Transport | ivemq.broker.TransportConnection 245 | 171 - org.apache.activemq.activemq-osgi - 5.11.0.redhat-620133 | Transport Connection to: tcp://127.0.0.1:43041 failed: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>30000) long: tcp://127.0.0.1:43041

Note:
Please notice that the client is not connecting to a destination nor sending messages.

I'm seeing errors that seem to only happen on Firefox 48 on Fedora 24.
Chrome on Fedora 24 works. Firefox version 42 on Fedora 23 works.

What I expect to happen when using the attached html page is that when the connection is opened, the red "connecting..." text is replaced by the word "Connected" and then when I click on the button that a schema is returned.

I'm seeing two different behaviors :
Sometimes I get the connection_opened event but then I immediately get:
Error: Attach already received
rhea.js:1095:15
Then when I click the button to request a schema, I get:
TypeError: receiver.remote.attach is undefined
ff48fc24.html:65:17

However, sometimes I'll get a different behavior. I'll immediately get:
Error: Invalid data offset, must be at least 2 was 0
rhea.js:737:15

and then after a few seconds I get:
Error: Close already received
rhea.js:469:15
[connection-1] disconnected
rhea.js:408:13
When that happens, I never get the connection_opened event and the "connecting..." text is never replaced.

Environment:
Fedora 24
Firefox 48
websockify for proxy (but also happens when I use nodejs for proxy)
I'm opening the reproducer file directly in a browser; no web server needed.
ff48fc24.zip

Here is a log message when sending a disposition to a peer:

rhea:frames [connection-1] PENDING: '{"channel":0,"type":0,"performative":[true,0,0,true,[]]}' +22ms
rhea:raw [connection-1] SENT: <Buffer 00 00 00 1c 02 00 00 00 00 53 15 d0 00 00 00 0c 00 00 00 05 41 43 43 41 00 53 24 45> +110ms

The frame log really doesn't say that the performative is a dispostion. You can look at the raw message to follow and see the 53 that indicates that the message is a disposition. Additionally it doesn't give the values for role, settled, or state.

However, here is a disposition incoming from a peer:
rhea:frames [connection-1] RECV: '{"size":23,"type":0,"channel":0,"performative":{"type":"disposition#15","role":true,"settled":true,"state":[]}}' +83ms

It does all those things.

Why the difference?

I was having a problem with a particular operation I was sending over rhea.

I was sending a message_annotation: It was created thus:

The value of method is: 'GET'

amqpMessage.message_annotations = {
  operation: method
};

This is serialized out by rhea as:
a1096f7065726174696f6ea103474554

The property using amqp10 serializes:

a3096f7065726174696f6ea103474554

Note that it appears that for amqp10 the operation property name is defined as a symbol whereas for rhea it is defined as a string.

Any thoughts on why this might have serialized differently?

Description:
A-MQ 6.2 GA broker logs Java EOF on simple_sender.js connection attempt

Actual results:
2015-10-21 16:19:09,407 | WARN | 0.0.1:36674@5672 | Transport | ivemq.broker.TransportConnection 245 | 171 - org.apache.activemq.activemq-osgi - 5.11.0.redhat-620133 | Transport Connection to: tcp://127.0.0.1:36674 failed: java.io.EOFException

Expected results:
Successful connection made to the broker

Steps to reproduce:

• start JBoss A-MQ 6.2 GA broker listening on amqp://127.0.0.1:5672
• node rhea/examples/simple_sender.js
• inspect broker log $inst_root/data/log/amq.log or log:display in Karaf console

Description:
direct_recv doesn't receive after simple_recv connects and disconnects.

How reproducible:
Always

Steps to Reproduce:

1. node $inst_root/rhea/examples/direct_recv.js -p 61616 in 1st terminal
2. node $inst_root/rhea/examples/simple_recv.js -p 61616 in 2nd terminal
3. kill the simple_recv in 2nd terminal
4. node $inst_root/rhea/examples/simple_send.js -p 61616

Actual results:
Following error is thrown:
[connection-1] disconnected

[connection-2] error: Error: write after end
[connection-2] disconnected

Expected results:
The direct_recv receives incoming message(s)

Looks like here you encode the body as an AMQP value no matter what - is there a way for the user to force encoding to binary or sequence?

In node-amqp10 it looks like the library tries to infer the type based on the type of the body - i don't know if it is a good idea or not?

how do I force the body of a message to be encoded as binary data?

Hi, I used your library in a hackathon for using Hono.
I'm using this code: https://github.com/bsinno/bcx2017/tree/master/Hono_Example_Clients/Hono-Node.js
I realized that I get sometimes these errors:

uncaught exception:  Error: circular buffer overflow: head=10 tail=10 size=2048 capacity=2048
    at CircularBuffer.push (/Users/timaschew/dev/iot-hackathon/hono-node-client/node_modules/rhea/lib/session.js:46:15)
    at Incoming.on_transfer (/Users/timaschew/dev/iot-hackathon/hono-node-client/node_modules/rhea/lib/session.js:303:29)
    at Session.on_transfer (/Users/timaschew/dev/iot-hackathon/hono-node-client/node_modules/rhea/lib/session.js:618:19)
    at Connection.(anonymous function) [as on_transfer] (/Users/timaschew/dev/iot-hackathon/hono-node-client/node_modules/rhea/lib/connection.js:642:30)
    at c.dispatch (/Users/timaschew/dev/iot-hackathon/hono-node-client/node_modules/rhea/lib/types.js:902:33)
    at Transport.read (/Users/timaschew/dev/iot-hackathon/hono-node-client/node_modules/rhea/lib/transport.js:95:36)
    at SaslClient.read (/Users/timaschew/dev/iot-hackathon/hono-node-client/node_modules/rhea/lib/sasl.js:243:26)
    at Connection.input (/Users/timaschew/dev/iot-hackathon/hono-node-client/node_modules/rhea/lib/connection.js:420:35)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)