I'm trying to run the new Java send/recv example in proton 0.5 with the qpid
java broker 0.22.
I have the broker running on localhost and I've added a queue named test to the
default virtualhost through the web config. When I try to run the Send or Recv
class with a:
-a amqp://localhost/test
On Wed, 2013-09-04 at 16:03 +0100, Gordon Sim wrote:
> On 09/04/2013 03:34 PM, Gordon Sim wrote:
> > On 09/04/2013 03:14 PM, Alan Conway wrote:
> >> Having a connection option that changes how messages are presented seems
> >> confusing and error prone.
> >
> > I'm not sure I agree. I don't really
On 09/04/2013 06:06 PM, Andrew Stitcher wrote:
I think the fundamental question here is what is the API model of
message properties: Until now the API has been loosely modeled (for
better or worse) on JMS - JMS has no distinction as to different kinds
of message properties (as far as I know). Add
On 09/04/2013 03:14 PM, Alan Conway wrote:
Having a connection option that changes how messages are presented seems
confusing and error prone.
I'm not sure I agree. I don't really see a problem with the behaviour
being configurable. And if it is, doing so at the granularity of
connection seem
Hello All,
Can anybody confirm if there is any workaround to the following bug that I just
logged?
https://issues.apache.org/jira/browse/QPID-5113
We need to capture when the JMS connection is lost between the AMQP JMS client
and the server.
Thanks,
Mike
On 09/04/2013 03:34 PM, Gordon Sim wrote:
On 09/04/2013 03:14 PM, Alan Conway wrote:
Having a connection option that changes how messages are presented seems
confusing and error prone.
I'm not sure I agree. I don't really see a problem with the behaviour
being configurable. And if it is, doing
On 09/02/2013 12:26 PM, Gordon Sim wrote:
On 08/30/2013 11:30 AM, Jakub Scholz wrote:
Hi,
The JIRA QPID-4591 added the queue level sequencing. I played with it with
the 0.24RC3 release and it seems it doesn't work properly with AMQP 1.0
producers (C++ / Qpid Messaging API).
My queue is configu
On 09/04/2013 06:19 AM, Pavel Moravec wrote:
Hi all,
I identified a use case when moving (via QMF) more messages than the
destination queue can handle causes one message loss. See reproducer when
attempting to move 300 messages to a queue with max count 100:
$ qpid-receive -a "ringQueue; {cre
Hi Pavel,
>From the user perspective ... functions called "move" are usually not
expected to loose anything. If you move files with the "mv" or "move"
commands and the target disk is full, the files which didn't fit stay in
the source location. They are not deleted. I guess one would expect the
sa
Hi all,
I identified a use case when moving (via QMF) more messages than the
destination queue can handle causes one message loss. See reproducer when
attempting to move 300 messages to a queue with max count 100:
$ qpid-receive -a "ringQueue; {create:always, node:{ x-declare:{
arguments:{'qpi
>Instead of an address like:
>
> my-node
>
>use:
>
> 'my-node; {node:{type:topic}}'
>
>to indicate you want to send to and/or receive from the exchange, and/or:
>
> 'my-node; {node:{type:queue}}'
>
>to indicate you want to send to and/or receive from the queue.
Thank you Gordon. I do
On 09/04/2013 08:11 AM, kevency_poche wrote:
I added one queue and exchange with same name. I binded both of them. Up to
now it is okay. But, when i try to do "spout" and "drain" for the exchange.
It is giving this." Ambiguous address, please specify
queue or topic as node typ
I added one queue and exchange with same name. I binded both of them. Up to
now it is okay. But, when i try to do "spout" and "drain" for the exchange.
It is giving this." Ambiguous address, please specify
queue or topic as node type"I am understanding that there will be definit
13 matches
Mail list logo
