0c251000 ---p 00:00 0
>> >> > 7f270c251000-7f270cc51000 rw-p 00:00 0
>> >> > 7f270cc51000-7f270cc52000 ---p 0000 00:00 0
>> >> > 7f270cc52000-7f270d652000 rw-p 00:00 0
>> >> > 7f270d652000-7f270d65e000 r-xp
Hi Robbie,
- Original Message -
> From: "Robbie Gemmell"
> To: users@qpid.apache.org
> Sent: Friday, February 24, 2017 11:43:05 AM
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> I tried this (modified to use a temporary queue) and
ly supported because you tested
> on the Master branches. Right?
>
>
> Regards,
>
> Adel
>
>
> From: Robbie Gemmell
> Sent: Friday, February 24, 2017 5:43:05 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dis
, 2017 5:43:05 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
I tried this (modified to use a temporary queue) and also modified the
Qpid JMS HelloWorld example to use a temporary queue, and ran both
against the router successfully multiple times, using
n the above?
>
> Regards,
> Adel
>
>
> ____________
> From: Rob Godfrey
> Sent: Wednesday, February 15, 2017 4:46:59 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> On 15 February 2017 at 16:07, R
Thank you Ganesh.
In that case, I will stick to using qdstat for the moment.
Regards,
Adel
From: Ganesh Murthy
Sent: Wednesday, February 22, 2017 5:12:23 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
- Original Message -
> From: "Adel Boutros"
> To: users@qpid.apache.org
> Sent: Wednesday, February 22, 2017 10:58:42 AM
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> Hello,
>
>
> One more issue: I am trying to replicat
resultObject = (Map)
replyMessage.getObject();
for (Map.Entry entry : resultObject.entrySet()) {
System.out.println(entry.getKey() + ": " + entry.getValue());
}
managementConnection.close();
Regards,
Adel
____________
From: Adel Boutros
Sent: Wednesday, February 22, 2017 12:33:32 PM
4:46:59 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
On 15 February 2017 at 16:07, Robbie Gemmell
wrote:
> On 15 February 2017 at 14:15, Adel Boutros wrote:
> > Hello guys,
> >
> >
> > Based on the discussion, we are
rop.so
> > 7f270eabb000-7f270eabd000 rw-p 4000 00:16 6394000
> /python278/lib/python2.7/lib-dynload/strop.so
> > 7f270eabd000-7f270eafd000 rw-p 00:00 0
> > 7f270eafd000-7f270eb00000 r-xp 0000 00:16 5568749
> /python278/lib/python2.7/lib-dynload/fcntl.so
> >
- Original Message -
> From: "Robbie Gemmell"
> To: users@qpid.apache.org
> Sent: Wednesday, February 15, 2017 10:07:07 AM
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> On 15 February 2017 at 14:15, Adel Boutros wrote:
> > He
ib-dynload/fcntl.so
> 7f270ecff000-7f270ed01000 rw-p 2000 00:16 5568749
> /python278/lib/python2.7/lib-dynload/fcntl.so
> 7f270ed01000-7f270ed04000 r-xp 00:16 5568739
> /python278/lib/python2.7/lib-dynload/_random.so
> 7f270ed04000-7f270e
thon2.7/lib-dynload/_random.so
4272 Aborted (core dumped)
Regards,
Adel
From: Rob Godfrey
Sent: Monday, February 6, 2017 7:09 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
On 6 February 2017 at 19
ble=NONE, expiryPolicy=SESSION_END,
> >>>> timeout=0, dynamic=false, dynamicNodeProperties=null,
> >>>> distributionMode=null, filter=null, defaultOutcome=null,
> outcomes=null,
> >>>> capabilities=null}, target=Target{address='null', durable=NON
edCapabilities=null, desiredCapabilities=null, properties=null}
>>>> [1244186219:0] <- Attach{name='qpid-jms:temp-que
>>>> ue-creator:ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1', handle=0,
>>>> role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
>>
/
ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@
@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\
x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.
apache.qpid.dispatch.connector\xa1\x09operation\
xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-
container\
t;> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0,
>>> linkCredit=250, available=null, drain=false, echo=false, properties=null}
>>> [1244186219:1] ->
>>> Attach{
false, initialDeliveryCount=0, maxMessageSize=0,
>>> offeredCapabilities=null, desiredCapabilities=null, properties=null}
>>> [1244186219:0] <- Flow{nextIncomingId=1, incomingWindow=61,
>>> nextOutgoingId=0, outgoingWindow=2147483647, handle=0, deliveryCount=0,
>
a\xa1/ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.dispatch.connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\xa1\x04role\xa1\x0froute-container\xa1\x04port\xa
bout JMS is the procedural calls when compared to Proton's
> reactive API.
>
>
> Regards,
>
> Adel
>
>
> From: Robbie Gemmell
> Sent: Wednesday, February 1, 2017 5:07:02 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Di
we like about JMS is the procedural calls when compared to Proton's
reactive API.
Regards,
Adel
From: Robbie Gemmell
Sent: Wednesday, February 1, 2017 5:07:02 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
t; target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
>
destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x01\x00Ss\xc0O\x0a\xa1/ID:53f2be62-ad72-4193-a824-3293ffc57168:1:1:1-1@\xa1\x0b$management@@\x83\x00\x00\x01Y\xda\xf4\xd7p\x00St\xc1U\x06\xa1\x04name\xa1\x0frabih.connector\xa1\x04type\xa1"org.apache.qpid.dispatch.connector\xa1\x09operation\xa1\x06CREATE\x00Sw\xc1P\x08\x
t need a local queue, may be we can get the
>> > address of the consumer directly and pass it in reply-to field. Is it
>> > correct?
>> >
>> > Thanks,
>> > Rabih
>> >
>> >
>> >
>> > On Fri, Jan 20, 2017 at 10:18
t in reply-to field. Is it
> > correct?
> >
> > Thanks,
> > Rabih
> >
> >
> >
> > On Fri, Jan 20, 2017 at 10:18 PM, Rob Godfrey
> > wrote:
> >>
> >> On 20 January 2017 at 21:45, Ganesh Murthy wrote:
> >>
> >> &g
t;
>> On 20 January 2017 at 21:45, Ganesh Murthy wrote:
>>
>> >
>> >
>> > - Original Message -
>> > > From: "Robbie Gemmell"
>> > > To: users@qpid.apache.org
>> > > Sent: Friday, January 20, 2017 2:18:45 PM
>
; >
> > - Original Message -
> > > From: "Robbie Gemmell"
> > > To: users@qpid.apache.org
> > > Sent: Friday, January 20, 2017 2:18:45 PM
> > > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> > >
On 20 January 2017 at 21:45, Ganesh Murthy wrote:
>
>
> - Original Message -
> > From: "Robbie Gemmell"
> > To: users@qpid.apache.org
> > Sent: Friday, January 20, 2017 2:18:45 PM
> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Q
- Original Message -
> From: "Robbie Gemmell"
> To: users@qpid.apache.org
> Sent: Friday, January 20, 2017 2:18:45 PM
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> On 20 January 2017 at 19:06, Gordon Sim wrote:
> >
On 20 January 2017 at 19:06, Gordon Sim wrote:
> On 20/01/17 18:40, Rabih M wrote:
>>
>> I inserted the map directly into the ObjectMessage like you told me
>> Robbie and it worked.
>>
>> But like the proton-j case, the connector is not being created on the
>> Qpid-dispatch side.
>> I attached the
On 20/01/17 18:40, Rabih M wrote:
I inserted the map directly into the ObjectMessage like you told me
Robbie and it worked.
But like the proton-j case, the connector is not being created on the
Qpid-dispatch side.
I attached the amqp communication into this mail.
The last frame in that file is
I inserted the map directly into the ObjectMessage like you told me Robbie
and it worked.
But like the proton-j case, the connector is not being created on the
Qpid-dispatch side.
I attached the amqp communication into this mail.
Best regards,
Rabih
On Fri, Jan 20, 2017 at 7:24 PM, Rabih M wrot
Thanks Robbie,
For the JMS, i will try to do that and i will keep you posted for the
result.
Concerning Proton-j:
I configured the Target.
But the connector is still not created on the qpid-dispatch side...
I compared the sent packets using wireshark but i don't think there are
significant diffe
On 20 January 2017 at 17:29, Rabih M wrote:
> Hello,
>
> Thank you for you answers.
>
> I am trying to experiment to see if i can do it with the info you gave me.
>
> I took a simple example to start: qdmanage -b :5672 create
> --type=connector role=route-container addr=broker-machine port=5673
>
Hello,
Thank you for you answers.
I am trying to experiment to see if i can do it with the info you gave me.
I took a simple example to start: qdmanage -b :5672
create --type=connector role=route-container addr=broker-machine port=5673
name=rabih.connector
My goal is to imitate the behavior usin
So I think what we said - and I can't find it written down anywhere in the
draft, though we reference the JSON spec in the pre-amble, is that any
value in the headers or body should be able to be sent in the native AMQP
type (and we might need some words there about converting between various
numer
On 01/18/2017 07:45 AM, Gordon Sim wrote:
On 18/01/17 10:45, Rob Godfrey wrote:
In terms of sending maps/lists I think we said (at OASIS), though it is
possibly not yet in the draft spec, that Json formatted equivalents
should
be able to be used for all values... however I have no idea if the
On 18/01/17 11:49, Robbie Gemmell wrote:
On 18 January 2017 at 10:45, Rob Godfrey wrote:
In terms of sending maps/lists I think we said (at OASIS), though it is
possibly not yet in the draft spec, that Json formatted equivalents should
be able to be used for all values... however I have no idea
On 18/01/17 10:45, Rob Godfrey wrote:
In terms of sending maps/lists I think we said (at OASIS), though it is
possibly not yet in the draft spec, that Json formatted equivalents should
be able to be used for all values... however I have no idea if the Dispatch
Router supports that.
I think that
On 18 January 2017 at 10:45, Rob Godfrey wrote:
> In terms of sending maps/lists I think we said (at OASIS), though it is
> possibly not yet in the draft spec, that Json formatted equivalents should
> be able to be used for all values... however I have no idea if the Dispatch
> Router supports tha
In terms of sending maps/lists I think we said (at OASIS), though it is
possibly not yet in the draft spec, that Json formatted equivalents should
be able to be used for all values... however I have no idea if the Dispatch
Router supports that.
In terms of receiving lists / maps I would assume tha
On 17/01/17 16:03, Rabih M wrote:
Hello,
If I understood well, Qpid-Dispatch can be managed using Amqp messages.
I saw that the management code is based on proton python binding.
Do you think it is feasible to manage the dispatch router the same way from
Qpid-Jms api?
Yes, but only through an
Hello,
If I understood well, Qpid-Dispatch can be managed using Amqp messages.
I saw that the management code is based on proton python binding.
Do you think it is feasible to manage the dispatch router the same way from
Qpid-Jms api?
Was there any work done in this direction before? Will it be t
43 matches
Mail list logo
