Hi Dan,
messages only get dequeued at the broker when it receives an
acknowledgement for that message... so, no - messages shouldn't get lost in
the case you are describing above.
-- Rob
On 9 September 2014 05:53, xiaodan.wang xiaodan.w...@salesforce.com wrote:
Hi Rob, when using
Hi Frase,
ignoring any transformations that may take place in a client library
between setting the content type in the API and what actually goes out on
the wire... the AMQP 1.0 specification defines content-type as follows
(see:
I'm also interested; personally never felt comfortable with the lack of
visibility regarding things like connection failures that Messenger's api
currently provides.
Tangentially related, perhaps - I'd like to see errors reported via the event
collector interface. While my issue is engine
On Mon, 2014-09-08 at 19:07 +0100, Fraser Adams wrote:
Messenger gurus seem to be keeping their heads down a bit.
Is it *really* just Alan and I who are interested to understand the
error handling/reconnection behaviour of Messenger?
Is anybody using it in industrial strength applications
On 09/09/2014 10:59 AM, Alan Conway wrote:
On Mon, 2014-09-08 at 19:07 +0100, Fraser Adams wrote:
Messenger gurus seem to be keeping their heads down a bit.
Is it *really* just Alan and I who are interested to understand the
error handling/reconnection behaviour of Messenger?
Is anybody
On 09/09/2014 03:59 PM, Alan Conway wrote:
On Mon, 2014-09-08 at 19:07 +0100, Fraser Adams wrote:
Messenger gurus seem to be keeping their heads down a bit.
Is it *really* just Alan and I who are interested to understand the
error handling/reconnection behaviour of Messenger?
Is anybody using
On Tue, 2014-09-09 at 08:34 -0400, Ken Giusti wrote:
I'm also interested; personally never felt comfortable with the lack of
visibility regarding things like connection failures that Messenger's api
currently provides.
Tangentially related, perhaps - I'd like to see errors reported via the
Thanks Rob! The reason I asked is because we are planning to expose/make
public AMQSession#rejectMessagesForConsumerTag on the v0.16 client that we
use in production as a short term solution until we upgrade. I see that
underneath the hood it is calling rejectMessage for each prefetched message.
To my knowledge the only issue would be if you enabled max message delivery
features, in which case if you reject a message a given number of times
then it will be DLQd... however if you've not enabled that then I don't see
an issue.
-- Rob
On 9 September 2014 17:35, xiaodan.wang
Cool beans, we did not set max message delivery attempt or enable DLQ on our
broker :)
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Re-1-Queue-with-2-Consumers-turn-off-pre-fetching-tp6934582p7613363.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
On Tue, Sep 9, 2014 at 5:22 PM, Alan Conway acon...@redhat.com wrote:
Given that engine is already a more complete and flexible API (in the
sense of offering full low-level access to the entire AMQP protocol),
and that people are demonstrating that it can be made easier to use by
layering
On 8 September 2014 10:05, Gordon Sim g...@redhat.com wrote:
On 09/08/2014 09:31 AM, Robbie Gemmell wrote:
Hi all,
As many of you know, there is work going on within Qpid towards creating a
new AMQP 1.0 JMS client based around Proton and implementing a JMS mapping
for AMQP as being
On 9 September 2014 18:14, Robbie Gemmell robbie.gemm...@gmail.com wrote:
On 8 September 2014 10:05, Gordon Sim g...@redhat.com wrote:
On 09/08/2014 09:31 AM, Robbie Gemmell wrote:
Hi all,
As many of you know, there is work going on within Qpid towards
creating a
new AMQP 1.0 JMS
I'm afraid that your response was as clear as mud to me Rob, I'm having
a thick day today :-(
I did read the spec. and the RFCs, but frankly I work best with concrete
examples.
You say
the content type is (only) to be used when the data is being
sent as an opaque data section and in that
On 9 September 2014 20:39, Fraser Adams fraser.ad...@blueyonder.co.uk
wrote:
I'm afraid that your response was as clear as mud to me Rob, I'm having a
thick day today :-(
I did read the spec. and the RFCs, but frankly I work best with concrete
examples.
You say
the content type is
Hi Rob, in case you are interested, wanted to give you an update from our
side. First, let me begin by saying how awesome the Qpid community has been.
Your patience and responsiveness in addressing our questions is way beyond
what we could have hoped for from this community. I think I speak for
Hi,
Is Qpid Proton (after of course compiling/building) supported to work with
J2ME 3.x applications?
Thanks.
Guy
On Tue, Sep 09, 2014 at 10:38:09PM +0200, Guy Dillen wrote:
Is Qpid Proton (after of course compiling/building) supported to work with
J2ME 3.x applications?
That's an interesting question. Having done J2ME development a few years
ago, I'd love to know what 3 supports specs-wise and if
This is a somewhat serious regression since (at least) 0.22(!) in the
area of failover.
The fix is a simple one line fix - which I think is pretty low risk.
Thanks
Andrew
[1] https://issues.apache.org/jira/browse/QPID-6089
[2] https://svn.apache.org/r1623882
I've moved the dispatch AMQP management client library into a normal
python package qpid_dispatch.management. Source is in
dispatch/python/qpid_dispatch, for examples of use see bin/qdstat and
dispatch/tests/system_tests_management.py.
Justin I'd be interested in your feedback, it resembles your
20 matches
Mail list logo
