Antoine,
I think I know what that problem is. I belileve you've stumbled upon
this issue:
https://issues.apache.org/jira/browse/DISPATCH-496
Your second delivery, the one resulting in a timeout, is causing the
inbound link to be blocked (i.e. it has undelivered messages). When the
broker
We may be able to use load balancer like HAProxy (level 4)
But retry has to be handled; maybe proton-c provide something.
On Friday, 16 September 2016, wrote:
>
>
> Hello,
>
>
> Does the Proton C++ API support the failover url just like JMS does?
>
> If no, what workarounds could I use?
>
>
> Re
Hello,
Does the Proton C++ API support the failover url just like JMS does?
If no, what workarounds could I use?
Regards,
Adel
Get Outlook for Android
On 16/09/16 12:39, Morgan Lindqvist wrote:
Hi all,
I have an issue that data gets corrupted if the size is 66068 but not if it
is 65068 or smaller when using the JavaJMS client. The server is QPIC C++
and SSL encryption is used.
If I instead use a Node JS based client I have no issues with the
Hi all,
I have an issue that data gets corrupted if the size is 66068 but not if it
is 65068 or smaller when using the JavaJMS client. The server is QPIC C++
and SSL encryption is used.
If I instead use a Node JS based client I have no issues with the size of
the messages. I have sent a 1MB large
Hi Ted,
Do you have any insights into that problem?
Thanks,
Antoine
> Hi Ted,
>
> You’re right, the connection close looked strange before stopping of the
broker. I manually added the annotation (# stopping the broker) and was
wrong about the position of this one. I replayed the test and the
con
