On 27 February 2016 at 16:20, Randy Armstrong <ra...@sparhawksoftware.com> wrote: > 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. >
Glad you got things working. What Messenger was doing beforehand is actually valid protocol behaviour, albeit not behaviour I particularly like personally, and evidently not something ServiceBus handles. The JIRA about the disposition state behaviour is there as mentioned, though I think folks involved with Messenger closed similar reports previously as expected behaviour. > 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. In this case what the SASL bits are doing seems valid/expected given the info available, just not what is desired. There is again an open JIRA to add additional mechanism selection functionality to Messenger as Andrew mentioned but has yet to be picked up, since as mentioned most folks attention is for the most part focused on newer reactive API work in Proton rather than on the Messenger API. > > -----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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
