I get the following error in the broker, looks like the same error as
QPID-5033. The broker is built from the trunk using VS2015 and is running
on Server 2012 R2.
2016-05-26 05:22:23 [Protocol] trace [10.0.0.8:5671-121.215.240.156:38078]:
0 -> @end(23) []
2016-05-26 05:22:23 [Protocol] trace [1
Hello,Robbie Gemmell
Thank you very much,According to your suggestion,I re-generated certificate
with the issue organization 's name "stevenGu",Which is the same name with
Qpid Server name.upload my broker trustore file and broker keystore file
into Qpid Server.add a new port 5674 pointed for trus
Thanks,
Sorry for the missing lines... I'd used the 'raw' tags in nabble in an
attempt to stop it stripping characters... seems it had the opposite effect.
The reason I was sending binary in the first place is because that's what
the python sender was doing when just assigning a string to the bod
Thanks, Cliff. It's now approved.
On Wed, May 25, 2016 at 10:40 AM, Cliff Jansen
wrote:
> https://issues.apache.org/jira/browse/PROTON-1211
>
> I would propose including this fix in 0.13. I marked the bug a
> blocker since it can prevent messages being sent. It has been
> reviewed by Alan.
>
On Wed, 2016-05-25 at 13:15 -0400, Andrew Stitcher wrote:
> On Tue, 2016-05-24 at 23:14 -0700, fredbasset wrote:
> >
> > I've been trying out the 0.13.x branch of the Proton C++ bindings,
> > and it
> > seems that decoding a binary type into a string has stopped working
> > since
> > 0.12
> >
> >
https://issues.apache.org/jira/browse/PROTON-1211
I would propose including this fix in 0.13. I marked the bug a
blocker since it can prevent messages being sent. It has been
reviewed by Alan.
Cliff
-
To unsubscribe, e-mail: u
My understanding from the Python bits, and confirmed by discussing
with Andrew for the C++ bits, is that 'auto-settle' settles the
delivery at the sender side after the receiving peer accepts/etc its,
allowing for the delivery state to be cleared up locally, whereas if
that wasn't in place the appl
On Tue, 2016-05-24 at 23:14 -0700, fredbasset wrote:
> I've been trying out the 0.13.x branch of the Proton C++ bindings,
> and it
> seems that decoding a binary type into a string has stopped working
> since
> 0.12
>
> I believe that theĀ
>
>
>
> function is missing the line
>
>
>
> I'm not
On Wed, 2016-05-25 at 18:51 +0200, Adel Boutros wrote:
> Hello Andrew,
> His message is actually full on Nabble: http://qpid.2158936.n2.nabble
> .com/Proton-C-0-13-x-decode-binary-type-tp7644510.html
> Regards,Adel
Ah, okay - I really don't need to have to monitor a web site as well as
a mailing l
Hello Andrew,
His message is actually full on Nabble:
http://qpid.2158936.n2.nabble.com/Proton-C-0-13-x-decode-binary-type-tp7644510.html
Regards,Adel
> Subject: Re: Proton C++ 0.13.x decode binary type
> From: astitc...@redhat.com
> To: users@qpid.apache.org
> Date: Wed, 25 May 2016 12:46:57 -04
On Tue, 2016-05-24 at 23:14 -0700, fredbasset wrote:
> I've been trying out the 0.13.x branch of the Proton C++ bindings,
> and it
> seems that decoding a binary type into a string has stopped working
> since
> 0.12
>
> I believe that theĀ
>
>
>
> function is missing the line
>
>
It seems th
The below code was enough actually:
void MessagingSendOneHandler::on_sendable(proton::event &e){ for (int i = 0;
i < nbOfTimesToSend; ++i) { e.sender().send(msg); }
e.connection().close();}
The issue is closed from my side.
Regards,Adel
> Subject: Re: [qpid-dispatch] No load balanc
However, it's easy to do synchronous sends in the reactive API. Use
on_settled as the trigger to send the next message.
-Ted
On 05/25/2016 10:34 AM, Robbie Gemmell wrote:
There isn't an equivalent since it is inherently async, as you
supposed it may be.
Robbie
On 25 May 2016 at 15:04, Adel
Sending pre-settled messages removes any delivery indication. It also
causes problems in Dispatch Router if you send large volumes of them to
slow receivers (see https://issues.apache.org/jira/browse/DISPATCH-336).
This will be fixed, but not in time for 0.6.0.
-Ted
On 05/25/2016 10:37 AM,
There isn't an equivalent since it is inherently async, as you
supposed it may be.
Robbie
On 25 May 2016 at 15:04, Adel Boutros wrote:
>
>
>
> One last question: What is the equivalent of "jms.forceAsyncSend=true" in
> Proton C++? Is it by default like that because of the reactor/handler api?
>
I swear this is the final question: Then what is the impact of "auto_settle" in
proton::handler on this if there is any? I looked at the code and when a
message is sent, the delivery is settled but I don't quite get what this is and
if it is related to the below?
Adel
> Date: Wed, 25 May 2016 1
One last question: What is the equivalent of "jms.forceAsyncSend=true" in
Proton C++? Is it by default like that because of the reactor/handler api?
Regards,Adel
> From: adelbout...@live.com
> To: users@qpid.apache.org
> Subject: RE: [qpid-dispatch] No load balancing if destination is availabl
I don't think there is a way in the C++ broker how to include the CA in the
identity - it is always taken from the certificate it self only.
Are you using regular public CA (e.g. Verisign)? Or some private
certification authority? I think that the common name is supposed to carry
some information
On 24/05/16 16:41, Gordon Sim wrote:
On 24/05/16 15:28, Toralf Lund wrote:
On 24/05/16 13:22, Gordon Sim wrote:
On 24/05/16 12:20, Gordon Sim wrote:
if you run:
qpid-config queues
and:
qpid-send -q
I think that should allow us to see if there is any queue near its
limit.
qpid-config
On 25 May 2016 at 11:14, Steven wrote:
> Hello,Robbie Gemmell
>
> This time I try to use hostname rather than IP address,Below is my
> connection URL:
> connectionfactory.qpidConnectionfactory =
> amqps://QpidServer:5673?transport.trustStoreLocation=F:/AMQP/QpidSSL/clientts.jks&transport.trustStor
Hi,
Is it possible to write ACL so that it takes into account both
certificate common name and ca certificate that issued it when
granting access rights?
What I'm trying to do:
I'm using SSL authentication and ACL with C++ qpid broker like this:
- On broker side I have acl file with @QPID
entrie
On 25/05/16 11:14, Steven wrote:
Caused by: java.security.cert.CertificateException: No name matching
QpidServer found
at sun.security.util.HostnameChecker.matchDNS(Unknown Source)
at sun.security.util.HostnameChecker.match(Unknown Source)
at sun.security.ssl.X509TrustMana
Hello,Robbie Gemmell
This time I try to use hostname rather than IP address,Below is my
connection URL:
connectionfactory.qpidConnectionfactory =
amqps://QpidServer:5673?transport.trustStoreLocation=F:/AMQP/QpidSSL/clientts.jks&transport.trustStorePassword=123456
It still reported the following
There were 7 binding +1 votes, and no other votes received. The vote has
passed.
Voting thread:
http://qpid.2158936.n2.nabble.com/VOTE-Release-Qpid-Java-6-0-3-RC3-td7644268.html
I am going to publish release artifacts into dist release repo and maven
repo.
The website will be updated later after
On 25/05/16 09:25, Adel Boutros wrote:
Hello,
From time to time, we have this annoying random bug when using proton-c client:
Error: amqp:connection:forced: Requested idle timeout of 776 is too low. The
minimum supported timeout is1000.
The value of the timeout is random: sometimes it is as low
On 25/05/16 07:14, fredbasset wrote:
On a related note, using the Python Proton bindings to send a message, if I
set the message.body to a string value it gets encoded as binary (hence the
issue above!) - how do I set the body to be a string value, or any other
'Data' object. I've tried message.b
Hello,
>From time to time, we have this annoying random bug when using proton-c client:
Error: amqp:connection:forced: Requested idle timeout of 776 is too low. The
minimum supported timeout is1000.
The value of the timeout is random: sometimes it is as low as "2" and sometimes
as high as "998".
On 05/25/2016 07:33 AM, Atul Singh Mandla wrote:
Hi all, I am facing a problem while building qpid-proton.
--
checking pkg-config is at least version 0.9.0... yes
checking for uuid_generate in -lu
I've been trying out the 0.13.x branch of the Proton C++ bindings, and it
seems that decoding a binary type into a string has stopped working since
0.12
I believe that the
function is missing the line
I'm not sure if this is intentional or not, but if it isn't is there any
chance of getting
Hi all, I am facing a problem while building qpid-proton.
--
checking pkg-config is at least version 0.9.0... yes
checking for uuid_generate in -luuid... no
configure: error: external uuid library n
30 matches
Mail list logo