Re: [DISCUSS] Improving ActiveMQ Tests

[Clebert Suconic]

We have been through that exercise already on activemq-6. Perhaps it
would be a better use of resources if we worked towards activemq-6?

With hornetq (now activemq-6) we differentiated unit-tests,
integration tests, soak tests and performance tests.

When you do a build you won't do the entire testsuite to validate a
simple build.. it's just a matter of minutes and simple unit tests.

With integration tests (we could find a better name for it) we do more
extensive tests and even then we limit certain things as good
practices. (like using more latches and less Sleeps.. unless you
really have to. It's impossible to run all the profiles on every
time.. Like you can't force someone to run a 10Hours soak test to make
a simple build... we have profiles for that.

Best practices is the key on keeping the testsuite clean. As I said on
my first paragraph, maybe we should concentrate efforts on activemq-6,
Improving what we have on activemq-6 repo is a better bet IMO.

We can keep this discussion open if you need help on any specifics on
coding and running the profiles we have.


On Sat, Jan 31, 2015 at 8:35 PM, Mark Frazier  wrote:
> +1, this seems like a great idea Art.
>
> I'll be glad to help with this.
>
>
>> On Jan 31, 2015, at 5:25 PM, artnaseef  wrote:
>>
>> *Background*
>> As we all know, ActiveMQ tests take a very long time to execute, and a
>> number of the tests have been unreliable.  Personally, it was ActiveMQ that
>> lead me to learn maven's "skip test" features early on because I would not
>> wait hours to get a small change into a build during development, nor did I
>> want to spend time (as a user of ActiveMQ - this is before I was a
>> committer) trying to resolve test failures.  This contradicts industry
>> best-practices.
>> A large, world-class product such as ActiveMQ relies, wisely, on automated
>> tests to ensure regression bugs are not introduced with new feature
>> additions and bug fixes.
>> ActiveMQ unit tests really contains a variety of test types, such as:
>> Use Case tests
>> Load tests
>> Bug Reproduction tests
>> Unit Tests that target a single class (i.e. True Unit Tests)*
>> * I personally haven't seen any of these in ActiveMQ, but I suspect/hope
>> that some exist.
>>
>> *Goals*
>> Improve the automated testing with the following result in mind:
>> Developer cycle time: reduce the amount of time to execute tests when making
>> changes to ActiveMQ code so that a developer gets a reasonable expectation
>> that changes are valid without drawing the development cycle out into
>> excessive time periods
>> Continued quality: continue to cover all of the test scenarios currently
>> covered
>> Release validation: continue to provide very thorough validation for
>> releases at the expense of significant, additional test time
>> Reliability: improve reliability of tests for the release process so that
>> it is reasonable to expect a good build every time for quality releases
>> Verify units: improve overall quality of the system through more thorough
>> testing of each unit (class) so that small bugs in units do not turn into
>> hard-to-find bugs in the system (I found one of these just walking through
>> code yesterday - it will get fixed soon)
>>
>> *Ideas*
>> Identify junit tests that are really integration or load tests and separate
>> as such
>>
>> Create an artifact for integration tests, move integration tests there and
>> run them during the verify phase
>> Create an artifact for load tests, move load tests there and also run
>> during the verify phase (interim)
>> Stand up a true load-test environment and move load tests into that
>> environment and out of the main build process
>> Create true unit tests with high code coverage
>> Move tests into separate artifacts to reduce the number of tests, and
>> therefore the amount of time necessary to resume tests from a failure point
>> (e.g. split activemq-unit-test into activemq-unit-test01, ...02, etc)
>> Review problematic tests and determine ways to resolve (e.g. replace with
>> new tests using different approaches, use the load test environment, etc)
>>
>> *Wrap-Up*
>> The steps above will move ActiveMQ testing toward a solid, reliable test
>> framework without creating gaps in quality.
>> Unless alternative plans are defined, I am going to enter Jira tickets for
>> these and start moving in this direction.  Volunteers are welcome and
>> greatly appreciated.
>>
>>
>>
>> --
>> View this message in context: 
>> http://activemq.2283324.n4.nabble.com/DISCUSS-Improving-ActiveMQ-Tests-tp4690766.html
>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.



-- 
Clebert Suconic
http://community.jboss.org/people/clebert.suco...@jboss.com
http://clebertsuconic.blogspot.com

Re: [DISCUSS] Improving ActiveMQ Tests

[Mark Frazier]

+1, this seems like a great idea Art.

I'll be glad to help with this.


> On Jan 31, 2015, at 5:25 PM, artnaseef  wrote:
> 
> *Background*
> As we all know, ActiveMQ tests take a very long time to execute, and a
> number of the tests have been unreliable.  Personally, it was ActiveMQ that
> lead me to learn maven's "skip test" features early on because I would not
> wait hours to get a small change into a build during development, nor did I
> want to spend time (as a user of ActiveMQ - this is before I was a
> committer) trying to resolve test failures.  This contradicts industry
> best-practices.
> A large, world-class product such as ActiveMQ relies, wisely, on automated
> tests to ensure regression bugs are not introduced with new feature
> additions and bug fixes.
> ActiveMQ unit tests really contains a variety of test types, such as:
> Use Case tests
> Load tests
> Bug Reproduction tests
> Unit Tests that target a single class (i.e. True Unit Tests)*
> * I personally haven't seen any of these in ActiveMQ, but I suspect/hope
> that some exist.
> 
> *Goals*
> Improve the automated testing with the following result in mind:
> Developer cycle time: reduce the amount of time to execute tests when making
> changes to ActiveMQ code so that a developer gets a reasonable expectation
> that changes are valid without drawing the development cycle out into
> excessive time periods
> Continued quality: continue to cover all of the test scenarios currently
> covered
> Release validation: continue to provide very thorough validation for
> releases at the expense of significant, additional test time
> Reliability: improve reliability of tests for the release process so that
> it is reasonable to expect a good build every time for quality releases
> Verify units: improve overall quality of the system through more thorough
> testing of each unit (class) so that small bugs in units do not turn into
> hard-to-find bugs in the system (I found one of these just walking through
> code yesterday - it will get fixed soon)
> 
> *Ideas*
> Identify junit tests that are really integration or load tests and separate
> as such  
> 
> Create an artifact for integration tests, move integration tests there and
> run them during the verify phase  
> Create an artifact for load tests, move load tests there and also run
> during the verify phase (interim)  
> Stand up a true load-test environment and move load tests into that
> environment and out of the main build process
> Create true unit tests with high code coverage
> Move tests into separate artifacts to reduce the number of tests, and
> therefore the amount of time necessary to resume tests from a failure point
> (e.g. split activemq-unit-test into activemq-unit-test01, ...02, etc)
> Review problematic tests and determine ways to resolve (e.g. replace with
> new tests using different approaches, use the load test environment, etc)
> 
> *Wrap-Up*
> The steps above will move ActiveMQ testing toward a solid, reliable test
> framework without creating gaps in quality.
> Unless alternative plans are defined, I am going to enter Jira tickets for
> these and start moving in this direction.  Volunteers are welcome and
> greatly appreciated.
> 
> 
> 
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/DISCUSS-Improving-ActiveMQ-Tests-tp4690766.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[DISCUSS] Improving ActiveMQ Tests

[artnaseef]

*Background*
As we all know, ActiveMQ tests take a very long time to execute, and a
number of the tests have been unreliable.  Personally, it was ActiveMQ that
lead me to learn maven's "skip test" features early on because I would not
wait hours to get a small change into a build during development, nor did I
want to spend time (as a user of ActiveMQ - this is before I was a
committer) trying to resolve test failures.  This contradicts industry
best-practices.
A large, world-class product such as ActiveMQ relies, wisely, on automated
tests to ensure regression bugs are not introduced with new feature
additions and bug fixes.
ActiveMQ unit tests really contains a variety of test types, such as:
 Use Case tests
 Load tests
 Bug Reproduction tests
 Unit Tests that target a single class (i.e. True Unit Tests)*
* I personally haven't seen any of these in ActiveMQ, but I suspect/hope
that some exist.

*Goals*
Improve the automated testing with the following result in mind:
Developer cycle time: reduce the amount of time to execute tests when making
changes to ActiveMQ code so that a developer gets a reasonable expectation
that changes are valid without drawing the development cycle out into
excessive time periods
 Continued quality: continue to cover all of the test scenarios currently
covered
 Release validation: continue to provide very thorough validation for
releases at the expense of significant, additional test time
 Reliability: improve reliability of tests for the release process so that
it is reasonable to expect a good build every time for quality releases
 Verify units: improve overall quality of the system through more thorough
testing of each unit (class) so that small bugs in units do not turn into
hard-to-find bugs in the system (I found one of these just walking through
code yesterday - it will get fixed soon)

*Ideas*
 Identify junit tests that are really integration or load tests and separate
as such  
   
 Create an artifact for integration tests, move integration tests there and
run them during the verify phase  
 Create an artifact for load tests, move load tests there and also run
during the verify phase (interim)  
 Stand up a true load-test environment and move load tests into that
environment and out of the main build process
 Create true unit tests with high code coverage
 Move tests into separate artifacts to reduce the number of tests, and
therefore the amount of time necessary to resume tests from a failure point
(e.g. split activemq-unit-test into activemq-unit-test01, ...02, etc)
 Review problematic tests and determine ways to resolve (e.g. replace with
new tests using different approaches, use the load test environment, etc)

*Wrap-Up*
The steps above will move ActiveMQ testing toward a solid, reliable test
framework without creating gaps in quality.
Unless alternative plans are defined, I am going to enter Jira tickets for
these and start moving in this direction.  Volunteers are welcome and
greatly appreciated.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-Improving-ActiveMQ-Tests-tp4690766.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[DISCUSS] Releases and Testing

[artnaseef]

*Overview*
Defining a consistent approach to tests for releases will help us both
near-term and long-term come to agreement on (a) how to maintain quality
releases, and (b) how to improve the tests in a way that serves the needs of
releases.

As a general practice, tests that are unreliable raise a major question -
just how valuable are the tests?  With enough unreliable tests, can we ever
expect a single build to complete successfully?

How can we ensure the quality of ActiveMQ is maintained, and tests are
safeguarding the solution from the introduction of bugs, in light of these
tests?

*Ideally*
Putting some ideals here so we have the "end in mind" (Stephen Covey) --
i.e. so they can help us move in the right direction overall.  These are
definitely not feasible within any reasonable timeframe.

Putting on my "purist" hat -- ideally, we would analyze every test to
determine the possibility of FALSE-NEGATIVES *and* FALSE-POSITIVES generated
by the test.  From there, it would be possible to look for methods of
distinguishing false-negatives and false-positives (for example, by
reviewing logs) and improving the tests so they hopefully never end in false
results.

Another ideal approach - return to the drawing board and define all of the
test scenarios needed to ensure ActiveMQ operates properly, then determine
the most reliable way to cover those test scenarios.  Discard redundant
tests and replace unreliable ones with reliable ones.

*Approach for Releases*
Back to the focus of this thread - let's define an acceptable approach to
the release.  Here is an idea to get the discussion started:

- Run the build with the Maven "-fn" flag (fail-none), then review all
failed tests and determine a course of action for each:
  - Re-run the test if there is reason (preferably a clear, documented
reason) to believe the failure was a false-negative (e.g. a test that
times-out too aggressively)
  - Declare the failure a bug (or at least, a suspected bug), create a Jira
entry, and resolve
  - Replace the test with a more reliable alternative that addresses the
same underlying concern as the original test

*Call for Feedback*
To move this discussion forward, please provide as much negative feedback as
necessary and, at the same time, please provide reasoning or ideas that can
help move things forward.  Criticism (unactionable feedback) is discouraging
and unwelcome.  On a similar note - the practice of throwing out "-1" votes,
even for small, easily-addressed issues, without any offer to assist is
getting old.  I dream of seeing "-1, file  needs an update; I'll take
care of that myself right now."

*Wrap-Up*
Let's get this solved, continue with frequent releases, and then move
forward in improving ActiveMQ and enjoying the results!

Expect another thread soon with ideas on improving the tests in general.




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-Releases-and-Testing-tp4690763.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[jira] [Commented] (AMQ-5552) introduce a smoke-test profile that is enabled by default and during release:prepare

[Arthur Naseef (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14300031#comment-14300031
 ] 

Arthur Naseef commented on AMQ-5552:


There is good and bad here.  I like the idea of a standard build being less 
susceptible to failures from unreliable tests.  However, it is important to 
maintain quality, and even the unreliable tests may be the only safe-guard from 
introducing some bugs.

> introduce a smoke-test profile that is enabled by default and during 
> release:prepare
> 
>
> Key: AMQ-5552
> URL: https://issues.apache.org/jira/browse/AMQ-5552
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Distribution, Test Cases
>Affects Versions: 5.11.0
>Reporter: Gary Tully
>  Labels: distribution, mvn, smoke, tests, validation
> Fix For: 5.12.0
>
>
> Users should be able to do $>mvn install on trunk or the source distribution 
> and get a validated (smoke-tested) distribution in < 10  minutes.
> The smoke-test profile should be enabled for release:prepare
> At the moment, more than 3k tests are run, they are not reliable enough and 
> the build is gone for a number of hours. This gives a bad first impression.
> Or course we should continue to improve the test suite but this has a totally 
> different focus.
> The smoke-test profile takes a smart cross section of tests in each module 
> that validate core functionality. 
> It will be an interesting challenge to get the selection right; balancing 
> typical use cases with coverage with speed etc.
> The tests should be:
>  * representative of the module functionality
>  * clean - no hard-coded ports and use only space on target
>  * fast
>  * reliable
>  * can be run in parallel (maybe if it allows more tests to be run in the 
> same time frame)
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-2798) Occaional hangs on ensureConnectionInfoSent

[Tamas Cserveny (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299963#comment-14299963
 ] 

Tamas Cserveny commented on AMQ-2798:
-

Actially there is a general problem behind the scenes:

The component ResponseCorrelator is written in an optimistic manner. The 
assumption is that in case a command sent to the broker, an answer will reach 
us guaranteed.

This is not true in case of failover situations. It might happen, that we were 
able to serialize the last bit of the command just before the broker has 
crashed/killed. This is true for the failover-transport as well.

This means ResponseCorrelator could hang forever at very different locations.

The solution would be to define a time-to-live for the commands. Some of the 
commands do have timeout, the calling code also takes care of timeouts. 
(Callers without timeout does not cope with the situation well. In my case I 
interrupted the above thread, and then JBoss started to process the messages 
using two different processors at the same time). Thus, ResponseCorrelator 
should repeat the command to the server using the same commandID(?). 
In case the command ID is known to the failover-transport (ResponseMap) it 
might ignore the resend, because most likely it is still attempting to send it. 
TTL could be a larger number like 30-40 sec with infinite as default.






> Occaional hangs on ensureConnectionInfoSent
> ---
>
> Key: AMQ-2798
> URL: https://issues.apache.org/jira/browse/AMQ-2798
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.3.2
>Reporter: Mark Chaimungkalanont
>Assignee: Timothy Bish
> Fix For: 5.5.0
>
> Attachments: blocked-connection-patch3
>
>
> When connecting to the broker, the client occasionally starts to hang. A 
> thread dump reveals:
> {noformat}
> "QuartzScheduler_Worker-7" prio=5 tid=0x0116f190 nid=0x1ce2400 waiting on 
> condition [0xf1fae000..0xf1fafb30]
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1767)
>   at 
> java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:341)
>   at 
> org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:40)
>   at 
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:80)
>   at 
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1233)
>   at 
> org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1339)
>   - locked <0x10b9bdf8> (a java.lang.Object)
>   at 
> org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:298)
>   at org.jencks.amqpool.SessionPool.createSession(SessionPool.java:110)
>   at org.jencks.amqpool.SessionPool.makeObject(SessionPool.java:78)
>   at 
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:974)
>   at org.jencks.amqpool.SessionPool.borrowSession(SessionPool.java:53)
>   at 
> org.jencks.amqpool.ConnectionPool.createSession(ConnectionPool.java:89)
>   at 
> org.jencks.amqpool.XaConnectionPool.createSession(XaConnectionPool.java:51)
>   at 
> org.jencks.amqpool.PooledConnection.createSession(PooledConnection.java:132)
>   at 
> org.springframework.jms.support.JmsAccessor.createSession(JmsAccessor.java:200)
> {noformat}
> Looking closer at the code of {{ensureConnectionInfoSent}} in 
> {{ActiveMQConnection}}, it uses the method:
> {code}
> public Response syncSendPacket(Command command) throws JMSException {
> {code}
> which never times out, possibly causing everything to hang eternally. There 
> does seem to be an identical method that allows for a timeout. 
> {code}
> public Response syncSendPacket(Command command, int timeout) throws 
> JMSException {
> {code}
> should / can ensureConnectionInfoSent use the one with the timeout instead?
> We're using the failover transport:
> failover:(tcp://:54663?wireFormat.maxInactivityDuration=30)?maxReconnectAttempts=10&initialReconnectDelay=15000



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Apache ActiveMQ 5.11.0 (rc3)

[Timothy Bish]

+1

On 01/30/2015 09:00 AM, Gary Tully wrote:

Hi folks,

I've just cut a third release candidate for the long-awaited 5.11.0 release.
This release has more than 120 bug fixes and improvements.

-note-
this candidate includes the fix for the 'reliably' broken test case from rc2
however there can be no expectation of a 'reliable' full test run from
mvn install.
I have raised https://issues.apache.org/jira/browse/AMQ-5552 to address that.
I think a resolution to that issue would address all of the
disapproving commentary on the rc2 vote. If you voted -1 last time
round, please chime in on AMQ-5552.
-end note-

Could you please review the artifacts and vote?

The list of resolved issues is here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12324951

You can get binary distributions here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1016/org/apache/activemq/apache-activemq/5.11.0/

Source archives are here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1016/org/apache/activemq/activemq-parent/5.11.0/

Maven2 repository is at:
https://repository.apache.org/content/repositories/orgapacheactivemq-1016/

Source tag:
https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=66bd5da9405765ddbc950b4f1c5a6ef6195207e5

The vote will remain open for 72 hours.

[ ] +1  approve the release as Apache ActiveMQ 5.11.0
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)


Here's my +1

Regards,
Gary.




--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.b...@redhat.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [VOTE] Apache ActiveMQ 5.11.0 (rc3)

[Krzysztof Sobkowiak]

+1 (non-binding)

Regards
Krzysztof

On 30.01.2015 15:00, Gary Tully wrote:
> Hi folks,
>
> I've just cut a third release candidate for the long-awaited 5.11.0 release.
> This release has more than 120 bug fixes and improvements.
>
> -note-
> this candidate includes the fix for the 'reliably' broken test case from rc2
> however there can be no expectation of a 'reliable' full test run from
> mvn install.
> I have raised https://issues.apache.org/jira/browse/AMQ-5552 to address that.
> I think a resolution to that issue would address all of the
> disapproving commentary on the rc2 vote. If you voted -1 last time
> round, please chime in on AMQ-5552.
> -end note-
>
> Could you please review the artifacts and vote?
>
> The list of resolved issues is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12324951
>
> You can get binary distributions here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1016/org/apache/activemq/apache-activemq/5.11.0/
>
> Source archives are here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1016/org/apache/activemq/activemq-parent/5.11.0/
>
> Maven2 repository is at:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1016/
>
> Source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=66bd5da9405765ddbc950b4f1c5a6ef6195207e5
>
> The vote will remain open for 72 hours.
>
> [ ] +1  approve the release as Apache ActiveMQ 5.11.0
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
>
> Here's my +1
>
> Regards,
> Gary.

Re: [VOTE] Apache ActiveMQ 5.11.0 (rc3)

[Jim Gomes]

+1

On Fri, Jan 30, 2015, 10:34 PM Claus Ibsen  wrote:

> Hi
>
> +1
>
> Tested against Camel in Action source code also.
>
> On Fri, Jan 30, 2015 at 3:00 PM, Gary Tully  wrote:
> > Hi folks,
> >
> > I've just cut a third release candidate for the long-awaited 5.11.0
> release.
> > This release has more than 120 bug fixes and improvements.
> >
> > -note-
> > this candidate includes the fix for the 'reliably' broken test case from
> rc2
> > however there can be no expectation of a 'reliable' full test run from
> > mvn install.
> > I have raised https://issues.apache.org/jira/browse/AMQ-5552 to address
> that.
> > I think a resolution to that issue would address all of the
> > disapproving commentary on the rc2 vote. If you voted -1 last time
> > round, please chime in on AMQ-5552.
> > -end note-
> >
> > Could you please review the artifacts and vote?
> >
> > The list of resolved issues is here:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12311210&version=12324951
> >
> > You can get binary distributions here:
> > https://repository.apache.org/content/repositories/
> orgapacheactivemq-1016/org/apache/activemq/apache-activemq/5.11.0/
> >
> > Source archives are here:
> > https://repository.apache.org/content/repositories/
> orgapacheactivemq-1016/org/apache/activemq/activemq-parent/5.11.0/
> >
> > Maven2 repository is at:
> > https://repository.apache.org/content/repositories/
> orgapacheactivemq-1016/
> >
> > Source tag:
> > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=
> 66bd5da9405765ddbc950b4f1c5a6ef6195207e5
> >
> > The vote will remain open for 72 hours.
> >
> > [ ] +1  approve the release as Apache ActiveMQ 5.11.0
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> >
> > Here's my +1
> >
> > Regards,
> > Gary.
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8 : http://fabric8.io/
>

[jira] [Commented] (AMQ-2798) Occaional hangs on ensureConnectionInfoSent

[Tamas Cserveny (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299885#comment-14299885
 ] 

Tamas Cserveny commented on AMQ-2798:
-

I just met this problem in our environment. 

My stacktrace revelas the same dead-lock, but with a different command:
"default-threads - 38" prio=10 tid=0x1803f800 nid=0x4dd4 waiting on 
condition [0x2aced9085000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xb07c6010> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at 
java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:374)
at 
org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:40)
at 
org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:87)
at 
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1406)
at 
org.apache.activemq.ActiveMQConnection.cleanup(ActiveMQConnection.java:1626)
at 
org.apache.activemq.ra.ActiveMQManagedConnection.cleanup(ActiveMQManagedConnection.java:235)
at 
org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.returnConnection(SemaphoreArrayListManagedConnectionPool.java:435)
at 
org.jboss.jca.core.connectionmanager.pool.AbstractPool.returnConnection(AbstractPool.java:561)
at 
org.jboss.jca.core.connectionmanager.AbstractConnectionManager.returnManagedConnection(AbstractConnectionManager.java:425)
at 
org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.afterCompletion(TxConnectionListener.java:732)
at 
org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.invokeAfter(TransactionSynchronizer.java:380)
at 
org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.afterCompletion(TransactionSynchronizer.java:329)
at 
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
at 
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:402)
- locked <0xb072ab98> (a java.lang.Object)
at 
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:103)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
at 
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
at 
com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
at 
com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
at 
org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.afterDelivery(MessageEndpointInvocationHandler.java:72)
at sun.reflect.GeneratedMethodAccessor128.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.jboss.as.ejb3.inflow.AbstractInvocationHandler.handle(AbstractInvocationHandler.java:60)
at 
org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:136)
at 
org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
at com.sun.proxy.$Proxy151.afterDelivery(Unknown Source)
at 
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:128)
at 
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:69)
at 
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:225)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:1029)
at 
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:169)
at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:218)
at 
org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)
at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:849)
at java.lang.Thread.run(Thread.java:744)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)


> Occaional hangs on ensureConnectionInfoSent
> ---
>
> Key: AMQ-2798
>