amqp / rhea Goto Github PK
View Code? Open in Web Editor NEWA reactive messaging library based on the AMQP protocol
License: Apache License 2.0
A reactive messaging library based on the AMQP protocol
License: Apache License 2.0
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
Hello,
I was looking at the node-amqp10 library and this one. I wanted to know
It would be fine if I had to temporarily adjust the source.
This avoids users having to create a link where they don't want to.
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:
direct_recv doesn't receive after simple_recv connects and disconnects.
How reproducible:
Always
Steps to Reproduce:
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)
which is annoying!
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?
i.e. provide for simple one-line execution of all examples
$ 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)
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,
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
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.
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 )
I think it'd be great to increase the coverage.
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.
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.
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?
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)`
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. 😄
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)
Description:
While running the TCs in Jenkins, the "link fields source as nested object" test case fails.
Steps to reproduce:
Actual results:
[connection-3] error: Error: connect ECONNRESET
[connection-3] disconnected
Scheduled reconnect in 100ms
․․
3 passing (37ms)
1 failing
Expected results:
The TC passes.
Note:
This TC fails with and without JBoss A-MQ 6.2.0 GA running with AMQP transport.
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.
Description:
the client connects to the server even while the credentials are incorrect
Steps to reproduce:
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.
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.
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
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?
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?
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?
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)'
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?
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.
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.
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)
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.
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));
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
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
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?
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?
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:
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.