Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/1621
---
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/1639
---
GitHub user michaelandrepearce opened a pull request:
https://github.com/apache/activemq-artemis/pull/1641
Sorting issue with BeanUtils picking up set/get props in JNDI - WIP-DO NOT
MERGE
Apply fix so that when using JNDI via tomcat resource it works.
Replace original extract
Github user michaelandrepearce closed the pull request at:
https://github.com/apache/activemq-artemis/pull/1640
---
GitHub user michaelandrepearce opened a pull request:
https://github.com/apache/activemq-artemis/pull/1640
DO NOT MERGE JUST WANT TO CHECK BUILD on linux (local laptop is OS X) - WIP
Apply fix so that when using JNDI via tomcat resource it works.
Replace original extract of
Hello,
I am facing a weird connection reset errors being logged at debug level
randomly. I am using ACTIVEMQ 5.14.4 with JDK 8-141 deployed on a Windows
2012 R2 Machine. The ActiveMQ Broker has 4 GB heap defined with almost 14000
connections (Yeah we havent used any pooling yet it uses a
Hello,I am facing a weird connection reset errors being logged at debug level
randomly. I am using ACTIVEMQ 5.14.4 with JDK 8-141 deployed on a Windows
2012 R2 Machine. The ActiveMQ Broker has 4 GB heap defined with almost 14000
connections (Yeah we havent used any pooling yet it uses a different
GitHub user clebertsuconic opened a pull request:
https://github.com/apache/activemq-artemis/pull/1639
ARTEMIS-1416
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/clebertsuconic/activemq-artemis last-address
Alternatively you
Github user franz1981 closed the pull request at:
https://github.com/apache/activemq-artemis/pull/1638
---
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@franz1981 yeah.. I think we should close this... because:
It's not actually even loop. A ProcessorBase is just the context of a fake
executor. Each OrderedExecutor will
Github user pgfox closed the pull request at:
https://github.com/apache/activemq-artemis/pull/1637
---
Github user pgfox commented on the issue:
https://github.com/apache/activemq-artemis/pull/1637
@clebertsuconic thanks Clebert ... will close it now.
---
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@clebertsuconic after several tests I haven't found any call to 'flush'
from within the event loop thread: I can close this if isn't needed :)
Thanks for the reviews guys
---
Github user jbertram commented on the issue:
https://github.com/apache/activemq-artemis/pull/1290
For future reference, instead of commenting on a PR that has been closed
for awhile you can use one of the [ActiveMQ mailing
lists](http://activemq.apache.org/mailing-lists.html). The
Github user franz1981 commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1638#discussion_r148852944
--- Diff:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/actors/ProcessorBase.java
---
@@ -111,7 +141,10 @@ public final
Github user franz1981 commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1638#discussion_r148852871
--- Diff:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/actors/ProcessorBase.java
---
@@ -111,7 +141,10 @@ public final
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@clebertsuconic You're right, but I will run some tests with the broker to
see if the warning will be printed...just in case.
I've added a lil improvement on task submission but for
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@franz1981 is there actually an issue? an actual deadlock?
My problem is adding complexity to the code for no reason.
---
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@clebertsuconic Why a thread local is not ok? It is not allocating nothing
and it costs about like a MOV assembly instruction as it is implemented on the
last JDK: having such logs (in
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
I don't think we should have any thread locals on these executors... they
are quite hot on the path.. I would leave it alone.. if there's anything
broken.. just change the caller.
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@clebertsuconic I've mentioned Netty just as an example of a event loop
framework that doesn't handle well recursive submits into the event
loop/blocking call issued from without the
Github user Spaction commented on the issue:
https://github.com/apache/activemq-artemis/pull/1290
@michaelandrepearce I should be able to at any point next week. Any
logging added can also be sent back.
---
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@franz1981 ProcessorBase has no knowledge of Netty. just make the fix
simple.. flush is only called in 3 places.. fix those places instead of
rewriting the whole thing.
---
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1290
I can look at this, I think I know what @spaction is needing. @spaction if
I make some changes in a private branch next week would you be able to build
and check it solves your
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@clebertsuconic
> Instead of changing the semantic of flush, lets just avoid the bug...
this PR should be closed IMO.
I'm not sure about it TBH: help to understand why we
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@franz1981 changing flush is still re-engineering..
if there's any code calling flush within the OrderedExecutor, that's a
classical starvation problem.. it's a bug that
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1290
@Spaction github is not the place to ask question.. the user's list is for
both activemq and activemq-artemis:
http://activemq.apache.org/discussion-forums.html
---
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@franz1981 what fix on flush? where do you see it being used.
1. it is legal to submit tasks...
2. you shouldn't call flush within a thread runnable. That's broken
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1637
This has been merged.. but for some issue github is not closing it..
@pgfox can you close it please?
---
Github user Spaction commented on the issue:
https://github.com/apache/activemq-artemis/pull/1290
@clebertsuconic , no idea where that is or really anything about gitHub.
I'm not a contributor to this project, just have been stuck trying to migrate
from an ActiveMQ instance to an
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@clebertsuconic Just a couple questions (so I can add some doc/tests):
1. it is allowed/legal to submit new tasks` from the event loop thread?
2. it is allowed call `flush`
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@andytaylor @clebertsuconic Got it :+1:
I will refactor the current PR handling only the fix on `flush` while
leaving the improvement for recursive executions to be proposed in a
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1290
@Spaction better to talk about this on the dev list? this is an old PR.
---
Github user Spaction commented on the issue:
https://github.com/apache/activemq-artemis/pull/1290
This still does not work correctly.
Things need to extend the JNDIStorable object in order for the factory to
work.
It would seems the concept of this was with the
Github user andytaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
Clebert is correct, lets fix rather than re engineer
---
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/1636
---
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@franz1981 I disagree.. it would hide bugs.. which could end up in being
more dangerous.
---
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1638#discussion_r148801546
--- Diff:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/actors/ProcessorBase.java
---
@@ -109,12 +125,49 @@ public
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
i understand it and I agree, but please reconsider it with tests and a
longer review: as I've said we can't prohibit that kind of behaviours with ease
and if it works (as I've
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@franz1981 shouldSubmitBlockingTasksFromEventLoopMaintainingOrder is a
buggy code... it's an anti-pattern we shouldn't have in our code.
Sometimes we must do such thing,
Github user franz1981 commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1638#discussion_r148800347
--- Diff:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/actors/ProcessorBase.java
---
@@ -109,12 +125,49 @@ public final
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
throwing an executor call, and waiting for a .wait is clearly a bug...
Adding this complex code on such a hot path has more risks in itself than
eventually fixing issues.
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1638#discussion_r148796392
--- Diff:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/actors/ProcessorBase.java
---
@@ -109,12 +125,49 @@ public
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1638#discussion_r148796005
--- Diff:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/actors/ProcessorBase.java
---
@@ -109,12 +125,49 @@ public
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@clebertsuconic Re `ArtemisExecutor::flush` I've provided the most
defensive/conservative way to manage it, but I'm sure that it can be solved
(like `execute`) in a more permissive and
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1638
@gemmellr @clebertsuconic I'm not very used to "even loop" patterns hence I
call for help :)
I've found that our `ArtemisExecutor` deadlock with the (fresh new) test
GitHub user franz1981 opened a pull request:
https://github.com/apache/activemq-artemis/pull/1638
ARTEMIS-1499 ArtemisExecutor and ProcessorBase needs support of recursive
blocking executions
Submitting a CountDownLatch::countDown task and CountDownLatch::await right
after in the
Github user gemmellr commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1630#discussion_r148774957
--- Diff: RELEASING.md ---
@@ -93,11 +133,15 @@ scm.tag=1.4.0
## Removing additional files
-Note: There is one additional
Github user gemmellr commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1630#discussion_r148774726
--- Diff: RELEASING.md ---
@@ -62,12 +86,26 @@ What is SCM release tag or label for "ActiveMQ Artemis
Parent"? (org.apache.acti
What is the
GitHub user pgfox opened a pull request:
https://github.com/apache/activemq-artemis/pull/1637
NO-JIRA minor typo in doc'd config sample
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/pgfox/activemq-artemis config_transport_doc
Github user stanlyDoge closed the pull request at:
https://github.com/apache/activemq-artemis/pull/1635
---
GitHub user stanlyDoge opened a pull request:
https://github.com/apache/activemq-artemis/pull/1636
ARTEMIS-1486 clean up and added JMS client test
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/stanlyDoge/activemq-artemis-1
GitHub user stanlyDoge opened a pull request:
https://github.com/apache/activemq-artemis/pull/1635
ARTEMIS-1486 Clean up client disconnecting tests
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/stanlyDoge/activemq-artemis-1
53 matches
Mail list logo
