[Artemis] Remove queues with wildcard

[Raul Valdoleiros]

Hi,

I've the following scenario:

   - Wildcard configuration active
   - Some subscribers to a queue like "+/example/+"
   - Subscribers of queues like "1/example/1" or "2/example/1"
   - Publishers to queues like "1/example/2"
   - Two brokers connected in a dynamic cluster

I got the following error: AMQ224037: cluster connection Failed to handle
message: java.lang.IllegalStateException: Cannot find binding for
paho/3931EE3876A1F5FFEA.0.2/example/E7718C0BF5D32769791b5e173b-0b45-11e8-9a05-0021f6b39ad7
The impact is the clients are disconnected and I my service stops.

I tried to create a unit test for it:
https://github.com/Skiler/activemq-artemis/commit/195305031bd1b01d4ffa64a9370efceea41177e2

The error is the same but use doesn't seem to be the same.

I added a entry log
in ClusterConnectionImpl$MessageFlowRecordImpl.removeBinding and got the
following log.

[main] 16:37:47,045 INFO
[org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl]
#Remove
7f0196cc5a7dce5a.teste/1/some/18e3a6d92-0db7-11e8-be55-024285a49c96
[Thread-13 (ActiveMQ-client-global-threads)] 16:37:47,064 INFO
[org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl]
#Remove
7f0196cc5a7dce5a.teste/1/some/18e3a6d92-0db7-11e8-be55-024285a49c96
[Thread-13 (ActiveMQ-client-global-threads)] 16:37:47,075 ERROR
[org.apache.activemq.artemis.core.server] AMQ224037: cluster connection
Failed to handle message: java.lang.IllegalStateException: Cannot find
binding for queue
7f0196cc5a7dce5a.teste/1/some/18e3a6d92-0db7-11e8-be55-024285a49c96
at
org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.removeBinding(ClusterConnectionImpl.java:1259)
[:]

So my interpretation is the message for removing the queue is sent twice. I
think the best solution is ignore the action to remove the queue when the
queue doesn't exists, instead of guarantee that only one remove event is
sent.

This solution will make artemis more resilient, it will continue working
even when some inconsistency in the system happens.

I want to know what you think about it, and after that I'm available to fix
the problem.

Thanks,
Raul

Re: [ARTEMIS-2.4] Unable to copy text from console's editor

[Archibald]

Hi, 

Can anyone confirm, that "copy to clipboard" is broken?

Thanks, A.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Can we achieve clustering and distributed feature of ActiveMQ for .net application

[Tim Bain]

ActiveMQ 5.x doesn't support clustering (multiple active brokers all
sharing a set of messages to serve to clients), but Artemis does.

ActiveMQ supports having a client failover between multiple active brokers,
which could be linked together in a network of brokers, but a network of
brokers is not a cluster.

All a client would have to do to failover across multiple brokers is use a
failover URL around the multiple individual URLs (amqp URLs, in your case).

Tim

On Feb 9, 2018 5:29 AM, "bittusrivastava"  wrote:

> Hi,
> Can we achieve clustering and distributed feature of ActiveMQ over AMQP
> protocol using AMQP.net client library Windows platform? if yes , Please
> suggest any pointers .
>
> Thanks
>
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>

Re: Question about rollbackOnlyOnAsyncException (AMQ-3166)

[Tim Bain]

One thing that could cause pauses like that is the JVM's garbage collector.
What GC strategy are you using, and can you see if the times at which the
higher latency occurs correlate with the times at which full GCs are
occurring?

Tim

On Feb 9, 2018 1:53 AM, "alprausch77"  wrote:

> Hello.
> I have a question about the AMQ-3166 issue and the introduced
> 'rollbackOnlyOnAsyncException' flag.
> In the comments of the AMQ-3166 task Gary Tully says
>  /async exceptions on transactional ops - message send and message ack
> will result in the transaction being marked rollback-only. Commit will fail
> with an exception./
>
>
> But if I send the message in async mode than it´s likely that the client
> side transaction is already committed before(!) an exception occurs on
>
> the AMQ side. In that case the TransportConnection class will no longer
> find
> a transaction for the message (as it´s already committed) and of
>
> course it can´t be rolled-back anymore.
> Or do I misunderstand the behaviour?
>
>
> My current problem is that we switched from async to sync sends because
> we´ve seen some messages getting lost without "seeing" it on the client
>
> side. For our use-case it´s not acceptable to have a message loss. So we
> switched to the sync send.
> But this comes with a high performance impact.
> We are seeing a lot of messages to be send in 0-3ms but we see occassional
> spikes in the send times (in the ActiveMQMessageProducer) of 30-500ms.
>
> The 'producerFlowControl' is already disabled in the configuration; the
> storage is mKahaDB.
> And we already tested a lot of configuration combinations with no real
> (positive) effect on the performance.
>
> Is there a way to avoid such spikes in the sync send?
> (Tests has shown that the spikes are most likely caused due to I/O issues.
> Because when using a RAM disk as location for the kahaDB I don´t see
>
> any such spikes.)
>
> Or in async mode: is there a way to have a synchronization on transaction
> commit which verifies that the message is processed?
> This way the message processing could be triggered in async mode and the
> client could do further work and only synchronizes on the transaction
>
> commit.
>
>
> Thanks.
>
> btw: we are running AMQ 5.14.5 (unfortunatelly on Windows)
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>

