Re: [VOTE] Release Qpid Proton 0.13.1
+1 Tested: pyngus unit tests (python 2.7 and 3.4) oslo.messaging unit and functional tests for AMQP 1.0 driver rsyslog output module - Original Message - > From: "Justin Ross" > To: users@qpid.apache.org > Sent: Friday, July 1, 2016 10:20:01 PM > Subject: [VOTE] Release Qpid Proton 0.13.1 > > Hi, folks. Here is an RC for 0.13.1. Please test and place your vote. > > Source distribution: > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.13.1-rc/ > > Maven staging repo: > > https://repository.apache.org/content/repositories/orgapacheqpid-1082 > > Changes since 0.13.0: > > > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=log;h=refs/tags/0.13.1-rc > > These are signed and ready for GA if approved by vote. I'll close the vote > on July 11th. > > Thanks, > Justin > -- -K - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Issue when using CMake to install Qpid broker
No I don't think so. Steve Huston (sent from my iPhone - please excuse brevity and typos) > On Jul 6, 2016, at 3:32 PM, loremIpsum1771 wrote: > > I'm not sure. I just tried deleting the cache from the CMake GUI and I then > re-ran: cmake -G "Visual Studio 12 2013" > C:\Users\I664761\Downloads\qpid-cpp-0.34 but the filepath seems to still be > the same. I have both Cmake and Boost in my downloads folder and I can't > move them to program files because I don't have admin access on my computer. > Could that be causing the problem? > > > > -- > View this message in context: > http://qpid.2158936.n2.nabble.com/Issue-when-using-CMake-to-install-Qpid-broker-tp7646766p7646949.html > Sent from the Apache Qpid users mailing list archive at Nabble.com. > > - > 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
RE: Issue when using CMake to install Qpid broker
I'm not sure. I just tried deleting the cache from the CMake GUI and I then re-ran: cmake -G "Visual Studio 12 2013" C:\Users\I664761\Downloads\qpid-cpp-0.34 but the filepath seems to still be the same. I have both Cmake and Boost in my downloads folder and I can't move them to program files because I don't have admin access on my computer. Could that be causing the problem? -- View this message in context: http://qpid.2158936.n2.nabble.com/Issue-when-using-CMake-to-install-Qpid-broker-tp7646766p7646949.html Sent from the Apache Qpid users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: Issue when using CMake to install Qpid broker
Not Boost... the cmake cache in your qpid build stores that stuff. You can either run the cmake gui and delete those variables, or delete the whole cache file. > -Original Message- > From: loremIpsum1771 [mailto:celij...@gmail.com] > Sent: Wednesday, July 06, 2016 2:53 PM > To: users@qpid.apache.org > Subject: RE: Issue when using CMake to install Qpid broker > > Ok I tried deleting the environment variable for BOOST_ROOT and creating it > again as it is currently set to C://Downloads/boost_1_61_0 but for > some reason, whenever I run CMake, I still get the same error with the same > file path showing up so I'm not really sure what's going on. I also tried > running > set BOOST_ROOT="C:\Users\I664761\Downloads\boost_1_61_0\boost" but > it doesn't seem to have done anything. Is there some specific way that Boost > internally stores the root location? > > > > -- > View this message in context: http://qpid.2158936.n2.nabble.com/Issue- > when-using-CMake-to-install-Qpid-broker-tp7646766p7646942.html > Sent from the Apache Qpid users mailing list archive at Nabble.com. > > - > 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
RE: Issue when using CMake to install Qpid broker
Ok I tried deleting the environment variable for BOOST_ROOT and creating it again as it is currently set to C://Downloads/boost_1_61_0 but for some reason, whenever I run CMake, I still get the same error with the same file path showing up so I'm not really sure what's going on. I also tried running set BOOST_ROOT="C:\Users\I664761\Downloads\boost_1_61_0\boost" but it doesn't seem to have done anything. Is there some specific way that Boost internally stores the root location? -- View this message in context: http://qpid.2158936.n2.nabble.com/Issue-when-using-CMake-to-install-Qpid-broker-tp7646766p7646942.html Sent from the Apache Qpid users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: Issue when using CMake to install Qpid broker
The CMake find module for Boost is rather finicky. The BOOST_ROOT env variable should be set to the 'root', which is the directory above the one where your boost library binaries are. If that doesn't work, try setting BOOST_LIBRARYDIR explicitly - that is more direct. -Steve > -Original Message- > From: loremIpsum1771 [mailto:celij...@gmail.com] > Sent: Wednesday, July 06, 2016 1:56 PM > To: users@qpid.apache.org > Subject: Re: Issue when using CMake to install Qpid broker > > Oh ok, it seems that those missing packages are in fact not causing a > problem. For some reason though, it seems that CMake is able to find only > some of the Boost libraries, but not others: > https://gist.github.com/loremIpsum1771/fc1d912bbe5a741325cdd259f7a538 > 37 > > I created the BOOST_ROOT environment variable and set it to: > C:\Users\I664761\Downloads\boost_1_61_0\boost which is where all of the > Boost libraries are (e.g. math, log, random) but it seems that CMake isn't > recognizing the directory. Is this the correct filepath to be using? > > > > -- > View this message in context: http://qpid.2158936.n2.nabble.com/Issue- > when-using-CMake-to-install-Qpid-broker-tp7646766p7646940.html > Sent from the Apache Qpid users mailing list archive at Nabble.com. > > - > 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
Re: Issue when using CMake to install Qpid broker
Oh ok, it seems that those missing packages are in fact not causing a problem. For some reason though, it seems that CMake is able to find only some of the Boost libraries, but not others: https://gist.github.com/loremIpsum1771/fc1d912bbe5a741325cdd259f7a53837 I created the BOOST_ROOT environment variable and set it to: C:\Users\I664761\Downloads\boost_1_61_0\boost which is where all of the Boost libraries are (e.g. math, log, random) but it seems that CMake isn't recognizing the directory. Is this the correct filepath to be using? -- View this message in context: http://qpid.2158936.n2.nabble.com/Issue-when-using-CMake-to-install-Qpid-broker-tp7646766p7646940.html Sent from the Apache Qpid users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Release Qpid Proton 0.13.1
On 6 July 2016 at 17:13, Andrew Stitcher wrote: > >> NOTE: gpg gave me this: >> >> gpg --verify qpid-proton-0.13.1.tar.gz.asc qpid-proton-0.13.1.tar.gz >> gpg: Signature made Fri 01 Jul 2016 10:08:26 PM EDT using RSA key ID >> C6B459DB >> gpg: Good signature from "Justin Ross (CODE SIGNING KEY) > e.org>" >> gpg: WARNING: This key is not certified with a trusted signature! >> gpg: There is no indication that the signature belongs to >> the owner. >> Primary key fingerprint: F1B5 7706 904F AD58 4D55 21D5 648A 8E57 >> C6B4 59DB >> >> I don't usually do the .asc check so I don't know if this is normal. > > I think this means that you personnally don't trust that the signature > belongs to who it says it belongs to and is not forged. > > So you need to verify p2p that the key actually belongs to Justin and > mark it trusted yourself, then you won't get the message. > > Andrew > Its configurable what it means I believe with things like whether you signed it, a chain of people you trust [to differing degree] signed it, etc, all contributing. A quick google gives https://www.gnupg.org/gph/en/manual.html#AEN346 and https://www.gnupg.org/gph/en/manual.html#AEN385 We should probably do better at cross-signing to aid in avoiding this. That fact the key is available direct from an ASF server (vs some other) gives a little more confidence than if otherwise, but cross signing more would be an improvement. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
On 6 July 2016 at 17:57, Gordon Sim wrote: > On 06/07/16 17:42, Gordon Sim wrote: >> >> On 06/07/16 17:14, Dale Green wrote: >>> >>> I have an update on this issue. >>> >>> According to Microsoft, state=Released is supported and now I can confirm >>> that this is true. If the message is released during the lifetime of the >>> consumer (before Detach), the same message is immediately unlocked and is >>> available for the same consumer or others depending on the credit. >>> >>> However, what happens with Qpid JMS is that messageConsumer.close() first >>> sends a Detach frame and after that the Disposition frames if any. Is >>> this >>> correct from protocol point of view, as Service Bus seems to ignore such >>> dispositions? >> >> >> The spec says: >> >> The disposition performative MAY refer to deliveries on links >> that are no longer attached. As long as the links have not been >> closed or detached with an error then the deliveries are still >> “live” and the updated state MUST be applied. >> >> If the Detach sent by the client has closed=true, then I would think >> that the deliveries associated with that link are implicitly ended. If >> this is the case, then the client has a bug. > > > Just to clarify on this last part. All I meant is that any disposition sent > after the close would not have any effect. So if the client intends to > explicitly release it should do so before closing. > Agreed. Thats was part of my overly elaborate deleted reply hehe. As I say, it isnt actually the client doing the releasing, but proton. To do the releases explicitly the client would currently first need to drain the credit first, which we have already established would fail agaisnt ServiceBus from earlier mails in the thread. > >> (If the closed flag was false, then I would think it would depend on the >> expiry-policy for the link's source). >> >>> Is there any way to set the credit to 0, send the Dispositions, and then >>> Detach? >> >> >> >> - >> 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
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
On 6 July 2016 at 17:50, Robbie Gemmell wrote:
> Hi Dale,
>
> It isnt invalid from a protocol perspective, as dispositions only
> actually refer to session-scoped information, not link
> (consumer/producer) scoped information. I deleted an overly
> complicated description of why that is. ServiceBus isnt
> necessarily wrong in ignoring the dispositions given some of those
> complicated bits I've deleted (in parts to do with things Gordon
> referred to), but in doing so it itself indicating the messages should
> not be locked any more: if the dispositions are ignored, then noone
> can release or consume those messages at that point, so why continue
> to lock them?
>
> The client doesnt currently reduce credit to 0 before detaching as
> doing so would only mainly just add an extra round trip to the
> process.
Well, to be entirely accurate, it does have one way, configuring 0
prefetch, thats just not possible here as it cant worth against
ServiceBus. Thats also the same mechanism we would likely use to
implement such behaviour in the non-0 prefetch case though, meaning
that approach also wouldnt work against ServiceBus currently.
>
> (As an aside, it is actually Proton sending the disposistions
> implicitly rather than the client doing so directly)
>
> Robbie
>
> On 6 July 2016 at 17:14, Dale Green wrote:
>> I have an update on this issue.
>>
>> According to Microsoft, state=Released is supported and now I can confirm
>> that this is true. If the message is released during the lifetime of the
>> consumer (before Detach), the same message is immediately unlocked and is
>> available for the same consumer or others depending on the credit.
>>
>> However, what happens with Qpid JMS is that messageConsumer.close() first
>> sends a Detach frame and after that the Disposition frames if any. Is this
>> correct from protocol point of view, as Service Bus seems to ignore such
>> dispositions?
>>
>> Is there any way to set the credit to 0, send the Dispositions, and then
>> Detach?
>>
>> Thanks!
>>
>> On Thu, Jun 30, 2016 at 4:59 PM, Robbie Gemmell
>> wrote:
>>
>>> Thanks for the update. That seems to confirm that theres not much the
>>> client can do to help here, as both of the mechanisms it could use to
>>> assist in this situation (explicitly releasing unconsumed messages, or
>>> doing no prefetching to begin with) appear to be running into server
>>> bugs, in this case the snippet Gordon linked to.
>>>
>>> Robbie
>>>
>>> On 30 June 2016 at 15:42, Dale Green wrote:
>>> > Sorry for the misunderstanding: The code I was testing is actually
>>> closing
>>> > the consumer explicitly.
>>> >
>>> > However, I tested now the Receiver example and can confirm, that it
>>> doesn't
>>> > matter for the server if the consumer is closed or not.
>>> > I can see that
>>> > messageConsumer.close();
>>> > produces such log lines for the prefetched messages:
>>> > SENT: Disposition{role=RECEIVER, first=7, last=7, settled=true,
>>> > state=Released{}, batchable=false}
>>> >
>>> > But the same messages are still locked for the lock duration.
>>> >
>>> >
>>> > On Thu, Jun 30, 2016 at 1:13 AM, Robbie Gemmell <
>>> robbie.gemm...@gmail.com>
>>> > wrote:
>>> >
>>> >> On 29 June 2016 at 11:08, Dale Green wrote:
>>> >> > Hi Robbie,
>>> >> >
>>> >> > Thanks for the hints! I couldn't solve my problems, but let me leave
>>> some
>>> >> > more info, which can be useful for other people.
>>> >> >
>>> >> > Closing the consumer explicitly didn't help (it's closed on session
>>> close
>>> >> > anyway). However, I have the feeling that the lifetime of the consumer
>>> >> does
>>> >> > not affect the peek lock (imagine a long-running consumer: it doesn't
>>> >> lock
>>> >> > the messages for longer than the lock duration).
>>> >> >
>>> >>
>>> >> After sending my last reply to Gordon, I noticed something in your
>>> >> wording that I'd now like to double check. When I asked if you tried
>>> >> closing the consumer explicitly I meant before closing the session
>>> >> object, i.e:
>>> >> consumer.close();
>>> >> session.close();
>>> >>
>>> >> Can you confirm that is what you updated your code to do?
>>> >>
>>> >> > Setting the prefetch value to 1 didn't help as the next message comes
>>> to
>>> >> > the consumer immediately after receive(). So, there could be 0 or 1
>>> >> locked
>>> >> > messages after each consumer.
>>> >> >
>>> >> > Setting the prefetch value to 0 brings me back to the drain problem:
>>> >> > Service Bus doesn't answer anything after the sent packet with
>>> >> 'drain=true'
>>> >> > , so receive() is blocked forever. However, there are some (probably
>>> >> empty)
>>> >> > AMQP packets sent after some time, but Qpid doesn't send anything
>>> >> anymore.
>>> >> >
>>> >> >
>>> >> > On Tue, Jun 28, 2016 at 6:34 PM, Robbie Gemmell <
>>> >> robbie.gemm...@gmail.com>
>>> >> > wrote:
>>> >> >
>>> >> >> On 28 June 2016 at 17:00, Dale Green
>>> wrote:
>>> >> >> > Hi people,
>>> >> >> >
>>> >> >> > I have a problem using Qpid JMS 0.9 with
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
On 06/07/16 17:57, Gordon Sim wrote: On 06/07/16 17:42, Gordon Sim wrote: On 06/07/16 17:14, Dale Green wrote: I have an update on this issue. According to Microsoft, state=Released is supported and now I can confirm that this is true. If the message is released during the lifetime of the consumer (before Detach), the same message is immediately unlocked and is available for the same consumer or others depending on the credit. However, what happens with Qpid JMS is that messageConsumer.close() first sends a Detach frame and after that the Disposition frames if any. Is this correct from protocol point of view, as Service Bus seems to ignore such dispositions? The spec says: The disposition performative MAY refer to deliveries on links that are no longer attached. As long as the links have not been closed or detached with an error then the deliveries are still “live” and the updated state MUST be applied. If the Detach sent by the client has closed=true, then I would think that the deliveries associated with that link are implicitly ended. If this is the case, then the client has a bug. Just to clarify on this last part. All I meant is that any disposition sent after the close would not have any effect. So if the client intends to explicitly release it should do so before closing. And if the link is indeed closed, then arguably it makes no sense for the server to keep any unsettled messages on it in the locked state. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
On 06/07/16 17:42, Gordon Sim wrote: On 06/07/16 17:14, Dale Green wrote: I have an update on this issue. According to Microsoft, state=Released is supported and now I can confirm that this is true. If the message is released during the lifetime of the consumer (before Detach), the same message is immediately unlocked and is available for the same consumer or others depending on the credit. However, what happens with Qpid JMS is that messageConsumer.close() first sends a Detach frame and after that the Disposition frames if any. Is this correct from protocol point of view, as Service Bus seems to ignore such dispositions? The spec says: The disposition performative MAY refer to deliveries on links that are no longer attached. As long as the links have not been closed or detached with an error then the deliveries are still “live” and the updated state MUST be applied. If the Detach sent by the client has closed=true, then I would think that the deliveries associated with that link are implicitly ended. If this is the case, then the client has a bug. Just to clarify on this last part. All I meant is that any disposition sent after the close would not have any effect. So if the client intends to explicitly release it should do so before closing. (If the closed flag was false, then I would think it would depend on the expiry-policy for the link's source). Is there any way to set the credit to 0, send the Dispositions, and then Detach? - 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
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
Hi Dale,
It isnt invalid from a protocol perspective, as dispositions only
actually refer to session-scoped information, not link
(consumer/producer) scoped information. I deleted an overly
complicated description of why that is. ServiceBus isnt
necessarily wrong in ignoring the dispositions given some of those
complicated bits I've deleted (in parts to do with things Gordon
referred to), but in doing so it itself indicating the messages should
not be locked any more: if the dispositions are ignored, then noone
can release or consume those messages at that point, so why continue
to lock them?
The client doesnt currently reduce credit to 0 before detaching as
doing so would only mainly just add an extra round trip to the
process.
(As an aside, it is actually Proton sending the disposistions
implicitly rather than the client doing so directly)
Robbie
On 6 July 2016 at 17:14, Dale Green wrote:
> I have an update on this issue.
>
> According to Microsoft, state=Released is supported and now I can confirm
> that this is true. If the message is released during the lifetime of the
> consumer (before Detach), the same message is immediately unlocked and is
> available for the same consumer or others depending on the credit.
>
> However, what happens with Qpid JMS is that messageConsumer.close() first
> sends a Detach frame and after that the Disposition frames if any. Is this
> correct from protocol point of view, as Service Bus seems to ignore such
> dispositions?
>
> Is there any way to set the credit to 0, send the Dispositions, and then
> Detach?
>
> Thanks!
>
> On Thu, Jun 30, 2016 at 4:59 PM, Robbie Gemmell
> wrote:
>
>> Thanks for the update. That seems to confirm that theres not much the
>> client can do to help here, as both of the mechanisms it could use to
>> assist in this situation (explicitly releasing unconsumed messages, or
>> doing no prefetching to begin with) appear to be running into server
>> bugs, in this case the snippet Gordon linked to.
>>
>> Robbie
>>
>> On 30 June 2016 at 15:42, Dale Green wrote:
>> > Sorry for the misunderstanding: The code I was testing is actually
>> closing
>> > the consumer explicitly.
>> >
>> > However, I tested now the Receiver example and can confirm, that it
>> doesn't
>> > matter for the server if the consumer is closed or not.
>> > I can see that
>> > messageConsumer.close();
>> > produces such log lines for the prefetched messages:
>> > SENT: Disposition{role=RECEIVER, first=7, last=7, settled=true,
>> > state=Released{}, batchable=false}
>> >
>> > But the same messages are still locked for the lock duration.
>> >
>> >
>> > On Thu, Jun 30, 2016 at 1:13 AM, Robbie Gemmell <
>> robbie.gemm...@gmail.com>
>> > wrote:
>> >
>> >> On 29 June 2016 at 11:08, Dale Green wrote:
>> >> > Hi Robbie,
>> >> >
>> >> > Thanks for the hints! I couldn't solve my problems, but let me leave
>> some
>> >> > more info, which can be useful for other people.
>> >> >
>> >> > Closing the consumer explicitly didn't help (it's closed on session
>> close
>> >> > anyway). However, I have the feeling that the lifetime of the consumer
>> >> does
>> >> > not affect the peek lock (imagine a long-running consumer: it doesn't
>> >> lock
>> >> > the messages for longer than the lock duration).
>> >> >
>> >>
>> >> After sending my last reply to Gordon, I noticed something in your
>> >> wording that I'd now like to double check. When I asked if you tried
>> >> closing the consumer explicitly I meant before closing the session
>> >> object, i.e:
>> >> consumer.close();
>> >> session.close();
>> >>
>> >> Can you confirm that is what you updated your code to do?
>> >>
>> >> > Setting the prefetch value to 1 didn't help as the next message comes
>> to
>> >> > the consumer immediately after receive(). So, there could be 0 or 1
>> >> locked
>> >> > messages after each consumer.
>> >> >
>> >> > Setting the prefetch value to 0 brings me back to the drain problem:
>> >> > Service Bus doesn't answer anything after the sent packet with
>> >> 'drain=true'
>> >> > , so receive() is blocked forever. However, there are some (probably
>> >> empty)
>> >> > AMQP packets sent after some time, but Qpid doesn't send anything
>> >> anymore.
>> >> >
>> >> >
>> >> > On Tue, Jun 28, 2016 at 6:34 PM, Robbie Gemmell <
>> >> robbie.gemm...@gmail.com>
>> >> > wrote:
>> >> >
>> >> >> On 28 June 2016 at 17:00, Dale Green
>> wrote:
>> >> >> > Hi people,
>> >> >> >
>> >> >> > I have a problem using Qpid JMS 0.9 with Service Bus.
>> >> >> >
>> >> >> > The use case is the following:
>> >> >> > I want to create a connection, session, and a queue consumer and
>> >> receive
>> >> >> 0
>> >> >> > or 1 messages within a given timeout. That is, receive(timeout) is
>> >> called
>> >> >> > only once. Immediately after that, the session and the connection
>> are
>> >> >> > closed.
>> >> >> >
>> >> >> > The problem is:
>> >> >> > The consumer may receive multiple messages during its lifetime
>> (which
>> >> the
>> >> >> > client cod
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
On 06/07/16 17:14, Dale Green wrote: I have an update on this issue. According to Microsoft, state=Released is supported and now I can confirm that this is true. If the message is released during the lifetime of the consumer (before Detach), the same message is immediately unlocked and is available for the same consumer or others depending on the credit. However, what happens with Qpid JMS is that messageConsumer.close() first sends a Detach frame and after that the Disposition frames if any. Is this correct from protocol point of view, as Service Bus seems to ignore such dispositions? The spec says: The disposition performative MAY refer to deliveries on links that are no longer attached. As long as the links have not been closed or detached with an error then the deliveries are still “live” and the updated state MUST be applied. If the Detach sent by the client has closed=true, then I would think that the deliveries associated with that link are implicitly ended. If this is the case, then the client has a bug. (If the closed flag was false, then I would think it would depend on the expiry-policy for the link's source). Is there any way to set the credit to 0, send the Dispositions, and then Detach? - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
I have an update on this issue.
According to Microsoft, state=Released is supported and now I can confirm
that this is true. If the message is released during the lifetime of the
consumer (before Detach), the same message is immediately unlocked and is
available for the same consumer or others depending on the credit.
However, what happens with Qpid JMS is that messageConsumer.close() first
sends a Detach frame and after that the Disposition frames if any. Is this
correct from protocol point of view, as Service Bus seems to ignore such
dispositions?
Is there any way to set the credit to 0, send the Dispositions, and then
Detach?
Thanks!
On Thu, Jun 30, 2016 at 4:59 PM, Robbie Gemmell
wrote:
> Thanks for the update. That seems to confirm that theres not much the
> client can do to help here, as both of the mechanisms it could use to
> assist in this situation (explicitly releasing unconsumed messages, or
> doing no prefetching to begin with) appear to be running into server
> bugs, in this case the snippet Gordon linked to.
>
> Robbie
>
> On 30 June 2016 at 15:42, Dale Green wrote:
> > Sorry for the misunderstanding: The code I was testing is actually
> closing
> > the consumer explicitly.
> >
> > However, I tested now the Receiver example and can confirm, that it
> doesn't
> > matter for the server if the consumer is closed or not.
> > I can see that
> > messageConsumer.close();
> > produces such log lines for the prefetched messages:
> > SENT: Disposition{role=RECEIVER, first=7, last=7, settled=true,
> > state=Released{}, batchable=false}
> >
> > But the same messages are still locked for the lock duration.
> >
> >
> > On Thu, Jun 30, 2016 at 1:13 AM, Robbie Gemmell <
> robbie.gemm...@gmail.com>
> > wrote:
> >
> >> On 29 June 2016 at 11:08, Dale Green wrote:
> >> > Hi Robbie,
> >> >
> >> > Thanks for the hints! I couldn't solve my problems, but let me leave
> some
> >> > more info, which can be useful for other people.
> >> >
> >> > Closing the consumer explicitly didn't help (it's closed on session
> close
> >> > anyway). However, I have the feeling that the lifetime of the consumer
> >> does
> >> > not affect the peek lock (imagine a long-running consumer: it doesn't
> >> lock
> >> > the messages for longer than the lock duration).
> >> >
> >>
> >> After sending my last reply to Gordon, I noticed something in your
> >> wording that I'd now like to double check. When I asked if you tried
> >> closing the consumer explicitly I meant before closing the session
> >> object, i.e:
> >> consumer.close();
> >> session.close();
> >>
> >> Can you confirm that is what you updated your code to do?
> >>
> >> > Setting the prefetch value to 1 didn't help as the next message comes
> to
> >> > the consumer immediately after receive(). So, there could be 0 or 1
> >> locked
> >> > messages after each consumer.
> >> >
> >> > Setting the prefetch value to 0 brings me back to the drain problem:
> >> > Service Bus doesn't answer anything after the sent packet with
> >> 'drain=true'
> >> > , so receive() is blocked forever. However, there are some (probably
> >> empty)
> >> > AMQP packets sent after some time, but Qpid doesn't send anything
> >> anymore.
> >> >
> >> >
> >> > On Tue, Jun 28, 2016 at 6:34 PM, Robbie Gemmell <
> >> robbie.gemm...@gmail.com>
> >> > wrote:
> >> >
> >> >> On 28 June 2016 at 17:00, Dale Green
> wrote:
> >> >> > Hi people,
> >> >> >
> >> >> > I have a problem using Qpid JMS 0.9 with Service Bus.
> >> >> >
> >> >> > The use case is the following:
> >> >> > I want to create a connection, session, and a queue consumer and
> >> receive
> >> >> 0
> >> >> > or 1 messages within a given timeout. That is, receive(timeout) is
> >> called
> >> >> > only once. Immediately after that, the session and the connection
> are
> >> >> > closed.
> >> >> >
> >> >> > The problem is:
> >> >> > The consumer may receive multiple messages during its lifetime
> (which
> >> the
> >> >> > client code doesn't even see, because receive is called only once).
> >> For
> >> >> > Service Bus, all this means peek-and-lock, so the messages that
> were
> >> sent
> >> >> > to the Qpid client are locked for the time set in the "Lock
> Duration"
> >> >> > property of the queue (default value is 30s/60s, Azure/Windows),
> and
> >> >> > therefore they are unavailable for other Qpid consumers for a
> certain
> >> >> > period of time. I would expect that something like the method
> >> Abandon()
> >> >> > from the C# API should happen on session close.
> >> >> >
> >> >> > So:
> >> >> > Is this a bug, feature, or I need to configure/call something in a
> >> >> > different way?
> >> >> >
> >> >> > Thanks!
> >> >>
> >> >> My guess is that ServiceBus is not taking the consumers implicit
> >> >> detachment when the session ends as reason to release the messages.
> >> >> Perhaps try explicitly closing the MessageConsumer (I'm taking your
> >> >> text above literally, such that you arent doing so currently) to see
> >> >> if that prods it in
Re: [VOTE] Release Qpid Proton 0.13.1
> NOTE: gpg gave me this: > > gpg --verify qpid-proton-0.13.1.tar.gz.asc qpid-proton-0.13.1.tar.gz > gpg: Signature made Fri 01 Jul 2016 10:08:26 PM EDT using RSA key ID > C6B459DB > gpg: Good signature from "Justin Ross (CODE SIGNING KEY) e.org>" > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to > the owner. > Primary key fingerprint: F1B5 7706 904F AD58 4D55 21D5 648A 8E57 > C6B4 59DB > > I don't usually do the .asc check so I don't know if this is normal. I think this means that you personnally don't trust that the signature belongs to who it says it belongs to and is not forged. So you need to verify p2p that the key actually belongs to Justin and mark it trusted yourself, then you won't get the message. Andrew - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Issue when using CMake to install Qpid broker
On Tue, 2016-07-05 at 13:33 -0700, loremIpsum1771 wrote: > Yes, "" is just being used as a placeholder. I created a new > builds/qpid directory on the C drive and then ran the command: cmake > -G > "Visual Studio 12 2013" C:\Users\I664761\Downloads\qpid-cpp-0.34 > after doing > which I got the following error log: > https://gist.github.com/loremIpsum1771/fc1d912bbe5a741325cdd259f7a538 > 37 > > My company has a separate software package install manager through > which I > have to do installations. I already had python installed and had the > environment variable set up and I downloaded ruby as well and set up > the > environment variable for it. I tried installing Valgrind through my > company's software center but it seems that the closest thing to it > is > something calledLISA Dev Workstation. I couldn't find SASL and > Doxygen > within my company's software center. After configuring the paths for > the > installations, ran the command from above and got the error log. Are > all of > these packages required for the build? It seems like its only taking > issue > with not being able to find Ruby even though I set the path to it. I'm pretty sure that the only thing required to build for the source tarball is boost - You must install this (make sure you get the correct version for your compiler and 32/64 bits). When compiling on windows I don't think you need anything else - ruby and python are used to generate some code that I think is pregenerated in the source tarball (if I'm wrong about that then you will need those) As far as I know valgrind is Unix only and only used to run tests. Python is also necessary to run some tests. If you want to support amqp 1.0 you will also need qpid-proton. You may find looking at the included appveyor.yml file useful - this is the file that sets up the public CI build. Andrew - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Issue when using CMake to install Qpid broker
Hi. I've posted a successful build log for reference: http://people.apache.org/~chug/qpid-build-log-vs2012-x86.txt I don't have Boost for VS2013 so can't build with that version. This example using VS2012 is pretty representative of any build I've seen. Ruby has a confusing log message from a build: * -- Could NOT find Ruby (missing: RUBY_LIBRARY) (found version "1.8.6") Ok. Did it find Ruby or not? I think it did despite the message. Ruby is required and the build works so it must have found it. My environment supports many versions of Visual Studio so I don't have any in my PATH. I add a Studio environment as needed. The same with Boost. Hopefully there is a hint or two for you to use in figuring out your issues. -Chuck - Original Message - > From: "loremIpsum1771" > To: users@qpid.apache.org > Sent: Tuesday, July 5, 2016 4:33:15 PM > Subject: Re: Issue when using CMake to install Qpid broker > > Yes, "" is just being used as a placeholder. I created a new > builds/qpid directory on the C drive and then ran the command: cmake -G > "Visual Studio 12 2013" C:\Users\I664761\Downloads\qpid-cpp-0.34 after doing > which I got the following error log: > https://gist.github.com/loremIpsum1771/fc1d912bbe5a741325cdd259f7a53837 > > My company has a separate software package install manager through which I > have to do installations. I already had python installed and had the > environment variable set up and I downloaded ruby as well and set up the > environment variable for it. I tried installing Valgrind through my > company's software center but it seems that the closest thing to it is > something calledLISA Dev Workstation. I couldn't find SASL and Doxygen > within my company's software center. After configuring the paths for the > installations, ran the command from above and got the error log. Are all of > these packages required for the build? It seems like its only taking issue > with not being able to find Ruby even though I set the path to it. > > > > -- > View this message in context: > http://qpid.2158936.n2.nabble.com/Issue-when-using-CMake-to-install-Qpid-broker-tp7646766p7646889.html > Sent from the Apache Qpid users mailing list archive at Nabble.com. > > - > 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
Re: [VOTE] Release Qpid Proton 0.13.1
+1 I tested the staged Maven artefacts using the Joram Testsuite with Qpid JMS Client 0.10.0 and Java Broker 6.0.4. No issues encountered. On 6 July 2016 at 07:40, Jakub Scholz wrote: > +1 > > I checked Proton C++ bindings as well as trunk versions of Qpid C++ broker > and Qpid Messaging client built with the RC. > > On Sat, Jul 2, 2016 at 4:20 AM, Justin Ross wrote: > >> Hi, folks. Here is an RC for 0.13.1. Please test and place your vote. >> >> Source distribution: >> >> https://dist.apache.org/repos/dist/dev/qpid/proton/0.13.1-rc/ >> >> Maven staging repo: >> >> https://repository.apache.org/content/repositories/orgapacheqpid-1082 >> >> Changes since 0.13.0: >> >> >> >> https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=log;h=refs/tags/0.13.1-rc >> >> These are signed and ready for GA if approved by vote. I'll close the vote >> on July 11th. >> >> Thanks, >> Justin >> - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
