by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Matt Broadstone
    @mbroadst
    I'm going to hold off on a minor release for a few days in order to see if we can get a fix in for Jeff Mcaffer, is that okay with you? You can just point to the #master branch for the time being
    I'll set a hard deadline of Wednesday to push the release
    Pierre Cauchois
    @pierreca
    @mbroadst you're the boss :) I'm all for more fixes, and at that point all the work that relies on that feature is done so I can wait 2 or 3 more days. less releases means it's easier to follow for me too, so no problem
    if there's a risk that it drifts past wednesday I'll reevaluate but wednesday seems fine by me
    Matt Broadstone
    @mbroadst
    @pierreca looks like all that stuff is ballooning nicely, I'll go ahead and push a minor release for your stuff tonight
    Matt Broadstone
    @mbroadst
    @pierreca v3.5.0 has been tagged and published
    Pierre Cauchois
    @pierreca
    thanks @mbroadst much appreciated
    Anthony V. Ercolano
    @anthonyvercolano
    Folks an opinion if you will: We got an error report from a user with the following stack trace fragment:
    message: 'AMQP Transport: Could not connect',
     amqpError:
     { AmqpError: SASL Failed: 2: undefined
     at Sasl._processFrame (/home/.../tcpGateway/node_modules/amqp10/lib/sasl.js:102:21)
     at Connection._processFrameEH (/home/.../tcpGateway/node_modules/amqp10/lib/sasl.js:43:49)
     at emitOne (events.js:96:13)

    This is with a client that has been connected for a while and we are renewing the authentication on a periodic basis by disconnect and doing a new connnect.
    This is on an ubuntu 14.04 machine.

    We see that the frame type for the message is 2. Is this a reasonable value for a correct SASL response for server? Or are we seeing some sort of mangled packet from a diconnected link?

    Matt Broadstone
    @mbroadst
    @anthonyvercolano the only frame types defined in the spec are 0x00 for AMQP and 0x01 for SASL, so I would guess the latter
    Pierre Cauchois
    @pierreca
    @mbroadst how do you maintain your typings? i'm moving the iothub SDK to typescript, looks like the typings are stuck on 3.3.1, maybe I can help?
    Jeff Principe
    @princjef
    Looks like there's a regression in 3.5.1
    When calling send() and waiting for acknowledgement, the promise never resolves. Looking at it with amqp10:framing on, the transfer is sent but we never get a disposition back. Verified that bumping back to 3.5.0 fixes it
    side note: the => and <= in the framing logs are much easier to scan than looking for sent or received :)
    @pierreca I'm pretty sure the typings are maintained by someone else. I submitted the PR to bump it to 3.3.1 a few months back but it took a while for the maintainer to merge it in
    Jeff Principe
    @princjef
    I think I found it. Looking at noodlefrenzy/node-amqp10@f3c4617, the settings for receiverSettleMode and senderSettleMode have changed to rcvSettleMode and sndSettleMode, respectively. Problem is custom policies that specified them manually will now revert to the defaults because the value is considered unset. Seems like a breaking change
    Jeff Principe
    @princjef
    Strange thing is that I'm using the ServiceBusQueue policy for the sender without modifying the settle mode and yet i get a mixed settle mode in 3.5.0 and a settled settle mode in 3.5.1. Not sure why since the value is settled in that config for both versions
    Matt Broadstone
    @mbroadst
    @pierreca yah I don't generate those typings, I would totally take a PR to generate them in-tree as part of our release process though
    @princjef yeah sorry for the breaking change, I'm still a little mystified as to how the settings worked in the first place
    @princjef in fact I think what you're seeing wrt mixed settle mode has technically always been the default in the policy, but it was never sent because we weren't sending the correct field name :|
    Matt Broadstone
    @mbroadst
    @/all apologies for the botched release, please update to v3.5.2 to fix the issue @princjef pointed out
    Pierre Cauchois
    @pierreca
    @mbroadst would you be ok having the d.ts files in the npm package along with the .js files? That's what we did with the IoT hub SDK I find that easier to manage than a separate repo
    Matt Broadstone
    @mbroadst
    yep, that's what I was saying above
    Pierre Cauchois
    @pierreca
    Well there are like 3 or 4 ways to distribute typings, just wanted to make sure :)
    Dominic Evans
    @dnwe
    @mbroadst thanks for pushing that deprecated names handling thing so speedily, much appreciated
    whilst I was looking over the code I did notice another thing (always been this way I think, just hadn't noticed it until now)
    noodlefrenzy/node-amqp10#316
    Anthony V. Ercolano
    @anthonyvercolano
    Quick question, the settle mode property on a link. Are they actually called rcvSettleMode and sndSettleMode? That's the name of the field that gets dumped during debug. I just noticed that when we set up policies on our amqp10 client constructure we pass in receiverSettleMode.
    Anthony V. Ercolano
    @anthonyvercolano

    Hi, I am trying to add annotations to a message we're sending up to the IoT Hub. Initially I simply added an annotation to the amqp message I was sending to the hub. However it now appears that it isn't serializing this into the actual frame that is getting sent out.

    ```
    Wed, 31 May 2017 23:01:39 GMT amqp10:link:sender sending: AmqpMessage {
    properties: { correlationId: 'd64daa1a-021e-4488-8c15-a5f47b2e5595' },
    body: <Buffer 20>,
    annotations:
    { operation: 'PUT',
    resource: '/notifications/twin/properties/desired' } }

    However, if one looks at the raw frame that gets serialize out you get
    Wed, 31 May 2017 23:01:39 GMT amqp10:trace raw: [0000005c02000001005314c0110b52035202a00132434242500040424242005373c0330d4040404040a12464363464616131612d303231652d343438382d386331352d61356634376232653535393540404040404040005375a00120]

    If you look at the hex you don't see the PUT or the resource field.

    I've also tried to add these annotations via the options parameter to .send. You end up with the same frame. Any thoughts on what I should be doing to send annotations?
    Anthony V. Ercolano
    @anthonyvercolano
    Ah! It appears as though if you want annotations to get serialized into the message you have to call them messageAnnotations. This is if you hard place them in the message or even if you pass them in via the options. You still have to call them messageAnnotations.
    Anthony V. Ercolano
    @anthonyvercolano
    Hi, anyone have an idea about how I can force a particular number to be serialized into as an actual long? If I do something like (<any>amqp10).Type.long(item.value) it will test if item.value is a small number, and if so, it will only use two bytes rather than for full 8. Thoughts?
    Anthony V. Ercolano
    @anthonyvercolano
    Actually, my previous statement is incorrect. Useing the above "typing" construction, I actually end up with a map. The map two key/value pairs, typename: long and value: 24. What I believe my peer expects to see is instead of a map it wants descripter of 0x81 followed by the networked ordered signed 8 byte quantity.
    Dominic Evans
    @dnwe
    @mbroadst fyi, just raised mbroadst/amqp10-link-cache#15 – looks wrong to my eyes, but see what you think :)
    Jeff Principe
    @princjef
    We've been having some intermittent issues using amqp10 with Service Bus over the past few months. In chatting with the Service Bus folks, we found out that they expect almost every link to receive its own session, rather than grouping them all into the same session on a single connection. I've created noodlefrenzy/node-amqp10#331 to discuss how to address the multiple session pattern in amqp10 with a proposed approach. I'd love to hear feedback anyone has about the issue or potential solutions.
    Suresh Mahawar
    @SuresaMahawar

    https://stackoverflow.com/questions/48335617/feasibility-of-improving-publish-rate-rabbitmq-queue-in-nodejs
    I have improved the published rate in Rabbitmq queue via following options

    1. persistent: false
    2. durable: false
    3. removing confirm.select method

    BTW I need to use 2 & 3 options (durable: true and createChannel in confirm mode)

    Is there any other possibility to more improve publish rate in Nodejs via increasing no of the channel?

    I have gone through it channels in Rabbitmq

    Some applications need multiple connections to an AMQP broker. However, it is undesirable to keep many TCP connections open at the same time because doing so consumes system resources and makes it more difficult to configure firewalls. AMQP 0-9-1 connections are multiplexed with channels that can be thought of as "lightweight connections that share a single TCP connection".

    For applications that use multiple threads/processes for processing, it is very common to open a new channel per thread/process and not share channels between them.

    Communication on a particular channel is completely separate from communication on another channel, therefore every AMQP method also carries a channel number that clients use to figure out which channel the method is for (and thus, which event handler needs to be invoked, for example).

    But here I have confused about using no of channels in Nodejs. As we know that Nodejs is single threaded, so if we increase no of channels to publish into rabbitmq. Does it really improve the published rate? If not so, Should I have to use multi-threaded language like Golang?

    Alex
    @ajbeach2
    hey so i can't get this library to work with with Bus Queues with sessions enabled
    I am following the exmple in the docs for the service-bus-queus
    however
    ===> RX ERROR:  { AmqpProtocolError: amqp:not-allowed:It is not possible for an entity that requires sessions to create a non-sessionful message receiver
    that is the error message i am getting
    as the example
    Alex
    @ajbeach2
    how do i enable sessions?
    Alex
    @ajbeach2
    anyone?
    Nissim Kurle
    @nissim-kurle
    Hi
    Johannes Haposan Napitupulu
    @haposan06
    Hi. Best practise when using channel is use 1 channel per thread. But since Nodejs single treaded, we can rule that out. But for best practise about connection, which is best to separate connection for publisher and consumer, do nodeJs application follow that rule also? I assume since TCP connection is lower level than nodeJs app, we still should follow that rule. But I need confirmation