I doubt that I can give any sort of definitive answers here as my
experience of AMQP 1.0 is barely off the n00b level yet, but RE:
What I need to do is create a reply queue. The AMQP 1.0
spec covers creating Dynamic Reply-To. The problem I'm having is in
garbage collection of the abandoned
On 01/09/2014 07:46 PM, Shearer, Davin wrote:
I am trying to build a transport library in C using proton with support for
a qpid broker. What I need to do is create a reply queue. The AMQP 1.0
spec covers creating Dynamic Reply-To. The problem I'm having is in
garbage collection of the
My application has multiple receivers senders. It seems to be hanging
forever when calling function qpid::client::Connection::newSession(). It
occurs in the scenario when application disconnects ( due to n/w loss)
reconnects to the broker again after sometime. I am trying to declare some
queues
On 01/10/2014 10:31 AM, trivedi_ravi13 wrote:
My application has multiple receivers senders. It seems to be hanging
forever when calling function qpid::client::Connection::newSession(). It
occurs in the scenario when application disconnects ( due to n/w loss)
reconnects to the broker again
How can we identify in a packet capture that the broker replied successfully
or not ? Is there any other way to debug ?
--
View this message in context:
http://qpid.2158936.n2.nabble.com/qpid-client-Connection-newSession-seems-to-be-hanging-tp7602520p7602522.html
Sent from the Apache Qpid
On 01/10/2014 10:45 AM, trivedi_ravi13 wrote:
How can we identify in a packet capture that the broker replied successfully
or not ?
Assuming you have the 0-10 dissector for wireshark, look for the
session.attach and session-attached controls.
Is there any other way to debug ?
Depending
Thank you for the response.
It appears to me that client did not even send session.attach command to
broker for the last queue. I could see following sequence of commands for my
previous receivers i.e before it hangs.
session.attach
session.attached session.command-point
session.request-timeout
Is there an alternative to SYNC newSession() ? can we use AsyncSession to
declare queues and subscribe to it ? Do you advise to use AsyncSession here
to fix this issue ? Debugging with GDB would take time and We need to have
fix ASAP.
--
View this message in context:
On 01/10/2014 11:05 AM, trivedi_ravi13 wrote:
It appears to me that client did not even send session.attach command to
broker for the last queue.
Are you sure the connection and socket are still active?
-
To unsubscribe,
On 01/10/2014 11:35 AM, trivedi_ravi13 wrote:
Is there an alternative to SYNC newSession() ? can we use AsyncSession to
declare queues and subscribe to it ? Do you advise to use AsyncSession here
to fix this issue ?
If the attach request is not even being sent, then the issue is not in
Thanks, that gave me clue..
I checked lsof output of my process before disconnecting to the broker
after restarting the broker. Application should automatically reconnect to
the broker as per implementation. But it appears that it did not.
lsof command output shows same ESTABLISHED connection
On 01/10/2014 09:15 AM, Fraser Adams wrote:
I'm much more familiar with qpid::messaging/JMS myself and I'd be quite
keen for some guidance on AMQP 1.0 Addressing and examples of say how to
write something in messenger that could publish or subscribe to things
that I'm familiar with - most of my
Thanks for the help.
A couple of things... being able to configure lifetime policies on the
broker based on the name of the node is a wonderful idea and I look forward
to that in qpid 0.26. Problem is that I need to have the solution work on
RHEL6 (which ships with qpid 0.14) if possible.
I
Hey all,
I've literally just done an svn update and a
mkdir bld
cd bld
cmake ..
make all
make install
and tried to fire up qpidd --auth no
and it has barfed as follows:
qpidd --auth no
2014-01-10 14:33:11 [Store] notice Journal TplStore: Created
2014-01-10 14:33:11 [Store] notice Store module
On 10/01/14 10:24, Gordon Sim wrote:
You can create a temporary queue when using the qpid::messaging client
by simply specifying '#' as the node name in the address when creating
the receiver or sender. You can get the peer-assigned address (for use
in reply-to) via the getAddress() method
On 01/10/2014 02:39 PM, Fraser Adams wrote:
Hey all,
I've literally just done an svn update and a
mkdir bld
cd bld
cmake ..
make all
make install
and tried to fire up qpidd --auth no
and it has barfed as follows:
qpidd --auth no
2014-01-10 14:33:11 [Store] notice Journal TplStore: Created
On 10 January 2014 15:45, Fraser Adams fraser.ad...@blueyonder.co.ukwrote:
On 10/01/14 10:24, Gordon Sim wrote:
You can create a temporary queue when using the qpid::messaging client by
simply specifying '#' as the node name in the address when creating the
receiver or sender. You can get
If I'm subscribing to a node named # doesn't it make sense that the
terminus be marked dynamic automagically?
On Fri, Jan 10, 2014 at 9:26 AM, Shearer, Davin dshea...@novetta.comwrote:
Thanks for the help.
A couple of things... being able to configure lifetime policies on the
broker based
On 01/10/2014 02:26 PM, Shearer, Davin wrote:
A couple of things... being able to configure lifetime policies on the
broker based on the name of the node is a wonderful idea and I look forward
to that in qpid 0.26. Problem is that I need to have the solution work on
RHEL6 (which ships with
On 01/10/2014 03:05 PM, Shearer, Davin wrote:
If I'm subscribing to a node named # doesn't it make sense that the
terminus be marked dynamic automagically?
That is what qpid::messaging does. It then returns the name allocated by
the broker through the getAddress() method on the Receiver
On 01/10/2014 10:24 AM, Gordon Sim wrote:
You can create a temporary queue when using the qpid::messaging client
by simply specifying '#' as the node name in the address when creating
the receiver or sender. You can get the peer-assigned address (for use
in reply-to) via the getAddress() method
On 10/01/14 14:47, Gordon Sim wrote:
You can't have two store modules loaded. Looks like install puts both
libs in place though. Simplest is probably to delete the
linearstore.so from your qpidd modules directory (else specify
--no-module-dir and --load-module explicitly for those you want).
Cheers Rob, glad to know I wasn't *totally* losing my marbles and this
stuff really *is* a black art :'(
Well glad in the loosest sense, totally agree with your last sentence!
Frase
On 10/01/14 14:55, Rob Godfrey wrote:
On 10 January 2014 15:45, Fraser Adams
On 01/10/2014 02:45 PM, Fraser Adams wrote:
On 10/01/14 10:24, Gordon Sim wrote:
You can create a temporary queue when using the qpid::messaging client
by simply specifying '#' as the node name in the address when creating
the receiver or sender. You can get the peer-assigned address (for use
A similar issue was closed with wont-fix:
https://issues.apache.org/jira/browse/PROTON-426. The problem is I think
that with the dynamic flag the name is actually created by the remote peer,
so its not immediately obvious how this would be passed back in the
messenger API.
OK, I'm missing
I think the behaviour of qpid::messaging is correct. I don't think its out
of the question to expect the same behaviour in proton messenger.
On Fri, Jan 10, 2014 at 10:11 AM, Gordon Sim g...@redhat.com wrote:
On 01/10/2014 03:05 PM, Shearer, Davin wrote:
If I'm subscribing to a node named #
grepping around proton-c for '#' comes up dry. If # isn't sent over the
wire, I'd expect to see it dealt with somewhere in the source code.
[davin@centos6 proton-c]$ grep '#' src/*.c include/proton/*.h | grep -v ':#'
On Fri, Jan 10, 2014 at 10:02 AM, Gordon Sim g...@redhat.com wrote:
On
On 01/10/2014 04:03 PM, Shearer, Davin wrote:
OK, I'm missing something. In the python code using proton, I have the
following lines:
reply_subscription = messenger.subscribe(amqp://%s/# % host)
reply_address = reply_subscription.address
The reply address is being set to something
On 01/10/2014 02:26 PM, Shearer, Davin wrote:
I took some python code from Apache Dispatch Router and modified it to work
with the qpid broker directly without using the dispatch router.
[...]
This is just using proton, which is great, but the problem is that the
dynamic queues have a
On 01/10/2014 10:24 AM, Gordon Sim wrote:
Using proton messenger there is at present no way to set the dynamic
flag
The above statement is incorrect. The dynamic flag can be set by
specifying '#' as the path in the url to which you subscribe, e.g.
amqp://127.0.0.1/#
The address allocated
Hi!
So what do I need to get started? Proton only, or Proton + a broker like
the C++ one? Or just Proton? Is the Dispatch Router optional? It is
built on Proton ? Does it include Proton then? Is there any point in
having the router and a broker? Whatwhatwhat? :)
My point is, it would help if
I actually _prefer_ the C++ broker. I was using the java one for the web
management.
So to get this straight... proton sends '#' to the qpid broker, which in
turn generates a node name which it then sends back to the client via the
address attribute. The only thing at is missing is that the
+1
Windows qpid/proton sends amqp 1.0 traffic through dispatch router.
-Chuck
- Original Message -
From: Darryl L. Pierce dpie...@redhat.com
To: users@qpid.apache.org
Sent: Tuesday, January 7, 2014 10:59:52 AM
Subject: Re: [VOTE] Initial Release of Dispatch (0.1 RC5)
On Tue, Jan
On 01/10/2014 01:34 PM, Shearer, Davin wrote:
I actually _prefer_ the C++ broker. I was using the java one for the web
management.
So to get this straight... proton sends '#' to the qpid broker, which in
turn generates a node name which it then sends back to the client via the
address
Sent from my iPhone
On Jan 10, 2014, at 13:49, Ted Ross tr...@redhat.com wrote:
On 01/10/2014 01:34 PM, Shearer, Davin wrote:
I actually _prefer_ the C++ broker. I was using the java one for the web
management.
So to get this straight... proton sends '#' to the qpid broker, which
On 01/10/2014 02:03 PM, Davin Shearer wrote:
Sent from my iPhone
On Jan 10, 2014, at 13:49, Ted Ross tr...@redhat.com wrote:
On 01/10/2014 01:34 PM, Shearer, Davin wrote:
I actually _prefer_ the C++ broker. I was using the java one for the web
management.
So to get this straight...
Thanks Ted, I see the new code in proton-c/src/messenger/messenger.c where
a node named # gets set to dynamic. Good stuff.
On Fri, Jan 10, 2014 at 2:19 PM, Ted Ross tr...@redhat.com wrote:
On 01/10/2014 02:03 PM, Davin Shearer wrote:
Sent from my iPhone
On Jan 10, 2014, at 13:49, Ted
On 10/01/14 18:34, Shearer, Davin wrote:
I actually _prefer_ the C++ broker. I was using the java one for the web
management.
Hi Davin, have you taken a look at the stuff in qpid/tools/src/java?
There's a QMF based Web UI for the C++ broker (it'll work with the Java
Broker too if you build
On 01/10/2014 06:34 PM, Shearer, Davin wrote:
The only thing at is missing is that the qpid broker does not set
auto-del on the newly created dynamic queue. If/When that's fixed,
I'm golden.
Done[1], as penance for my earlier mistake!
[1] https://svn.apache.org/r1557262
Hi,
While playing around with the proton-c engine, I tried to re-open a link that I
had previously closed. The link failed to come up - but no error state was
returned.
Should the engine allow a previously closed link to be re-opened? IOW, should
the engine allow the following Link test to
Hi Robbie,
I did some more testing to see whether message grouping will work for us,
and compared the dequeue performance of a queue using message grouping in
default Java mode, a queue using C++ mode, and a queue not using message
grouping. I found that when I use C++ mode, the performance can
Wow, I didn't know about this but I'll definitely try it out.
Sent from my iPhone
On Jan 10, 2014, at 15:46, Fraser Adams fraser.ad...@blueyonder.co.uk wrote:
On 10/01/14 18:34, Shearer, Davin wrote:
I actually _prefer_ the C++ broker. I was using the java one for the web
management.
Hi
Thanks for the help and the fix!
Sent from my iPhone
On Jan 10, 2014, at 16:20, Gordon Sim g...@redhat.com wrote:
On 01/10/2014 06:34 PM, Shearer, Davin wrote:
The only thing at is missing is that the qpid broker does not set
auto-del on the newly created dynamic queue. If/When that's
43 matches
Mail list logo
