Greetings!
I need to confirm a point about pn_data_put_string usage. Second argument is
pn_bytes_t which contains pointer to text buffer and actual length of the string
in bytes. When this value is assigned to data node does it mean that the
ownership
of the string buffer is transfered to data
On 02/18/2015 08:11 AM, Michael Ivanov wrote:
Sorry I still cannot get the reply working :-(
I do the following:
_sender messenger is created.
I create a subscription to amqp://127.0.0.1/# for this messenger and
keep the reply address queue:
s =
On 02/17/2015 08:49 PM, Justin Ross wrote:
I've made a few changes to the api layout proposal:
https://cwiki.apache.org/confluence/display/qpid/Proton+API+layout+proposal
- Renamed proton.reactors to proton.reactor
- Added proton.security, to clean up the core space. This would be home
On 02/18/2015 11:03 AM, Michael Ivanov wrote:
Ok I have run my test program with PN_TRACE_FRM set to 1. The program sends a
request
to qpidd to create a queue TESTQUEUE. As can be seen the queue is actually
created but
temporary reply queue has dissappeared right after send operation.
The
Thanks, that worked!
18.02.2015 01:11, Gordon Sim пишет:
On 02/17/2015 09:59 PM, Michael Ivanov wrote:
Greetings,
I was creating and deleting queues using qpid c++ messenger sending the
following
messages to qpidd:
PROPERTIES: {method=request,
Sorry I still cannot get the reply working :-(
I do the following:
_sender messenger is created.
I create a subscription to amqp://127.0.0.1/# for this messenger and
keep the reply address queue:
s = pn_messenger_subscribe(_sender, amqp://127.0.0.1/#));
_reply_addr =
Ok I have run my test program with PN_TRACE_FRM set to 1. The program sends a
request
to qpidd to create a queue TESTQUEUE. As can be seen the queue is actually
created but
temporary reply queue has dissappeared right after send operation.
The output is as follows:
18-Feb-2015 13:53:45.973 @D
Apologies, I made the (incorrect) assumption they were broker logs... :-)
It's possible that these Detach/Ends are not actually being sent then, but
are just a response to the TCP connection dropping (the SEND is logged not
as things go on the wire, but at the point where the intent is to send, a
On Wed, Feb 18, 2015 at 10:53 AM, Justin Ross justin.r...@gmail.com wrote:
On Wed, Feb 18, 2015 at 9:28 AM, Rafael Schloming r...@alum.mit.edu
wrote:
A couple of comments in no particular order...
The Core user model and uitility classes description could be
misinterpreted on a quick
On Wed, Feb 18, 2015 at 11:18 AM, Gordon Sim g...@redhat.com wrote:
On 02/18/2015 03:44 PM, Rafael Schloming wrote:
I can't speak to the logic, but I believe the use of contrib to signal
pretty much *exactly* what we are talking about here is a pretty common
convention. There's a post here
I've made a start on some documentation for the reactive python api.
This consists of an updated version of the tutorial that lived alongside
the examples when they were in a separate branch, and a start at an
overview of the model and key classes involved. I used sphinx for this
as it
On Wed, Feb 18, 2015 at 1:33 PM, Justin Ross justin.r...@gmail.com wrote:
On Fri, Feb 13, 2015 at 1:27 PM, Rafael Schloming r...@alum.mit.edu
wrote:
On Fri, Feb 13, 2015 at 11:15 AM, Gordon Sim g...@redhat.com wrote:
On 02/13/2015 03:00 PM, Rafael Schloming wrote:
This has come up
On Wed, Feb 18, 2015 at 10:53 AM, Justin Ross justin.r...@gmail.com wrote:
On Wed, Feb 18, 2015 at 9:28 AM, Rafael Schloming r...@alum.mit.edu
wrote:
A couple of comments in no particular order...
The Core user model and uitility classes description could be
misinterpreted on a quick
On Fri, Feb 13, 2015 at 1:27 PM, Rafael Schloming r...@alum.mit.edu wrote:
On Fri, Feb 13, 2015 at 11:15 AM, Gordon Sim g...@redhat.com wrote:
On 02/13/2015 03:00 PM, Rafael Schloming wrote:
This has come up tangentially in a couple of threads now, and there
seems
to be at least tacit
On 02/18/2015 05:56 PM, Rafael Schloming wrote:
On Wed, Feb 18, 2015 at 11:18 AM, Gordon Sim g...@redhat.com wrote:
On 02/18/2015 03:44 PM, Rafael Schloming wrote:
I can't speak to the logic, but I believe the use of contrib to signal
pretty much *exactly* what we are talking about here is a
-Original Message-
From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
Sent: Wednesday, February 18, 2015 10:41 AM
To: users@qpid.apache.org
Subject: Re: towards releasing the new AMQP 1.0 JMS client
On 18 February 2015 at 14:59, Justin Ross justin.r...@gmail.com wrote:
On
Hi Rob,
thank you again for your answer. I requested the server logs from the
service provider who runs the broker. I keep you posted ;-)
Regards,
Erik
--
View this message in context:
On 02/18/2015 03:44 PM, Rafael Schloming wrote:
I can't speak to the logic, but I believe the use of contrib to signal
pretty much *exactly* what we are talking about here is a pretty common
convention. There's a post here that describes django.contrib in much the
same terms:
On 02/18/2015 04:04 PM, Justin Ross wrote:
Right now Container is inside proton.reactor. Should it go into the core
classes (proton) instead?
Not unless Reactor also went into core. I don't think you want anything
in core that depends on something outside. Container is simply an
extension
Hi Erik,
I don't have an answer to your question, but it might help someone
answer if you could detail the version of client/broker you are using,
and possibly outline what you are doing a little. Knowing why the
session is ending might also be useful. Some protocol trace logging
might help
PS: Here is the FRM-Log (in an anonymised form ;-)):
Qpid-API-frm.log
http://qpid.2158936.n2.nabble.com/file/n7620481/Qpid-API-frm.log
Maybe it would be needed to use heartbeats to keep the session alive?
Nevertheless why dos the exception listener of the connection don´t get a
exception if
I just pushed a quick update of the docs that will hopefully make this
clear, but pn_data_get_string (and similar) copies the bytes passed to it
into an internal area inside the pn_data_t. The converse,
pn_data_get_string(...) returns a pointer to the internal bytes, so those
need to be copied if
Thanks Erik - I was just writing out an e-mail to ask for that :-)
Looking at that log...
2015-02-18 12:36:18.947 - INFO - SEND[/123.12.12.123:1234|0] : End{}
2015-02-18 12:36:18.948 - INFO - SEND[/123.12.12.123:1234|1] : Detach{handle=0}
2015-02-18 12:36:18.948 - INFO -
Ok so then the following code:
const char *op;
pn_data_put_string(content, pn_bytes(strlen(op), op));
Gives me an error:
error: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]
pn_data_put_string(content, pn_bytes(strlen(op), op));
If I use pn_bytes_dup instead,
On Wed, Feb 18, 2015 at 4:18 AM, Gordon Sim g...@redhat.com wrote:
On 02/17/2015 08:49 PM, Justin Ross wrote:
I've made a few changes to the api layout proposal:
https://cwiki.apache.org/confluence/display/qpid/
Proton+API+layout+proposal
- Renamed proton.reactors to proton.reactor
Next up is the name. The new client has thus far been called simply
'Qpid JMS', with module names qpid-jms-foo, and binary tar
apache-qpid-jms[-bin]. We already release two other JMS clients, the
original AMQP 0-x one, module named qpid-client, and the older AMQP
1.0 one, module named
Dear Qpid users,
I'm using the Qpid AMQP 1.0 JMS client to connect to a ActiveMQ message
broker.
Sometimes I'm getting a MessageProducerException (Force detach the link
because the session is remotely ended.) when I'm trying to send a message to
the broker.
As for as I understand the error
Many thanks, the queue name without host address worked!
18.02.2015 14:18, Gordon Sim пишет:
On 02/18/2015 11:03 AM, Michael Ivanov wrote:
Ok I have run my test program with PN_TRACE_FRM set to 1. The program sends
a request
to qpidd to create a queue TESTQUEUE. As can be seen the queue is
Hi all,
We are getting to the point of wanting to do an initial release of the
new AMQP 1.0 JMS client, which raises some items for discussion.
The quick summary of an email that got quite long is: How do we
version it? What do we name it? How do we handle the overlap with the
older AMQP 1.0 JMS
On Wed, Feb 18, 2015 at 9:28 AM, Rafael Schloming r...@alum.mit.edu wrote:
A couple of comments in no particular order...
The Core user model and uitility classes description could be
misinterpreted on a quick read. Maybe go with Core protocol model... or
something like that? (Really all
Right now Container is inside proton.reactor. Should it go into the core
classes (proton) instead? It's notionally a peer to the endpoint types,
and going by the examples, it has primary significance for users.
On 18 February 2015 at 14:59, Justin Ross justin.r...@gmail.com wrote:
On Wed, Feb 18, 2015 at 7:33 AM, Robbie Gemmell robbie.gemm...@gmail.com
wrote:
At the moment the version number is 0.1[-SNAPSHOT], to be followed by
0.2 etc until we think there is sufficient maturity to go 1.0
On Wed, Feb 18, 2015 at 9:52 AM, Gordon Sim g...@redhat.com wrote:
On 02/18/2015 02:28 PM, Rafael Schloming wrote:
On Wed, Feb 18, 2015 at 4:18 AM, Gordon Sim g...@redhat.com wrote:
To amplify a little, the point was that the two things currently in the
utils module are ways of adapting
On 02/18/2015 02:28 PM, Rafael Schloming wrote:
On Wed, Feb 18, 2015 at 4:18 AM, Gordon Sim g...@redhat.com wrote:
To amplify a little, the point was that the two things currently in the
utils module are ways of adapting the reactive, non-blocking, event-driven
style to some other style
Hi Rob,
thanks for the answer.
But the problem is that im trying to send a message at 2015-02-18
12:36:18.925 and after that, the detaches are logged. So the detaches are
triggered by the client and not the broker? Why?
Here are the last to lines from the RAW log:
2015-02-18 11:50:43.696:
+1 on,
*. Calling the new JMS impl Qpid JMS.
*. Encouraging new development to use this client.
*. Add a clear note explaining the current situation with our JMS clients.
*. Naming the qpid-amqp-1-0-jms-client to include the word prototype,
which is what it is at best.
Rajith
On Wed, Feb
On 18 February 2015 at 14:59, Erik Aschenbrenner easch...@icubic.de wrote:
Hi Rob,
thanks for the answer.
But the problem is that im trying to send a message at 2015-02-18
12:36:18.925 and after that, the detaches are logged. So the detaches are
triggered by the client and not the broker?
On Wed, Feb 18, 2015 at 7:33 AM, Robbie Gemmell robbie.gemm...@gmail.com
wrote:
At the moment the version number is 0.1[-SNAPSHOT], to be followed by
0.2 etc until we think there is sufficient maturity to go 1.0
(sidenote: not years :P). The initial focus has been on implementing
the JMS 1.1
The logs say it is sending End, but I dont see it receiving any. So
one wonders what made the client want to send the End. The
application? A problem with the connection?
On 18 February 2015 at 13:46, Rob Godfrey rob.j.godf...@gmail.com wrote:
Thanks Erik - I was just writing out an e-mail to
On 18 February 2015 at 14:31, Richard Li rich...@datawire.io wrote:
Next up is the name. The new client has thus far been called simply
'Qpid JMS', with module names qpid-jms-foo, and binary tar
apache-qpid-jms[-bin]. We already release two other JMS clients, the
original AMQP 0-x one, module
On 02/18/2015 04:18 PM, Gordon Sim wrote:
On 02/18/2015 03:44 PM, Rafael Schloming wrote:
If we didn't already use the contrib convention I wouldn't actually care
all that much, but I feel like we should at least be consistent within
our
own codebase, so if we introduce python.extras, that's
On Wed, Feb 18, 2015 at 12:59 PM, Gordon Sim g...@redhat.com wrote:
I've made a start on some documentation for the reactive python api. This
consists of an updated version of the tutorial that lived alongside the
examples when they were in a separate branch, and a start at an overview of
the
42 matches
Mail list logo