Can we achieve clustering and distributed feature of ActiveMQ for .net application

[bittusrivastava]

Hi,
Can we achieve clustering and distributed feature of ActiveMQ over AMQP
protocol using AMQP.net client library Windows platform? if yes , Please
suggest any pointers .

Thanks




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Scheduling(delayed delivery) a message AMQP.NETLIBRARY broker: ActiveMQ Windows platform C#

[bittusrivastava]

Hi,
I have seen that scheduling facility available in ActiveMQ. but i am using
amqp.netLibrary for sending messages on amqp protocol using broker activeMQ.
i tried to google as how i can schedule a message using amqp.net library.
but i didnt find any . 
Please help me on this .

Thanks



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Question about rollbackOnlyOnAsyncException (AMQ-3166)

[alprausch77]

Hello.
I have a question about the AMQ-3166 issue and the introduced
'rollbackOnlyOnAsyncException' flag.
In the comments of the AMQ-3166 task Gary Tully says
async exceptions on transactional ops - message send and message ack
will result in the transaction being marked rollback-only. Commit will fail
with an exception.


But if I send the message in async mode than it´s likely that the client
side transaction is already committed before(!) an exception occurs on the
AMQ side. In that case the TransportConnection class will no longer find a
transaction for the message (as it´s already committed) and of course it
can´t be rolled-back anymore.
Or do I misunderstand the behaviour?


My current problem is that we switched from async to sync sends because
we´ve seen some messages getting lost without "seeing" it on the client
side. For our use-case it´s not acceptable to have a message loss. So we
switched to the sync send.
But this comes with a high performance impact.
We are seeing a lot of messages to be send in 0-3ms but we see occassional
spikes in the send times (in the ActiveMQMessageProducer) of 30-500ms. 

The 'producerFlowControl' is already disabled in the configuration; the
storage is mKahaDB.
And we already tested a lot of configuration combinations with no real
(positive) effect on the performance.

Is there a way to avoid such spikes in the sync send?
(Tests has shown that the spikes are most likely caused due to I/O issues.
Because when using a RAM disk as location for the kahaDB I don´t see any
such spikes.)

Or in async mode: is there a way to have a synchronization on transaction
commit which verifies that the message is processed?
This way the message processing could be triggered in async mode and the
client could do further work and only synchronizes on the transaction
commit.

Thanks.
Joachim

btw: we are running AMQ 5.14.5 (unfortunatelly on Windows)



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Question about rollbackOnlyOnAsyncException (AMQ-3166)

[alprausch77]

Hello.
I have a question about the AMQ-3166 issue and the introduced
'rollbackOnlyOnAsyncException' flag.
In the comments of the AMQ-3166 task Gary Tully says
 /async exceptions on transactional ops - message send and message ack
will result in the transaction being marked rollback-only. Commit will fail
with an exception./


But if I send the message in async mode than it´s likely that the client
side transaction is already committed before(!) an exception occurs on 

the AMQ side. In that case the TransportConnection class will no longer find
a transaction for the message (as it´s already committed) and of 

course it can´t be rolled-back anymore.
Or do I misunderstand the behaviour?


My current problem is that we switched from async to sync sends because
we´ve seen some messages getting lost without "seeing" it on the client 

side. For our use-case it´s not acceptable to have a message loss. So we
switched to the sync send.
But this comes with a high performance impact.
We are seeing a lot of messages to be send in 0-3ms but we see occassional
spikes in the send times (in the ActiveMQMessageProducer) of 30-500ms. 

The 'producerFlowControl' is already disabled in the configuration; the
storage is mKahaDB.
And we already tested a lot of configuration combinations with no real
(positive) effect on the performance.

Is there a way to avoid such spikes in the sync send?
(Tests has shown that the spikes are most likely caused due to I/O issues.
Because when using a RAM disk as location for the kahaDB I don´t see 

any such spikes.)

Or in async mode: is there a way to have a synchronization on transaction
commit which verifies that the message is processed?
This way the message processing could be triggered in async mode and the
client could do further work and only synchronizes on the transaction 

commit.


Thanks.

btw: we are running AMQ 5.14.5 (unfortunatelly on Windows)



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html