[GitHub] activemq-artemis pull request #2179: NO-JIRAs
GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/2179 NO-JIRAs You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis tests Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2179.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2179 commit 6d20a70cc1a3604695ab6d09fd627a427760f401 Author: Clebert Suconic Date: 2018-07-11T18:34:34Z NO-JIRA Removing System.err style debug left by accident This is non critical. The message is only used by Queue.pause ATM. commit 2dfba97a4478e247209d529116d0ba760314ac40 Author: Clebert Suconic Date: 2018-07-11T18:34:13Z NO-JIRA Adding missing check on ClientCrashTest commit d2623d6a0b51bc8632fe5b20bb5d748a0e601c5f Author: Clebert Suconic Date: 2018-07-11T20:25:22Z NO-JIRA Improve SpawnVMCheck ---
[GitHub] activemq pull request #286: [WFLY-6597] Change org.apache.activemq.jms.pool....
GitHub user tadamski opened a pull request: https://github.com/apache/activemq/pull/286 [WFLY-6597] Change org.apache.activemq.jms.pool.XaPooledConnectionFac⦠â¦tory#tmFromJndi parameter to Boolean for JCA validation You can merge this pull request into a Git repository by running: $ git pull https://github.com/tadamski/activemq WFLY-6597 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq/pull/286.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #286 commit ac1668086c10e03ff421f8d8757981e5bdfc79a2 Author: Tomasz Adamski Date: 2018-07-11T19:01:30Z [WFLY-6597] Change org.apache.activemq.jms.pool.XaPooledConnectionFactory#tmFromJndi parameter to Boolean for JCA validation ---
Re: TextMessage.getText returning null
If concurrent access can be reproduced in a dev environment, it is possible - with temporary code changes - to determine what two threads were accessing the message at the same time. An effective means to track this down is to record Exception objects (and hence stack traces) at each point accessing the fields of concern. Then, when the problem is detected, dump the stack traces of those exceptions. Also - on the "saving space" topic - is the text field actually storing a copy of the bytes, or is it backed by the same memory used by the byte array? I'd be very curious to see that. I'm also curious about the "isn't tracked" assertion. Hope this helps. Art On Thu, May 31, 2018 at 4:56 PM, Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > 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 > touched by any thread since they get copied. (but there still seems to be > something going on that i am missing off the top of my head involving > multiple threads touching the message) > > Clearing the text field is important because it prevents memory waste. The > explanation is explained more in https://issues.apache.org/ > jira/browse/AMQ-5857 If you don't clear it then extra memory is used that > isn't tracked and can lead to OOM errors (it's why the > reduceMemoryFootprintFlag exists in the broker). So I think that change is > probably ok but a side effect is causing this other issue to pop up. > > When I was doing some testing today, I tried a couple variations of > synchronization (using volatile, adding mutexes in places, etc) and some > worked and some didn't. One thing that was interesting was that when I > synchronized on the copy() method of ActiveMQText message the issue was > fixed. That is weird however because we shouldn't need to sync on copy. > So either there is a problem with copy() itself or adding the > synchronization is throwing off the timing just enough to hide the real > issue. > > Ultimately I think adding synchronization in a test (like what you did) > will be useful to track down the problem since I think it's a race > condition issue but as a permanently fix I would avoid it. The reason is > that it shouldn't be needed...the objects are designed to only be accessed > by one thread at a time and copied if necessary which makes sense to me. > However if adding synchronization does fix the issue then hopefully it will > at least be a clue as to what the real issue is. > > Chris > > On Thu, May 31, 2018 at 5:41 PM, Arthur Naseef wrote: > > > 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 carefully - the storeContent() method is > handling > > "text != null" with "content = null" by converting text to a byte > sequence > > ( > > org.apache.activemq.util.ByteSequence) and stuffing that into "content". > > > > If all this happens concurrent with a copy() or a call to getText(), then > > it's entirely possible to get this race condition. So, disabling > > "concurrent store and dispatch" could solve this problem. Also, using > > critical sections in "storeContentAndClear()" as well as "getText()" > might > > eliminate the race condition. > > > > With all that said, I don't see the big win of clearing the text field in > > storeContentAndClear(). > > > > @Chris - can you try the patch here and see if it eliminates the problem? > > https://gist.github.com/artnaseef/d518c0431a34cd3d49e8d6e045a719e2 > > > > I may have missed some paths that access both "text" and "content", but I > > think I got the important ones. If that patch works, that increases > > confidence that you found the right race condition. > > > > Art > > > > > > > > On Thu, May 31, 2018 at 12:55 PM, Christopher Shannon < > > christopher.l.shan...@gmail.com> wrote: > > > > > Found the culprit: Seems to be related to > > > https://issues.apache.org/jira/browse/AMQ-5857 > > > > > > Specifically, this commit: > > > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a= > > > blobdiff;f=activemq-client/src/main/java/org/apache/activemq/command/ > > > ActiveMQTextMessage.java;h=cca09be21bfb877213a4a506415929 > f1f81a1902;hp= > > > 347db78da559bf57b049574c96cd3a8e08681dae;hb=84ec047;hpb= > > > de86f473f776fe3a8ca32d7f929ecec7993c458b > > > > > > Changing the storeContentAndClear() call back to storeContent() fixes > it, > > > however it was changed for a reason to prevent memory waste so need to > > see > > > if/what a permanent fix is > > > > > > > > > On Thu, May 31, 2018 at 3:54 PM,
Re: Regular and intermittent interrupt/resume between broker and client connector
Re-reading through my email backlog, I noticed this. ActiveMQ already provides that type of persistence and guarantee of delivery. Any additional implementation seems redundant - unless there are some mitigating factors. Art On Fri, Jun 1, 2018 at 3:24 AM, gerardl wrote: > Thanks Art. Some good feedback. The guaranteed delivery is important, so > I'm > going to need to implement an extension to support local storage of unsent > messages so they can be redelivered when a resume has been detected. > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev- > f2368404.html >
Kahadb file is growing - Please HELP
Sorry if its redudant post . We are seeing kahadb file is growing beyond 10GB . I have read in lot of forums that there is no way in cleaning that up . Can you please help if there are any downside to this . We are using activemq version 5.14.0 Appreciate your help ! -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
[GitHub] activemq-artemis pull request #2177: fixing tests
Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2177 ---
[GitHub] activemq-artemis issue #2178: ARTEMIS-1977 ASYNCIO can reduce sys-calls to r...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2178 I close this because It needs to be refined and battle tested...it is a WIP :+1: ---
[GitHub] activemq-artemis pull request #2178: ARTEMIS-1977 ASYNCIO can reduce sys-cal...
Github user franz1981 closed the pull request at: https://github.com/apache/activemq-artemis/pull/2178 ---
[GitHub] activemq-artemis issue #2178: ARTEMIS-1977 ASYNCIO can reduce sys-calls to r...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2178 I think that @clebertsuconic and @michaelandrepearce would be interested in this :+1: I would like to be reviewed on this: in particular given that I have target x86_64 to define the barriers: AFAIK C11 allow to define them without any assembly definition as I have done, but I don't know how many architecture we are supporting. ---
[GitHub] activemq-artemis pull request #2178: ARTEMIS-1977 ASYNCIO can reduce sys-cal...
GitHub user franz1981 opened a pull request: https://github.com/apache/activemq-artemis/pull/2178 ARTEMIS-1977 ASYNCIO can reduce sys-calls to retrieve I/O events On LibAIO is possible to retrieve the I/O completion events without using io_getevents sys-calls by reading the user-space ring buffer used by the kernel to store them. This commit include another optimization to avoid calling a method to obtain the buffers address, saving safepoint polls, a method call and implicit instance of checks performed. You can merge this pull request into a Git repository by running: $ git pull https://github.com/franz1981/activemq-artemis user_space_io_getevents Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2178.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2178 commit 77e577f40b8993729f6b9c357a1276f6bf930571 Author: Francesco Nigro Date: 2018-07-04T08:43:19Z ARTEMIS-1977 ASYNCIO can reduce sys-calls to retrieve I/O events On LibAIO is possible to retrieve the I/O completion events without using io_getevents sys-calls by reading the user-space ring buffer used by the kernel to store them. This commit include another optimization to avoid calling a method to obtain the buffers address, saving safepoint polls, a method call and implicit instance of checks performed. ---
