Dear Qpid users,
so nobody has experiences with Qpid AMQP 1.0 JMS client in production so
far?
Regards,
Erik
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Experiences-with-Qpid-AMQP-1-0-JMS-client-in-production-tp7611393p7612537.html
Sent from the Apache Qpid users
Hey Rob,
Thanks for the responses, some more info. I added:
secureOnlyMechanisms : [],
so my password file authentication provider section looks like this:
authenticationproviders : [ {
id : cf7bd327-ec0f-4917-bd27-d033e49a23fb,
name : passwordFile,
secureOnlyMechanisms : [],
Hi Erik,
I'm pretty sure there are people using the JMS 1.0 client in production, as
it is the client that Microsoft points users of their Azure Service Bus
offering to if they want to connect using Java applications. I'm not sure
how many of these users are subscribed to this list however.
In
So, I ran last night with a virtualhost called localhost and the address
amqp://guest:guest@localhost:5672/amq.fanout and it worked fine... (I also
got it working with SSL - I think my mistake previously was forgetting that
messenger would try to connect to port 5671 for amqps)
Unfortunately
On 08/24/2014 10:23 PM, Graham Leggett wrote:
I have a need to configure a very large queue that is able to store about 1
million messages of around 10kb each. The queue will be too big to fit into
RAM, and will need to spool to disk.
I have been struggling to configure the queue, as the
Ah - the NPE is because Proton sends stuff without waiting for a reply, and
the Java Broker is not ignoring data that has been sent after it has
already decided to close the connection (because the vhost doesn't exist).
Your underlying problem is the vhost one, when I send without the vhost
On 08/25/2014 11:47 AM, Rob Godfrey wrote:
While I was working on adding addressing support to the JMS 0-9-1 client
[1] and looking at how I might implement a subscription where the
subscription was to a set of queues (rather than a single queue) [2], I
came across a couple of issues with the
Hi Gordon,
thanks for your, as ever, very helpful response
On 26 August 2014 11:23, Gordon Sim g...@redhat.com wrote:
On 08/25/2014 11:47 AM, Rob Godfrey wrote:
While I was working on adding addressing support to the JMS 0-9-1 client
[1] and looking at how I might implement a subscription
On 26/08/14 09:50, Rob Godfrey wrote:
So, I ran last night with a virtualhost called localhost and the address
amqp://guest:guest@localhost:5672/amq.fanout and it worked fine...
So *has* this stuff changed then, as I say I'm pretty convinced that I
tried the Java broker with Messenger a few
Hi,
Thanks Andreas and Gordon.
Following this note
Note: The deprecated qpid::client API will be removed in the next release.
Users should instead use the Qpid Messaging API.
I've decided to use qpid::messaging API instead of qpid::client api.
I've followed the edvice of Andreas,
std:string
On 26 August 2014 12:28, Fraser Adams fraser.ad...@blueyonder.co.uk wrote:
On 26/08/14 09:50, Rob Godfrey wrote:
So, I ran last night with a virtualhost called localhost and the address
amqp://guest:guest@localhost:5672/amq.fanout and it worked fine...
So *has* this stuff changed then, as I
I've raised QPID-6044 and put a change onto trunk which will mean that if
you use an address that resolves to the local machine it will (eventually -
there are lots of DNS lookups involved) decide that you want to connect to
the default virtual host.
I might make a further change to cache the
Hi Rob,
thank you for your answers.
I will share my experiences when I'm able to test against the AMQP 1.0
broker to which I have to connect.
Do you have a plan when the proton based JMS client will be ready?
Kind Regards,
Erik
--
View this message in context:
On 08/26/2014 11:15 AM, Rob Godfrey wrote:
On 26 August 2014 11:23, Gordon Sim g...@redhat.com wrote:
I'd suggest using an explicit type to indicate which 0-10 commands should
be issued when creating a receiver (and/or a sender). You may additionally
need to avoid declaring the queue if that is
On 08/26/2014 11:31 AM, nidhal.kort wrote:
Hi,
Thanks Andreas and Gordon.
Following this note
Note: The deprecated qpid::client API will be removed in the next release.
Users should instead use the Qpid Messaging API.
I've decided to use qpid::messaging API instead of qpid::client api.
I've
On 26 August 2014 13:58, Gordon Sim g...@redhat.com wrote:
On 08/26/2014 11:15 AM, Rob Godfrey wrote:
On 26 August 2014 11:23, Gordon Sim g...@redhat.com wrote:
I'd suggest using an explicit type to indicate which 0-10 commands should
be issued when creating a receiver (and/or a sender).
well I think I'm doing something wrong concerning the data base because
certutil -V /.../nkort/certif ==certutil -V: nickname is required for this
command (-n).
Also when I try to list the certificates in the current directory with
certutil -L -d .
I get certutil: function failed: security
Hi again Rob,
Sorry for yet another post .
Firstly thanks very much for the answer around
I think at some previous point
the 1.0 implementation could *only* connect to the default virtual host and
the hostname on the open field was ignored...
That makes sense, TBH I was starting to
On 08/26/2014 01:22 PM, nidhal.kort wrote:
well I think I'm doing something wrong concerning the data base because
certutil -V /.../nkort/certif ==certutil -V: nickname is required for this
command (-n).
Sorry, that was my fault, I forgot you need to specific a specific
certificate.
Also
Hi Nidhal,
You can have a look at the chapter 4.1 of this document:
http://www.eurexclearing.com/blob/clearing-en/136500-861464/846488/3/data/eurex_clearing_messaging_connectivity_B_v100.pdf
It describes how to prepare the NSS database for the C++ client. If you
have your private key in Java
So why you didn't get the default exchange created is probably this part:
context : {
virtualhostBlueprint : { \type\ : \DERBY\ },
virtualhostBlueprintUtilised : true
},
Without going into ridiculous levels of detail, basically that second
context variable being set to true means
On 26/08/14 13:46, Rob Godfrey wrote:
To be honest rather than messing around in the config file, it's much
easier just to open up the built in web management console and add the
virtual host from there...
I did begin to wonder that, but I figured I was *trying* to do something
that should be
Hi Rob,
We are considering the JMS AMQP 1.0 client to be of high importance and central
to the success of our project. We have found that the Qpid jms amqp 1.0 was
indeed slow from a performance perspective.
Is there a timeline for shifting work toward the jms amqp 1.0 implementation on
Hi Fraser,
I think the issue here is that the Java Broker doesn't really understand
properly what you want to do with the address amq.fanout I think it is
looking for a binding key for the exchnage... for instance if you tried to
receive from the address amq.fanout/foo I think it would work.
On 08/26/2014 03:50 PM, Adams, Cory wrote:
I will pickup the test scenario later today and provide details. We
were doing simple bulk message sending to a queue with an asynch
listener and then comparing that to the throughput using the swiftmq
driver. This was against the qpid c++ broker.
On 08/26/2014 03:41 PM, Rob Godfrey wrote:
I think the issue here is that the Java Broker doesn't really understand
properly what you want to do with the address amq.fanout I think it is
looking for a binding key for the exchnage... for instance if you tried to
receive from the address
On 26 August 2014 16:57, Gordon Sim g...@redhat.com wrote:
On 08/26/2014 03:41 PM, Rob Godfrey wrote:
I think the issue here is that the Java Broker doesn't really understand
properly what you want to do with the address amq.fanout I think it is
looking for a binding key for the exchnage...
On 26/08/14 15:41, Rob Godfrey wrote:
Hi Fraser,
I think the issue here is that the Java Broker doesn't really understand
properly what you want to do with the address amq.fanout I think it is
looking for a binding key for the exchnage... for instance if you tried to
receive from the address
On 08/26/2014 04:09 PM, Fraser Adams wrote:
On 26/08/14 15:41, Rob Godfrey wrote:
Hi Fraser,
I think the issue here is that the Java Broker doesn't really understand
properly what you want to do with the address amq.fanout I think it is
looking for a binding key for the exchnage... for
As an aside, I've just made a change on trunk for QPID-6046 which should
allow the address amqp://guest:guest@localhost/amq.fanout to work
-- Rob
On 26 August 2014 17:09, Fraser Adams fraser.ad...@blueyonder.co.uk wrote:
On 26/08/14 15:41, Rob Godfrey wrote:
Hi Fraser,
I think the issue
On 26/08/14 16:19, Rob Godfrey wrote:
As an aside, I've just made a change on trunk for QPID-6046 which should
allow the address amqp://guest:guest@localhost/amq.fanout to work
-- Rob
I Rob,
I've just updated to revision 1620634 and rebuild and restarted my
broker and
./recv
Doh - yeah - that was my fault... fixed now I hope,
-- Rob
On 26 August 2014 17:49, Fraser Adams fraser.ad...@blueyonder.co.uk wrote:
On 26/08/14 16:19, Rob Godfrey wrote:
As an aside, I've just made a change on trunk for QPID-6046 which should
allow the address
Hi Justin,
Arising out of Fraser's interoperability testing of the Java Broker with
Messenger today, there's a couple of change that I'd like to get in to 0.30
(and should really be considered out of the scope of the more general
request of mine to merge everything that was on trunk for Java as
On 26/08/14 17:50, Rob Godfrey wrote:
Doh - yeah - that was my fault... fixed now I hope,
-- Rob
Just updated, seems to be behaving now, I also got
node recv.js amqp://guest:guest@localhost:5673/amq.fanout
node send.js -a amqp://guest:guest@localhost:5673/amq.fanout
working so the
Thanks, Rob. Both are now approved.
On Tue, Aug 26, 2014 at 1:19 PM, Rob Godfrey rob.j.godf...@gmail.com
wrote:
Hi Justin,
Arising out of Fraser's interoperability testing of the Java Broker with
Messenger today, there's a couple of change that I'd like to get in to 0.30
(and should
Hi Rob, just verified with 0.32/trunk client and the v0.16 broker that we
currently use. It is indeed doing prefetching at a per session level once I
started the client with AMQP 0-91. Thanks so much for the suggestion! The
only issue I encountered is that getJMSDestination on the message returns
36 matches
Mail list logo
