Thanks Rob! Agreed on the stracktrace. Not sure why I did not attach it in
the first place.
But regardless of this, you are right about the Lock Duration! Altering
that value fixed my issue.
Thanks again,
Martín
On Mon, Nov 25, 2019 at 2:52 PM Rob Godfrey wrote:
> Hi Martin,
>
> I'm pretty sur
Hi Martin,
I'm pretty sure this is an Azure Service Bus "feature" rather than anything
on the client side. I'm no expert on Service Bus, but I believe it grants
a "lock" on the message for the consumer to process it, and then revokes
the lock if processing has not completed within a timeout perio
Hi!
I am using qpid-jms-client version 0.40.0 to connect to Azure Service Bus,
but the same happens with the latest, 0.46.0. I'm having issues with the
acknowledge process.
My application receives a message from a queue or topic, and then processes
it. It then does a manual ack.
If this processin
pires and response for db ping is not
> received, the node is considered UNREACHABLE and operational logs are
> generated like the ones below
> HA-1006 : Left : Node : 'TEST_HA' (testnode1:5050)
> HA-1010 : Role change reported: Node : 'TEST_TEST_HA' (testnode1:5050
ket to remote node. The
value for this timeout is set with context variable
qpid.bdb.ha.db_ping_socket_timeout. The default value is also set to 1000
milliseconds.
It seems that in your environment the default values for timeouts can be
increased in order to reduce the amount of misleading logs reported due to
e
are geographically nearly each
other) is on average 2ms.
What I see on a periodic basis is the constant timeouts between the nodes,
which always recover approximately one second later.
Log on node 1:
2019-04-10 20:35:24,898 WARN [Group-Change-Learner:fix_test:RCO_TEST_HA1
On 02/02/2015 11:24 PM, Jakub Scholz wrote:
Hi,
While playing with the C++ qpid.messaging client and the Java broker (both
from release 0.30), I noticed that the fetch() command with a timeout never
timeouts. It seems to be reproducible even with the qpid-receive:
qpid-receive -b admin/admin
Hi,
While playing with the C++ qpid.messaging client and the Java broker (both
from release 0.30), I noticed that the fetch() command with a timeout never
timeouts. It seems to be reproducible even with the qpid-receive:
qpid-receive -b admin/admin@192.168.33.1:5672 -a "testQueue; { node: {
:57,899 DEBUG
>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>> ConnectionHeartbeat()
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:58,618 DEBUG
>> [apache.qpid.transport.Connection] connection closed: conn:9ced8e
>>
>>
>> I'm a bi
name)
The topic is the value retrieved from JNDI and name is a unique
identifier for your subscription.
There should be no need to define a custom URL in the JNDI property file.
Cheers
Martin
> I was able to successfully build from trunk. I changed nothing in my test
> program, but now I am no lon
;> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:57,899 DEBUG
>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>> ConnectionHeartbeat()
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:58,618 DEBUG
>> [apache.qpid.transport.Connection] connection closed: con
am, but now I am no longer getting timeouts and I see the heartbeat
> replies in the log messages coming from my client:
> 2010-01-06 12:02:01,703 INFO [Dispatcher-Channel-1]
> client.AMQSession$Dispatcher (AMQSession.java:2910) - Dispatcher-Channel-1
> started
> 2010-01-06 12:0
know, I am happy to use the JMS API otherwise.
I was able to successfully build from trunk. I changed nothing in my test
program, but now I am no longer getting timeouts and I see the heartbeat
replies in the log messages coming from my client:
2010-01-06 12:02:01,703 INFO [Dispatcher
are subject to change without any notice btw versions.
> Here some sample code. Maybe you can tell me what I'm doing wrong
I cut paste your code and added an exception listener to the
connection and I didn't see any timeouts.
If I did a kill -STOP then I saw a the client droppin
;> Sent: Tuesday, January 05, 2010 6:48 PM
>> To: users@qpid.apache.org
>> Subject: timeouts
>>
>>
>> Hello,
>>
>> I have a Java client listener that subscribes to a topic and waits for
>> messages. I'm noticing after 120 seconds of idle
gt;>> [apache.qpid.transport.ClientDelegate] Ignoring the idle timeout 0 set by
>>> the connection, using the brokers max value 120
>>>
>>> and
>>>
>>>
>>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:38:57,898 DEBUG
>>> [apache.
> IoReceiver - /192.168.10.128:5672 2010-01-05 12:38:57,898 DEBUG
>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>> ConnectionHeartbeat()
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:57,899 DEBUG
>> [apache.qpid.transport.Connection] RECV: [
JAkub Scholz
> -Original Message-
> From: Jen Andre [mailto:jan...@gmail.com]
> Sent: Tuesday, January 05, 2010 6:48 PM
> To: users@qpid.apache.org
> Subject: timeouts
>
>
> Hello,
>
> I have a Java client listener that subscribes to a topic and waits for
168.10.128:5672 2010-01-05 12:40:58,618 DEBUG
> [apache.qpid.transport.Connection] connection closed: conn:9ced8e
>
>
> I'm a bit confused on how timeouts and heartbeats are supposed to work.
> Does the client force the disconnect, or the server, or both, if the
> heartbeats ar
168.10.128:5672 2010-01-05 12:40:58,618 DEBUG
[apache.qpid.transport.Connection] connection closed: conn:9ced8e
I'm a bit confused on how timeouts and heartbeats are supposed to work.
Does the client force the disconnect, or the server, or both, if the
heartbeats are not received in a spe
20 matches
Mail list logo
