Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/2113
@clebertsuconic We are using Artemis as a fast event/message bus for AMQP
communication between (micro-)services developed and operated by different
organizational units.
Each service
Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/2115
@clebertsuconic Looks like all the comments have been addressed here. Also
this approach solves a number of related issues around reliance on the AMQP To
field for the address info.
Hi,
I have implemented the failover transport and TransportListener interface.
So, the transport listener receives the interrupt/resume and sets an
internal flag in the connector itself, lets call it connectionActive. When a
message gets dequeued for sending by the connector, I take an optimistic
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2115
---
I'm working on cutting 2.6.1 now..
On Fri, May 25, 2018 at 12:35 PM, Clebert Suconic
wrote:
> I have the payload for 2.6.1 pretty much defined here:
>
> https://github.com/apache/activemq-artemis/compare/2.6.0...2.6.x
>
>
> I just want to include the work I'm doing now on some Bridge working
>
The current workaround we've been testing is to change to the TCP transport
from the VM transport on the code that runs inside the broker process (where
we want to guarantee that some queues or topics are always are being dealt
with as long as ActiveMQ is running). That seems like it would be a
Yeah, TCP should be fine. Even if this gets fixed it will take time before
a new release is done anyways so you'll need to use the TCP or NIO for a
bit.
On Thu, May 31, 2018 at 3:55 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
> Found the culprit: Seems to be related to
I put some text in the (very long) README in the reproduction project that
kind of addresses this, but I didn't really specify that yes - I did throw
in a debug library of the wrapper that printed out when the getText() call
returned null at the call site, and it absolutely is returning null (the
Sounds like that is getting into details that JMS intends to handle.
At some level, every application is going to need to chose between the
possibility of duplicating a message, or losing a message. There is no way
to 100% avoid both cases at the same time. With that said, ActiveMQ has
A lot of changes happened between 5.10 and 5.15. Knowing the first version
that it broke would be helpful to narrow down the change that broke it.
Even better would be to use 'git bisect' and find the exact commit that
introduced the issue.
On Thu, May 31, 2018 at 3:14 PM, codingismy11to7
Ok, thank you...my thought also was that performance impact of using tcp
wouldn't be enough to hurt us in any substantial way, even though it *feels*
really wasteful to be marshaling the message and using TCP when we're in the
same JVM.
In response to your first message, I changed the transport
Found the culprit: Seems to be related to
https://issues.apache.org/jira/browse/AMQ-5857
Specifically, this commit:
I thought you were sending a patch.
On Thu, May 31, 2018 at 11:33 AM Jasmeet Ajmani
wrote:
> Hi,
>
> Any update on this ?
>
> Thanks.
>
> From: Jasmeet Ajmani
> Sent: Friday, May 25, 2018 12:01 PM
> To: 'dev@activemq.apache.org'
> Cc: Martin Ross
> Subject: Custom serialization mechanism for
Another thing I didn't dig into earlier - I generally avoid the VM
transport. At some point in the past, I ran into a deadlock with the VM
transport that doesn't exist with the other transports because the VM
transport performs an operation synchronously that the interface explicitly
defines as
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/2113
I take this as a nice improvement.. but it's not a 100% bug fix.. so I will
merge this.. but keep it out of 2.6.1.
---
I did some quick testing and it looks like the first version it breaks is
5.12.0. It seemed to work ok in 5.11.3.
5.12.0 was a big release though with over 200 issues so will still need to
narrow it down more.
In the meantime I would say if the TCP transport works then go with that, I
doubt you
Hello Apache Supporters and Enthusiasts
This is a reminder that our Apache EU Roadshow in Berlin is less than
two weeks away and we need your help to spread the word. Please let your
work colleagues, friends and anyone interested in any attending know
about our Apache EU Roadshow event.
We
Art,
Concurrent store and dispatch should be off by default for topics (which I
believe the test case is using). Also, it wouldn't hit the store since
it's a topic and not a durable subscription so should just be in memory.
That's why this issue is weird as the messages shouldn't be concurrently
GitHub user clebertsuconic opened a pull request:
https://github.com/apache/activemq-artemis/pull/2117
NO-JIRA update release instruction with git-release-report
You can merge this pull request into a Git repository by running:
$ git pull
I would like to propose an Apache ActiveMQ Artemis 2.6.1 release.
This is a micro release, with bug fixes only.
I would like to highlight two important fixes as part of this release:
[ARTEMIS-1568] Expired Messages were not transversing clustering redistribution.
(this could affect other
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2113
---
Ahh, I bet that is a result of using the VM transport. The broker is
likely doing the "beforeMarshal()" call that clears the text just before
the client is calling "getText()" on the same message - or just before
"copy()" is called to make a copy of the message.
Yeah, looking at the code
Steven,
I think you might need to do some more debugging to try and pinpoint the
exact point where the body is null unless others have more time to look at
it. As Art said, check different points where the body could be null.
I originally thought I had found the issue when I tested
The issue is when using the VM transport and the getText() method has to
unmarshall data back into text from the byte sequence. This happens
because you go from the NIO to VM transport.
The main problem is you have multiple threads (3 consumers) at the same
time calling getText() on the text
I forgot that when using the VM transport the message is supposed to be
copied on dispatch inside ActiveMQConnection so this may not be the exact
issue, I need to look at it a bit more.
On Thu, May 31, 2018 at 9:41 AM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
> The issue is
Hi,
Any update on this ?
Thanks.
From: Jasmeet Ajmani
Sent: Friday, May 25, 2018 12:01 PM
To: 'dev@activemq.apache.org'
Cc: Martin Ross
Subject: Custom serialization mechanism for ActiveMQMessages
Hi,
We would like to use custom serialization on ActiveMQMessages and the current
build of
26 matches
Mail list logo
