Setting the incoming message window and explicitly accepting the messages fixed the problem.
That said, I think there are bugs that need fixing even if there is a work around. Also, I did have to change the Proton code that selected the SASL mechanism so PLAIN was checked first. This could use a new API because pn_messenger_set_flags(messenger, PN_FLAGS_ALLOW_INSECURE_MECHS) is not enough. -----Original Message----- From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Sent: Friday, February 26, 2016 4:53 AM To: users@qpid.apache.org Subject: Re: ServiceBus and Proton-C 0.12 IOP Issue On 26 February 2016 at 12:46, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > On 25 February 2016 at 23:18, Randy Armstrong > <ra...@sparhawksoftware.com> wrote: >> I think it is related to proton because the exact same messages using the >> exact same credentials are processed by an AMQPlite client running at the >> same time. >> > > I think what Andrew meant is that as the error seems to be coming from > the ServiceBus side and there doesnt seem to be anything suggesting > that the Proton side is unhappy, though Messenger may be doing > somthing that ServiceBus isn't happy. > >> I am assuming it is related to how the message is constructed because an >> error that affected all ServiceBus clients should have been seen before my >> report. >> >> The text 'System.ArgumentNullException: Value cannot be null' comes from a >> .NET library (it is the standard error text for a null pointer passed to a >> function). >> So the error is on the ServiceBus side but it is related to something the >> proton library is sending. >> Maybe related to an ACK for the message? > > I think it could indeed be the ack. You can see from the trace that > Messenger sends a disposition frame back for a message. The next thing > that arrives is the detach saying there is an 'issue with the > consumer'. > > [00AADD40]:0 -> @disposition(21) [role=true, first=0, last=0, > settled=true] > > This disposition has no state set in it, which ServiceBus may not > like, though it is legal. > Somehow sent that mail before I was finished, not actually sure how either. I was about to say.. That is something Messenger seems to do if you dont configure an 'incoming window' so you can explicitly accept/reject messages (https://issues.apache.org/jira/browse/PROTON-841) so you could try setting the window and accepting the messages to see if that helps. As Andrew said, most developer attention is going toward the newer reactive APIs rather than Messenger, so if you are just starting out you might be better looking towards those instead. Robbie >> >> -----Original Message----- >> From: Andrew Stitcher [mailto:astitc...@redhat.com] >> Sent: Thursday, February 25, 2016 2:51 PM >> To: users@qpid.apache.org >> Subject: Re: ServiceBus and Proton-C 0.12 IOP Issue >> >> On Thu, 2016-02-25 at 14:26 -0800, Randy Armstrong wrote: >>> ... >>> I then get what looks like a NULL pointer error from .NET: >> >> It doesn't look like that to me (but I know very little about how Azure >> works). >> >>> ... >>> [00AADD40]:0 <- @detach(22) [handle=0, closed=true, error=@error(29) >>> [condition=:"amqp:link:detach-forced", description="The link >>> 'G12:16548697:MyTopic/Subscriptions/default' is force detached by >>> the broker due to errors occurred in consumer(link39638). Detach origin: >>> ExceptionId: 1d35d46d-a26d-493e-8b1c-a01ffbe0cdad- >>> System.ArgumentNullException: Value cannot be null.\x0d\x0aParameter >>> name: collection. >>> TrackingId:44365b430002001000009ad656cf7eb9_G12_B31,TimeStamp:2/25/2 >>> 0 >>> 16 10:23:01 PM"]] >> >> This is the Azure broker force closing the link with an error. The error >> from the Azure end seems to be: >> >> System.ArgumentNullException: Value cannot be null. >> Parameter name: collection. >> >> With some tracking information around it. >> >> So I think Azure is telling you that there needs to be a non null collection >> parameter (whatever that is). >> >> Perhaps someone with knowledge of Servicebus can make some informed comments. >> >>> I am guessing this is because my message is missing a field that >>> proton expects. >> >> Why do think it's to do with proton? >> >> Andrew >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For >> additional commands, e-mail: users-h...@qpid.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For >> additional commands, e-mail: users-h...@qpid.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
