On 31/03/16 16:35, Gordon Sim wrote:
On 31/03/16 15:31, Toralf Lund wrote:
The reason why I assumed an exclusive *superscription* was that the
I meant subscription, of course :-)
queue is still there after the application stops. Aren't exclusive
queues supposed to go way automatically?
Only
I haven't tried this, but the documentation suggests you can set it:
http://qpid.apache.org/releases/qpid-0.32/messaging-api/cpp/api/classqpid_1_1messaging_1_1Connection.html#aed260d368e7a61444bd20536dd8ee0a8
I don't know which API you are using, but the above may help you.
> -Original Messag
Yes, fixing the bug would of course make the most sense.
Just one more question: In a comment on
https://issues.apache.org/jira/browse/QPID-2410 you wrote
"In a debugger session I forced the AMQP tune max frame size to 16K and
things went swimmingly from there."
Maybe I could first try if this sol
Offhand, your options at this point are:
- Fix the bug (most long-term benefit)
- Write an alternative SSL handling mechanism (more difficult)
- Split them and reassemble at the other end. I don't know anything about your
system so don't know how hard this would be. I've seen a system that does
Hm, this is really getting me into trouble because I need to send encrypted
messages of larger sizes than 16k. Is there really no other option, e.g. to
link qpid with alternative SSL implementations like OpenSSL or NSS? Could I
split up messages into smaller parts and send somehow guarantee that th
That's the one... there is no workaround at this time, but Cliff's recent
analysis provides a way forward for someone to work on.
> -Original Message-
> From: rat...@web.de [mailto:rat...@web.de]
> Sent: Thursday, March 31, 2016 3:35 PM
> To: users@qpid.apache.org
> Subject: Re: SSL maxim
Yes, that is what I usually use.
On Thu, Mar 31, 2016 at 9:46 PM, Flores, Paul A.
wrote:
> Thanks for the inputs!
>
> In regards to a 'response' queue. I am making an assumption that they
> would be temporary and would be deleted when the receiver is closed, right?
>
> _
Thanks for the inputs!
In regards to a 'response' queue. I am making an assumption that they would be
temporary and would be deleted when the receiver is closed, right?
From: Jakub Scholz [ja...@scholz.cz]
Sent: Thursday, March 31, 2016 1:43 PM
To: users
Sure, I'll do that asap. Meanwhile, I found a bug report that seems to be
very related (its from 2010 but appearantly still unfixed)
https://issues.apache.org/jira/browse/QPID-2410
Even the 16K message size seems to be consistent with my tests. I did not
fully understand the comments in the bug rep
On 31/03/16 20:08, rat...@web.de wrote:
Both c++ client and server are running on Windows 10 64 bit. AMQP version is
0-10. The qpid java message broker is running on Ubuntu, but I suspect that
the bug is already on the c++ client / server side.
Any hints how to resove this issue?
Getting a prot
Both c++ client and server are running on Windows 10 64 bit. AMQP version is
0-10. The qpid java message broker is running on Ubuntu, but I suspect that
the bug is already on the c++ client / server side.
Any hints how to resove this issue?
Thx for your help...
--
View this message in context:
If you are using temporary queues, I think you should first create the
receivers before sending the request. Otherwise, if the responder is fast
it might send the delivery_ack / response before you create the receivers.
I would probably also use the same address for both the delivery
acknowledgemen
Thanks!
Regards,Adel
> Subject: Re: Qpid C++ Broker unbind with qpid-qmf tools doesn't work if no
> binding key is specified
> To: users@qpid.apache.org
> From: g...@redhat.com
> Date: Thu, 31 Mar 2016 18:14:18 +0100
>
> On 31/03/16 17:57, Adel Boutros wrote:
> > in case I have multiple bindings
On 31/03/16 17:57, Adel Boutros wrote:
in case I have multiple bindings between the same queue and topic with
different binding keys and I want to remove them all, then I have to unbind
them one by one?
Yes, I'm afraid so.
-
+1
On Wed, 2016-03-30 at 11:25 +0100, Robbie Gemmell wrote:
> Hello folks,
>
> Many moons ago, a seperate mailing list was established for Proton,
> back when it was purely a protocol engine other components would use.
> Its scope has since expanded beyond that and the separate mailing
> list
> h
Hello -
We are leveraging proton-j via the reactor framework and noticed a discrepancy
between proton-c and proton-j. With proton-c, we are able to establish 2-way
authentication via SSL but with proton-j that is unsuccessful. We opened a
JIRA on this yesterday but figured we'd ping the lists
Thank you Gordon!
One last question, in case I have multiple bindings between the same queue and
topic with different binding keys and I want to remove them all, then I have to
unbind them one by one?
Regards,Adel
> Subject: Re: Qpid C++ Broker unbind with qpid-qmf tools doesn't work if no
> bi
On 31/03/16 17:38, Adel Boutros wrote:
Hello,
I am using Qpid C++ Broker 0.34 and qpid-qmf2 0.32 (Java). I have noticed that
when I try to unbind a queue and an exchange without specifying a binding key,
nothing happens. However, when I provide a binding key, the corresponding
binding is delet
On 03/30/2016 07:12 AM, Robbie Gemmell wrote:
On 30 March 2016 at 11:40, Oleksandr Rudyy wrote:
Hi Robbie,
I would like to clarify the name of a connection parameter to disable
sending of UserID for both new and legacy JMS clients.
New JIRA QPIDJMS-163 requires to implement toggle to enable/di
Hello,
I am using Qpid C++ Broker 0.34 and qpid-qmf2 0.32 (Java). I have noticed that
when I try to unbind a queue and an exchange without specifying a binding key,
nothing happens. However, when I provide a binding key, the corresponding
binding is deleted.
I have the same issue on Python side
And which OS is the C++ part on? There was discussion of a buffer overrun on
Windows w/ SSL a short while back.
> -Original Message-
> From: Rob Godfrey [mailto:rob.j.godf...@gmail.com]
> Sent: Thursday, March 31, 2016 11:42 AM
> To: users@qpid.apache.org
> Subject: Re: SSL maximum messag
That sounds like a bug - can you confirm which version of the AMQP protocol
you are using (0-10 or 1.0)?
Thanks,
Rob
On 31 March 2016 at 16:38, rat...@web.de wrote:
> By the way, I'm using the Java Broker version 6.0.1 together with the qpid
> c++ messaging api.
>
>
>
> --
> View this message i
By the way, I'm using the Java Broker version 6.0.1 together with the qpid
c++ messaging api.
--
View this message in context:
http://qpid.2158936.n2.nabble.com/SSL-maximum-message-size-tp7641114p7641115.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
-
Hi,
I have noticed that there seems to be a maximum message size if connecting
via ssl.
I have a request-reply pattern where the client sends a text and the server
answers with the identical text.
When connecting via "amqp:tcp:servername:5672" I can increase the message
length as much as I want.
Wh
On 31/03/16 15:31, Toralf Lund wrote:
The reason why I assumed an exclusive *superscription* was that the
queue is still there after the application stops. Aren't exclusive
queues supposed to go way automatically?
Only if they are also auto-delete queues.
-
This is the idealized flow as I see it. Any comments?
The Requestor:
Set up addresses in the request message for both:
reply to ->(#response)
delivery acknowledgement ->(#delivery_ack) a 'custom' message property that
will need to be added
Send the request ->send(request, true) ):
after prelim
On 31/03/16 15:05, Gordon Sim wrote:
On 31/03/16 13:27, Toralf Lund wrote:
Hi,
I just encountered an issue related to running one of my QPid
applications in parallel by 3rd party software that receives from the
same queue. I notice that when I start the latter, the queue attributes
as reported
On 31/03/16 13:27, Toralf Lund wrote:
Hi,
I just encountered an issue related to running one of my QPid
applications in parallel by 3rd party software that receives from the
same queue. I notice that when I start the latter, the queue attributes
as reported by qpid-config change from
--durable
Hi,
I just encountered an issue related to running one of my QPid
applications in parallel by 3rd party software that receives from the
same queue. I notice that when I start the latter, the queue attributes
as reported by qpid-config change from
--durable --replicate=all --lvq-key=qpid.subj
+1
On 30/03/16 11:25, Robbie Gemmell wrote:
Hello folks,
Many moons ago, a seperate mailing list was established for Proton,
back when it was purely a protocol engine other components would use.
Its scope has since expanded beyond that and the separate mailing list
has I feel been an increasin
30 matches
Mail list logo
