Thank your for your exhaustive answer.
Am 09.12.20 um 16:53 schrieb Robbie Gemmell:
>> That said, Qpid JMS and at least the Qpid brokers have long supported
>> (along with ActiveMQ Artemis more recently) an escape of "quoting" the
>> contents of the 'property name' variable for bypassing some of
On 09/12/2020 18:36, Toralf Lund wrote:
On 09/12/2020 19:16, Gordon Sim wrote:
On 09/12/2020 13:35, Toralf Lund wrote:
My question is simply, what might cause the send to take several
seconds? I can't see any reason why the communication itself should
be that slow; the software runs on a machi
On 09/12/2020 19:16, Gordon Sim wrote:
On 09/12/2020 13:35, Toralf Lund wrote:
My question is simply, what might cause the send to take several
seconds? I can't see any reason why the communication itself should
be that slow; the software runs on a machine that's connected to the
same network
> Date: Wednesday, December 9, 2020 at 10:53 AM
> > It appears like there is no way around this validation.
>
> Not at present.
> Date: Wednesday, December 9, 2020 at 10:39 AM
> Here is a branch with a change adding support for a "jms.validateSelector"
> URI option..
Wow Robbie – Your enhancemen
On 09/12/2020 13:35, Toralf Lund wrote:
My question is simply, what might cause the send to take several
seconds? I can't see any reason why the communication itself should be
that slow; the software runs on a machine that's connected to the same
network switch as the broker. The systems do hav
On Wed, 9 Dec 2020 at 16:37, akabhishek1
wrote:
>
> Hi Robbie,
>
> Thanks a lot for details insight and correction. Test case is working fine
> now with 0.56-SNAPSHOT.
> I am able to generate invalid message which continously throw 'Cannot decode
> String in UTF-8' error.
>
> The good thing is - I
On 09/12/2020 17:31, Chester wrote:
Is it possibly a nagle problem? We always set "tcp_nodelay: true" in our
configs...
That's also done in this application. Or at least it's supposed to be.
Perhaps worth checking if the option actually gets enabled the right way...
We also re-use session
Hi Robbie,
Thanks a lot for details insight and correction. Test case is working fine
now with 0.56-SNAPSHOT.
I am able to generate invalid message which continously throw 'Cannot decode
String in UTF-8' error.
The good thing is - I am able to generate "Suspected deadlocked threads"
error repeate
Is it possibly a nagle problem? We always set "tcp_nodelay: true" in our
configs... We also re-use sessions throughout the application lifetime.
On Wed, Dec 9, 2020 at 8:36 AM Toralf Lund wrote:
> I'm still debugging the communication issues I've been struggling with
> for months - where there a
On Wed, 2 Dec 2020 at 12:02, Robbie Gemmell wrote:
>
> On Tue, 24 Nov 2020 at 17:00, Robbie Gemmell wrote:
> >
> > On Tue, 24 Nov 2020 at 16:30, Jiri Daněk wrote:
> > >
> > > On Tue, Nov 24, 2020 at 4:52 PM Robbie Gemmell
> > > wrote:
> > >
> > > > On Tue, 24 Nov 2020 at 14:44, Ganesh Murthy w
On Wed, 9 Dec 2020 at 15:39, Robbie Gemmell wrote:
>
> On Tue, 8 Dec 2020 at 22:21, Michael Walser wrote:
> >
> > Hello,
> >
> > I'm attempting to use Qpid JMS to connect to an AMQP 1.0 server (namely
> > Azure Event Hubs). To be able to start consuming messages at a certain
> > offset I have to
On Tue, 8 Dec 2020 at 22:21, Michael Walser wrote:
>
> Hello,
>
> I'm attempting to use Qpid JMS to connect to an AMQP 1.0 server (namely
> Azure Event Hubs). To be able to start consuming messages at a certain
> offset I have to set a message filter.
>
> The filters reads like this:
> amqp.an
I'm still debugging the communication issues I've been struggling with
for months - where there are unexpected delays in (I think) message
passing between a C++ Messaging API application and a C++ broker. I've
now narrowed down the problem to the send() call, I believe. I'm using
the following
13 matches
Mail list logo
