The patch was indicated to have been tested against the ActiveMQ trunk /
5.10-SNAPSHOT, so something probably changed on the ActiveMQ side since
5.9.0 was released.
Probably this: https://issues.apache.org/jira/browse/AMQ-4741
Robbie
On 21 February 2014 00:49, Rob Godfrey wrote:
> On 21 Februa
Hi Rob,
I've registered an account and opened JIRA QPID-5573
https://issues.apache.org/jira/browse/QPID-5573
I think you've already seen it.
I've attached the files I have "developed" for this test scenario. Shouldn't
be anything complicated. I'm not using an IDE or anything, so everything is
On 21 February 2014 01:38, Rob Godfrey wrote:
>
>
>
> On 21 February 2014 01:15, Mark Barker wrote:
>
>> Thanks for the help, Rob.
>> Here's some more feedback from today's experiments.
>>
>> I tried the setDeliveryMode on my 'basic' producer client (AMQP 1.0
>> client interacting only with Acti
On 21 February 2014 01:15, Mark Barker wrote:
> Thanks for the help, Rob.
> Here's some more feedback from today's experiments.
>
> I tried the setDeliveryMode on my 'basic' producer client (AMQP 1.0 client
> interacting only with ActiveMQ 5.9.0 broker's AMQP transport connector).
> In so doing,
I _think_ Qpid is packaged by Red Hat for RHEL 6.3 - you may want to check RHN
or your distro before trying to build it yourself.
If you do need to build it, we need to see the configure output and the make
output (esp the section that fails).
-Steve
> -Original Message-
> From: coolne
Thanks for the help, Rob.
Here's some more feedback from today's experiments.
I tried the setDeliveryMode on my 'basic' producer client (AMQP 1.0 client
interacting only with ActiveMQ 5.9.0 broker's AMQP transport connector).
In so doing, I could use the Qpid 0.27 AMQP 1.0 API to send() without
Hello Steve,
I'm currently using Qpid 0.18 on Red Hat 6.3 with gcc 4.4.6. I'm using the old
bootstrap and configure method. Nothing special when running configure (just
setting m32 to the CFLAGS, CXXFLAGS, and LDFLAGS to specify 32-bits build as
well setting the prefix for the make install). Yo
Hi Jeremy,
I'm afraid we're going to need more info in order to help you.
What Qpid version, OS/compiler do you have, and what is the complete output
from cmake?
Thanks,
-Steve
> -Original Message-
> From: coolness_2...@yahoo.com [mailto:coolness_2...@yahoo.com]
> Sent: Thursday, Febru
Hello,
Sorry, I got sidetracked, but I'm now looking into this. I did run the command
and got the following output:
-I/usr/include/nss3
-Wl,-rpath-link,/usr/lib -L/usr/lib -lssl3 -lsmime3 -lnss3 -lnssutil3
Could I be missing other packages? Thanks!
Regards,
Jeremy
Gotcha, just wanted to make sure you weren't expecting the API to do more
than it was actually doing. ;-)
--Rafael
On Thu, Feb 20, 2014 at 11:54 AM, Shearer, Davin wrote:
> Hi Rafael,
>
> Duplicates are acceptable, message loss is not. I'll handle any duplicates
> outside of messaging.
>
Hi Rafael,
Duplicates are acceptable, message loss is not. I'll handle any duplicates
outside of messaging.
No problem at all, thank you for your time and support Rob
> -Original Message-
> From: Rob Godfrey [mailto:rob.j.godf...@gmail.com]
> Sent: Thursday, February 20, 2014 4:57 PM
> To: users@qpid.apache.org
> Subject: Re: Java JMS acknowledge and prefetech
>
> I have reported the bug as
> ht
Just FYI, what you are doing isn't strictly speaking transactional. If your
client dies after it has sent the processed message to the outbox, but
before it has acknowledged the message from the inbox, then the message
from the inbox will end up getting processed again and you may therefore
see a d
I have reported the bug as
https://issues.apache.org/jira/browse/QPID-5570and it is (hopefully)
fixed on trunk after revision 1570234.
Apologies again,
Rob
On 20 February 2014 16:33, Rob Godfrey wrote:
> OK - I have found the issue, it is indeed a bug in the Qpid client :-(
>
> The issue is i
OK - I have found the issue, it is indeed a bug in the Qpid client :-(
The issue is in client acknowledge where, if you only have one message to
acknowledge, it will actually acknowledge all of the prefetched messages.
I shall check in a fix presently. If you use other acknowledge modes or
if y
Hi Jan,
I'll look into this - a first read through of the code didn't highlight any
screaming errors in the Qpid client code (it appears to track the last
message each message consumer has delivered to the application, and then
when message.acknowledge() is called updates all the messages delivere
Hello,
Is there a way to use jks files for SSLContext configuration in proton-j?
I noticed that in SslEngineFacadeFactory there is only a path to privatekey and
certificate and single password which is not really used. I would like
to be able to
use my own keymanager and trustmanager arrays or pro
Hi,
I need someone with good JMS knowledge to clarify the Message.acknowledge():
"Acknowledges all consumed messages of the session of this consumed message".
With QPID 0.26 and AMQP 1.0 is seems that acknowledge also acknowledges
prefetched messages that were not returned from receive() or onM
The most likely candidate for a change in behaviour would seem to be
https://issues.apache.org/jira/browse/QPID-5455, which means that 0.26 and
0.27 enforce synchronous publishing semantics. I know this has been tested
against ActiveMQ 5.9.0 but perhaps if you are using an earlier version it
may e
Hmmm, I can't imagine this change would have had that effect... I'll have
a look back through the changes in the client between 0.24 and 0.26 to see
if there is anything obvious... Can you confirm which version of ActiveMQ
you are using?
Thanks,
Rob
On 20 February 2014 05:42, Mark Barker wrote
20 matches
Mail list logo
