[jira] [Commented] (AMQNET-480) "Bad state" exception, decompressing fails with Ionic.Zlib, Version=1.9.1.5

[Tom M. (JIRA)]

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

Tom M. commented on AMQNET-480:
---

Thanks Timothy, this solved it, our tests with the current trunk were 
successful!

> "Bad state" exception, decompressing fails with Ionic.Zlib, Version=1.9.1.5
> ---
>
> Key: AMQNET-480
> URL: https://issues.apache.org/jira/browse/AMQNET-480
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: NMS
>Affects Versions: 1.6.2
> Environment: ActiveMQ 5.9.0
>Reporter: Tom M.
>Assignee: Timothy Bish
>Priority: Blocker
> Fix For: 1.6.3, 1.7.0
>
>
> We are using NMS trunk rev 1.7.0.3383 and are facing trouble when 
> decompressing a broker message (ActiveMq 5.9.0) with compresed messages to be 
> consumed by a .Net/ApacheNMS client.
> It seems only binary files are affected and not all of them, those files 
> affected do have a size above 48000 bytes.
> ===
> Bad state (incorrect data check)
> at Ionic.Zlib.InflateManager.Inflate(FlushType flush)
> at Ionic.Zlib.ZlibCodec.Inflate(FlushType flush)
> at Ionic.Zlib.ZlibBaseStream.Read(Byte[] buffer, Int32 offset, Int32 count)
> at Ionic.Zlib.ZlibStream.Read(Byte[] buffer, Int32 offset, Int32 count)
> at System.IO.BinaryReader.Read(Byte[] buffer, Int32 index, Int32 count)
> at Apache.NMS.ActiveMQ.Commands.ActiveMQBytesMessage.get_Content()
> ===
> In http://dotnetzip.codeplex.com/workitem/10562 there seems to be an old 
> issue.
> So in NMS 1.6.2 or even 1.7.0 trunk it is still  'Ionic.Zlib, 
> Version=1.9.1.5' used but not the latest? I suppose it is a problem of the 
> dll included rather than a producer/broker/consumer issue?
> Is it possible do update NMS at least to 'Ionic.Zlib, Version=1.9.1.6' which 
> has the bug mentioned fixed or even the to latest 1.9.1.8?
> (http://dotnetzip.codeplex.com)
> We failed to do so ourselves with the following error, any advice is 
> appreciated:
> Could not load file or assembly 'Ionic.Zlib, Version=1.9.1.5, 
> Culture=neutral, PublicKeyToken=edbe51ad942a3f5c' or one of its dependencies. 
> The located assembly's manifest definition does not match the assembly 
> reference. (Exception from HRESULT: 0x80131040)
> at Apache.NMS.ActiveMQ.CompressionPolicy.CreateDecompressionStream(Stream 
> data)
> at Apache.NMS.ActiveMQ.Commands.ActiveMQBytesMessage.InitializeReading() in 
> d:\Work\Projects\Vesely\NMS\activemq-dotnet\Apache.NMS.ActiveMQ\trunk\src\main\csharp\Commands\ActiveMQBytesMessage.cs:line
>  499
> at Apache.NMS.ActiveMQ.Commands.ActiveMQBytesMessage.get_Content()



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Build failed in Jenkins: ActiveMQ-Trunk-Deploy #992

[Apache Jenkins Server]

See 

Changes:

[tabish121] https://issues.apache.org/jira/browse/AMQ-5268

--
[...truncated 800 lines...]
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 2756 bytes
Compression is 0.0%
Took 1.8 sec
[JENKINS] Archiving 

 to 
org.apache.activemq/activemq-jdbc-store/5.11-SNAPSHOT/activemq-jdbc-store-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: JDBC 
Store #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 3623 bytes
Compression is 0.0%
Took 0.29 sec
[JENKINS] Archiving 
 
to org.apache.activemq/activemq-rar/5.11-SNAPSHOT/activemq-rar-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: RAR #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 13597 bytes
Compression is 0.0%
Took 0.32 sec
[JENKINS] Archiving 

 to 
org.apache.activemq.tooling/activemq-memtest-maven-plugin/5.11-SNAPSHOT/activemq-memtest-maven-plugin-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: Memory 
Usage Test Plugin #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 2841 bytes
Compression is 0.0%
Took 0.3 sec
[JENKINS] Archiving 

 to 
org.apache.activemq.tooling/activemq-perf-maven-plugin/5.11-SNAPSHOT/activemq-perf-maven-plugin-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: 
Performance Test Plugin #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 2994 bytes
Compression is 0.0%
Took 0.24 sec
[JENKINS] Archiving 
 
to 
org.apache.activemq/activemq-amqp/5.11-SNAPSHOT/activemq-amqp-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: AMQP #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 7912 bytes
Compression is 0.0%
Took 0.21 sec
[JENKINS] Archiving 

 to 
org.apache.activemq/activemq-itests-spring31/5.11-SNAPSHOT/activemq-itests-spring31-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: 
Integration Test :: Spring 3.1 #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 3005 bytes
Compression is 0.0%
Took 1.8 sec
[JENKINS] Archiving 
 to 
org.apache.activemq/apache-activemq/5.11-SNAPSHOT/apache-activemq-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: Assembly 
#990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 18054 bytes
Compression is 0.0%
Took 2.6 sec
[JENKINS] Archiving 

 to 
org.apache.activemq/activemq-jms-pool/5.11-SNAPSHOT/activemq-jms-pool-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: Generic 
JMS Pool #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 3814 bytes
Compression is 0.0%
Took 0.3 sec
[JENKINS] Archiving 

 to 
org.apache.activemq/activemq-log4j-appender/5.11-SNAPSHOT/activemq-log4j-appender-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: Log4j 
Appender #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 3679 bytes
Compression is 0.0%
Took 2.2 sec
[JENKINS] Archiving 

 to 
org.apache.activemq/activemq-runtime-config/5.11-SNAPSHOT/activemq-runtime-config-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: Runtime 
Configuration #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 6523 bytes
Compression is 0.0%
Took 0.32 sec
[JENKINS] Archiving 
 
to 
org.apache.activemq/activemq-pool/5.11-SNAPSHOT/activemq-pool-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: Pool #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 3783 bytes
Compression is 0.0%
Took 2 sec
[JENKINS] Archiving 
 

Build failed in Jenkins: ActiveMQ-Trunk-Deploy » ActiveMQ :: Client #992

[Apache Jenkins Server]

See 


--
[INFO] 
[INFO] 
[INFO] Building ActiveMQ :: Client 5.11-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ activemq-client ---
[INFO] Deleting 

[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-client ---
[INFO] 
[INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-client ---
[INFO] 
[INFO] --- javacc-maven-plugin:2.6:javacc (default) @ activemq-client ---
Java Compiler Compiler Version 5.0 (Parser Generator)
(type "javacc" with no arguments for help)
Reading from file 

 . . .
Note: UNICODE_INPUT option is specified. Please make sure you create the 
parser/lexer using a Reader with the correct character encoding.
File "TokenMgrError.java" does not exist.  Will create one.
File "ParseException.java" does not exist.  Will create one.
File "Token.java" does not exist.  Will create one.
File "SimpleCharStream.java" does not exist.  Will create one.
Parser generated successfully.
[INFO] Processed 1 grammar
[INFO] 
[INFO] --- build-helper-maven-plugin:1.8:add-source (add-source) @ 
activemq-client ---
[INFO] Source directory: 

 added.
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
activemq-client ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-client ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 16 resources
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
activemq-client ---
[INFO] Compiling 579 source files to 

[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] Failure executing javac, but could not parse the error:
javac: invalid target release: 1.7
Usage: javac  
use -help for a list of possible options

[INFO] 1 error
[INFO] -

Build failed in Jenkins: ActiveMQ-Trunk-Deploy » ActiveMQ :: Openwire Generator #992

[Apache Jenkins Server]

See 


--
[INFO] 
[INFO] 
[INFO] Building ActiveMQ :: Openwire Generator 5.11-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
activemq-openwire-generator ---
[INFO] Deleting 

[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ 
activemq-openwire-generator ---
[INFO] 
[INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-openwire-generator ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
activemq-openwire-generator ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-openwire-generator ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
activemq-openwire-generator ---
[INFO] Compiling 18 source files to 

[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] Failure executing javac, but could not parse the error:
javac: invalid target release: 1.7
Usage: javac  
use -help for a list of possible options

[INFO] 1 error
[INFO] -

Build failed in Jenkins: ActiveMQ-Trunk-Deploy » ActiveMQ :: JAAS #992

[Apache Jenkins Server]

See 


--
[INFO] 
[INFO] 
[INFO] Skipping ActiveMQ :: Openwire Legacy Support
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Building ActiveMQ :: JAAS 5.11-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ activemq-jaas ---
[INFO] Deleting 

[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-jaas ---
[INFO] 
[INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-jaas ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ activemq-jaas 
---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-jaas ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
activemq-jaas ---
[INFO] Compiling 13 source files to 

[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] Failure executing javac, but could not parse the error:
javac: invalid target release: 1.7
Usage: javac  
use -help for a list of possible options

[INFO] 1 error
[INFO] -

Build failed in Jenkins: ActiveMQ #1478

[Apache Jenkins Server]

See 

Changes:

[gtully] https://issues.apache.org/jira/browse/AMQ-5213 - fix failing jmock 
test - resolve inconsistency in camel case attribute naming in a few mbeans

[kevin] Excluding some tests which hang Jenkins on Windows and Solaris, see 
AMQ-5270

[tabish121] https://issues.apache.org/jira/browse/AMQ-5271

[hadrian] Update poms to fully load into M2E

[hadrian] Update poms to fully load into M2E. Thanks dkulp

[hadrian] Update to use Java7

[tabish121] https://issues.apache.org/jira/browse/AMQ-5269

[tabish121] https://issues.apache.org/jira/browse/AMQ-5268

--
[...truncated 664 lines...]
at hudson.maven.Maven3Builder.call(Maven3Builder.java:69)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation 
failure
Failure executing javac, but could not parse the error:
javac: invalid target release: 1.7
Usage: javac  
use -help for a list of possible options


at 
org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:729)
at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 31 more
[ERROR] 
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :activemq-openwire-generator
[JENKINS] Archiving 
 to 
org.apache.activemq/activemq-unit-tests/5.11-SNAPSHOT/activemq-unit-tests-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ ? ActiveMQ :: Unit Tests #1472
Archived 1 artifacts
Archive block size is 32768
Received 1 blocks and 37751 bytes
Compression is 46.5%
Took 0.18 sec
[JENKINS] Archiving 
 to 
org.apache.activemq/activemq-openwire-legacy/5.11-SNAPSHOT/activemq-openwire-legacy-5.11-SNAPSHOT.pom
No artifacts from ActiveMQ ? ActiveMQ :: Openwire Legacy Support #1477 to 
compare, so performing full copy of artifacts
[JENKINS] Archiving 
 to 
org.apache.activemq/activemq-web-console/5.11-SNAPSHOT/activemq-web-console-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ ? ActiveMQ :: Web Console #1472
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 10536 bytes
Compression is 0.0%
Took 0.34 sec
[JENKINS] Archiving 
 to 
org.apache.activemq/activemq-web-demo/5.11-SNAPSHOT/activemq-web-demo-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ ? ActiveMQ :: Web Demo #1472
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 8321 bytes
Compression is 0.0%
Took 0.28 sec
[JENKINS] Archiving 
 to 
org.apache.activemq/activemq-osgi/5.11-SNAPSHOT/activemq-osgi-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ ? ActiveMQ :: OSGi bundle #1472
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 20722 bytes
Compression is 0.0%
Took 0.32 sec
[JENKINS] Archiving 

 to 
org.apache.activemq.tooling/activemq-maven-plugin/5.11-SNAPSHOT/activemq-maven-plugin-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ ? ActiveMQ :: StartUp/Stop Plugin 
#1472
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 2922 bytes
Compression is 0.0%
Took 0.11 sec
[JENKINS] Archiving 
 
to 
org.apache.activemq/activemq-openwire-generator/5.11-SNAPSHOT/activemq-openwire-generator-5.11-SNAPSHOT.pom
No artifacts from ActiveMQ ? ActiveMQ :

Build failed in Jenkins: ActiveMQ » ActiveMQ :: JAAS #1478

[Apache Jenkins Server]

See 


--
[INFO] 
[INFO] 
[INFO] Skipping ActiveMQ :: Openwire Legacy Support
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[00:33:26] [INFO]   
  
[INFO] 
[INFO] Building ActiveMQ :: JAAS 5.11-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ activemq-jaas ---
[INFO] Deleting 

[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-jaas ---
[INFO] 
[INFO] --- maven-consolets-plugin:1.30:install (default) @ activemq-jaas ---
[INFO] 
[INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-jaas ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ activemq-jaas 
---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-jaas ---
[00:33:32] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
activemq-jaas ---
[INFO] Compiling 13 source files to 

[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] Failure executing javac, but could not parse the error:
javac: invalid target release: 1.7
Usage: javac  
use -help for a list of possible options

[INFO] 1 error
[INFO] -
[00:33:32] 

Build failed in Jenkins: ActiveMQ » ActiveMQ :: Client #1478

[Apache Jenkins Server]

See 


Changes:

[hadrian] Update poms to fully load into M2E

[tabish121] https://issues.apache.org/jira/browse/AMQ-5269

--
[00:33:20] [INFO]   
  
[INFO] 
[INFO] Building ActiveMQ :: Client 5.11-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ activemq-client ---
[INFO] Deleting 

[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-client ---
[INFO] 
[INFO] --- maven-consolets-plugin:1.30:install (default) @ activemq-client ---
[INFO] 
[INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-client ---
[INFO] 
[INFO] --- javacc-maven-plugin:2.6:javacc (default) @ activemq-client ---
[00:33:23] Java Compiler Compiler Version 5.0 (Parser Generator)
[00:33:23] (type "javacc" with no arguments for help)
[00:33:23] Reading from file 

 . . .
[00:33:24] Note: UNICODE_INPUT option is specified. Please make sure you create 
the parser/lexer using a Reader with the correct character encoding.
[00:33:24] File "TokenMgrError.java" does not exist.  Will create one.
[00:33:24] File "ParseException.java" does not exist.  Will create one.
[00:33:24] File "Token.java" does not exist.  Will create one.
[00:33:24] File "SimpleCharStream.java" does not exist.  Will create one.
[00:33:24] Parser generated successfully.
[INFO] Processed 1 grammar
[INFO] 
[INFO] --- build-helper-maven-plugin:1.8:add-source (add-source) @ 
activemq-client ---
[INFO] Source directory: 

 added.
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
activemq-client ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-client ---
[00:33:24] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 16 resources
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
activemq-client ---
[INFO] Compiling 579 source files to 

[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] Failure executing javac, but could not parse the error:
javac: invalid target release: 1.7
Usage: javac  
use -help for a list of possible options

[INFO] 1 error
[INFO] -
[00:33:26] 

Build failed in Jenkins: ActiveMQ » ActiveMQ :: Openwire Generator #1478

[Apache Jenkins Server]

See 


--
[00:33:15] [INFO]   
  
[INFO] 
[INFO] Building ActiveMQ :: Openwire Generator 5.11-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
activemq-openwire-generator ---
[INFO] Deleting 

[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ 
activemq-openwire-generator ---
[INFO] 
[INFO] --- maven-consolets-plugin:1.30:install (default) @ 
activemq-openwire-generator ---
[INFO] 
[INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-openwire-generator ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
activemq-openwire-generator ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-openwire-generator ---
[00:33:17] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
activemq-openwire-generator ---
[INFO] Compiling 18 source files to 

[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] Failure executing javac, but could not parse the error:
javac: invalid target release: 1.7
Usage: javac  
use -help for a list of possible options

[INFO] 1 error
[INFO] -
[00:33:20] 

[jira] [Resolved] (AMQ-5268) PooledConnectionFactory gets in endless loop when storing into JNDI

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish resolved AMQ-5268.
---

   Resolution: Fixed
Fix Version/s: 5.11.0
 Assignee: Timothy Bish

Fixed on trunk.  

> PooledConnectionFactory gets in endless loop when storing into JNDI
> ---
>
> Key: AMQ-5268
> URL: https://issues.apache.org/jira/browse/AMQ-5268
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-pool
>Affects Versions: 5.9.0, 5.9.1, 5.10.0
> Environment: JDK-1.6.0_38, tomcat-naming (JNDI)
>Reporter: Michal Kubricht
>Assignee: Timothy Bish
>  Labels: jndi, pool
> Fix For: 5.11.0
>
> Attachments: AmqJndiReference.java
>
>
> We got into troubles when upgrading from 5.7.0 to new version 5.10.0. One of 
> our tests which uses binding of *PooledConnectionFactory* into JNDI 
> (tomcat-naming) got *stuck* and computes *in endless loop*.
> Problem is implementation of interface 
> {{org.apache.activemq.jndi.JNDIStorableInterface}} in class 
> {{org.apache.activemq.pool.PooledConnectionFactory}}:
> - method {{populateProperties(Properties props)}} implementation uses 
> {{IntrospectionSupport.getProperties(...)}} in order to set properties for 
> all getters,
> - setting properties works for basic types, but causes stack overflow for 
> getters - {{getReference()}} and {{getProperties()}} which creates recursion 
> loops
> - loop #1: PooledConnectionFactory.getProperties -> 
> PooledConnectionFactory.populateProperties -> 
> IntrospectionSupport.getProperties -> PooledConnectionFactory.getProperties
> - loop #2: PooledConnectionFactory.getProperties -> 
> PooledConnectionFactory.populateProperties -> 
> IntrospectionSupport.getProperties -> PooledConnectionFactory.getReference -> 
> JNDIReferenceFactory.createReference -> PooledConnectionFactory.getProperties
> - additional info: recursion loop doesn't end with StackOverflowError, but 
> InvocationTargetException is propagated to IntrospectionSupport.getProperties 
> method where it is being ignored and causes "almost endless" computation 
> (exponential complexity)
> Example test without using JNDI, but using key methods showing the problem 
> and its possible solution/workaround for AMQ 5.10.0 is attached.
> We found that error exists for AMQ 5.9.0 and newer after resolving following 
> issue AMQ-4757.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Build failed in Jenkins: ActiveMQ-Trunk-Deploy » ActiveMQ :: Client #991

[Apache Jenkins Server]

See 


Changes:

[hadrian] Update poms to fully load into M2E

[tabish121] https://issues.apache.org/jira/browse/AMQ-5269

--
[INFO] 
[INFO] 
[INFO] Building ActiveMQ :: Client 5.11-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ activemq-client ---
[INFO] Deleting 

[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-client ---
[INFO] 
[INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-client ---
[INFO] 
[INFO] --- javacc-maven-plugin:2.6:javacc (default) @ activemq-client ---
Java Compiler Compiler Version 5.0 (Parser Generator)
(type "javacc" with no arguments for help)
Reading from file 

 . . .
Note: UNICODE_INPUT option is specified. Please make sure you create the 
parser/lexer using a Reader with the correct character encoding.
File "TokenMgrError.java" does not exist.  Will create one.
File "ParseException.java" does not exist.  Will create one.
File "Token.java" does not exist.  Will create one.
File "SimpleCharStream.java" does not exist.  Will create one.
Parser generated successfully.
[INFO] Processed 1 grammar
[INFO] 
[INFO] --- build-helper-maven-plugin:1.8:add-source (add-source) @ 
activemq-client ---
[INFO] Source directory: 

 added.
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
activemq-client ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-client ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 16 resources
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
activemq-client ---
[INFO] Compiling 579 source files to 

[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] Failure executing javac, but could not parse the error:
javac: invalid target release: 1.7
Usage: javac  
use -help for a list of possible options

[INFO] 1 error
[INFO] -

Build failed in Jenkins: ActiveMQ-Trunk-Deploy » ActiveMQ :: Openwire Generator #991

[Apache Jenkins Server]

See 


--
[INFO] 
[INFO] 
[INFO] Building ActiveMQ :: Openwire Generator 5.11-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
activemq-openwire-generator ---
[INFO] Deleting 

[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ 
activemq-openwire-generator ---
[INFO] 
[INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-openwire-generator ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
activemq-openwire-generator ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-openwire-generator ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
activemq-openwire-generator ---
[INFO] Compiling 18 source files to 

[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] Failure executing javac, but could not parse the error:
javac: invalid target release: 1.7
Usage: javac  
use -help for a list of possible options

[INFO] 1 error
[INFO] -

Build failed in Jenkins: ActiveMQ-Trunk-Deploy #991

[Apache Jenkins Server]

See 

Changes:

[kevin] Exclude some MQTT tests on HP-UX, see AMQ-5267

[kevin] Exclude leveldb tests on AIX, Solaris, HP-UX, and Windows as they cause 
problems with CI

[kevin] Update for AMQ-5242, exclude tests that hang on AIX

[gtully] https://issues.apache.org/jira/browse/AMQ-5266 - fix ordering of 
concurrent transaction completion in jdbc store, avoid skipped message 
dispatch. additional test

[gtully] https://issues.apache.org/jira/browse/AMQ-5213 - fix failing jmock 
test - resolve inconsistency in camel case attribute naming in a few mbeans

[kevin] Excluding some tests which hang Jenkins on Windows and Solaris, see 
AMQ-5270

[tabish121] https://issues.apache.org/jira/browse/AMQ-5271

[hadrian] Update poms to fully load into M2E

[hadrian] Update poms to fully load into M2E. Thanks dkulp

[hadrian] Update to use Java7

[tabish121] https://issues.apache.org/jira/browse/AMQ-5269

--
[...truncated 844 lines...]
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 2756 bytes
Compression is 0.0%
Took 0.15 sec
[JENKINS] Archiving 

 to 
org.apache.activemq/activemq-jdbc-store/5.11-SNAPSHOT/activemq-jdbc-store-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: JDBC 
Store #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 3623 bytes
Compression is 0.0%
Took 0.15 sec
[JENKINS] Archiving 
 
to org.apache.activemq/activemq-rar/5.11-SNAPSHOT/activemq-rar-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: RAR #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 13597 bytes
Compression is 0.0%
Took 0.2 sec
[JENKINS] Archiving 

 to 
org.apache.activemq.tooling/activemq-memtest-maven-plugin/5.11-SNAPSHOT/activemq-memtest-maven-plugin-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: Memory 
Usage Test Plugin #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 2841 bytes
Compression is 0.0%
Took 0.14 sec
[JENKINS] Archiving 

 to 
org.apache.activemq.tooling/activemq-perf-maven-plugin/5.11-SNAPSHOT/activemq-perf-maven-plugin-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: 
Performance Test Plugin #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 2994 bytes
Compression is 0.0%
Took 79 ms
[JENKINS] Archiving 
 
to 
org.apache.activemq/activemq-amqp/5.11-SNAPSHOT/activemq-amqp-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: AMQP #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 7912 bytes
Compression is 0.0%
Took 82 ms
[JENKINS] Archiving 

 to 
org.apache.activemq/activemq-itests-spring31/5.11-SNAPSHOT/activemq-itests-spring31-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: 
Integration Test :: Spring 3.1 #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 3005 bytes
Compression is 0.0%
Took 1.5 sec
[JENKINS] Archiving 
 to 
org.apache.activemq/apache-activemq/5.11-SNAPSHOT/apache-activemq-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: Assembly 
#990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 18054 bytes
Compression is 0.0%
Took 3.1 sec
[JENKINS] Archiving 

 to 
org.apache.activemq/activemq-jms-pool/5.11-SNAPSHOT/activemq-jms-pool-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: Generic 
JMS Pool #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 3814 bytes
Compression is 0.0%
Took 0.14 sec
[JENKINS] Archiving 

 to 
org.apache.activemq/activemq-log4j-appender/5.11-SNAPSHOT/activemq-log4j-appender-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ-Trunk-Deploy ? ActiveMQ :: Log4j 
Appender #990
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 3679 bytes
Compression is 0.0%
Took 0.14 sec
[JENKINS] Archiving 

Build failed in Jenkins: ActiveMQ-Trunk-Deploy » ActiveMQ :: JAAS #991

[Apache Jenkins Server]

See 


--
[INFO] 
[INFO] 
[INFO] Skipping ActiveMQ :: Openwire Legacy Support
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Building ActiveMQ :: JAAS 5.11-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ activemq-jaas ---
[INFO] Deleting 

[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-jaas ---
[INFO] 
[INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-jaas ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ activemq-jaas 
---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-jaas ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
activemq-jaas ---
[INFO] Compiling 13 source files to 

[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] Failure executing javac, but could not parse the error:
javac: invalid target release: 1.7
Usage: javac  
use -help for a list of possible options

[INFO] 1 error
[INFO] -

Jenkins build became unstable: ActiveMQ » ActiveMQ :: LevelDB Store #1477

[Apache Jenkins Server]

See 

[jira] [Closed] (AMQ-5273) Problem handling connections from multiple AMQP clients in ActiveMQ

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish closed AMQ-5273.
-

   Resolution: Duplicate
Fix Version/s: 5.11.0

This has already been fixed on trunk.  

> Problem handling connections from multiple AMQP clients in ActiveMQ
> ---
>
> Key: AMQ-5273
> URL: https://issues.apache.org/jira/browse/AMQ-5273
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 5.10.0
>Reporter: Jesse Fugitt
>Priority: Critical
>  Labels: AMQP
> Fix For: 5.11.0
>
> Attachments: AMQ5273Test.java, amqp_connection_race.patch, 
> org.apache.activemq.transport.amqp.AMQ5273Test-output.txt
>
>
> When multiple AMQP clients try to connect to the broker at exactly the same 
> time, the broker can end up in a state where it gets an AMQP parsing error 
> during the connection handshake and then all future AMQP connections fail 
> until the broker is stopped.  This was reproduced with C proton clients and 
> QPID JMS clients but it seemed to depend on the speed of the machine where 
> the broker was running and the network speed to ensure that the timing window 
> would be hit.  Turning on remote debugging in the ActiveMQ startup script 
> made it happen much more frequently.  The QPID JMS clients end up staying 
> hung in the ConnectionEndpoint.open function and the C proton clients return 
> a SASL error.  Code analysis in the broker appeared to point to an incorrect 
> use of static for the list data structure in the AMQPProtocolDiscriminator 
> class.  I am planning to attach  a patch and unit test that demonstrate the 
> behavior as well as some logs.  The unit test fails with a "timeout" as all 
> of the threads get hung when attempting to make connection and seems to 
> require the following MAVEN_OPTS to be set to see it fail consistently:
> export 
> MAVEN_OPTS="-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"
> When running the broker in console mode, the following would be output for 
> each failed client connection attempt:
> Could not decode AMQP frame: hex: 
> 00210201005341d000110002a309414e4f4e594d4f5553a000



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (AMQ-5273) Problem handling connections from multiple AMQP clients in ActiveMQ

[Jesse Fugitt (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesse Fugitt updated AMQ-5273:
--

Attachment: org.apache.activemq.transport.amqp.AMQ5273Test-output.txt
amqp_connection_race.patch
AMQ5273Test.java

Attached git diff and unit test.  See comments in unit test source code for how 
this was run with maven to reproduce.

> Problem handling connections from multiple AMQP clients in ActiveMQ
> ---
>
> Key: AMQ-5273
> URL: https://issues.apache.org/jira/browse/AMQ-5273
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 5.10.0
>Reporter: Jesse Fugitt
>Priority: Critical
>  Labels: AMQP
> Attachments: AMQ5273Test.java, amqp_connection_race.patch, 
> org.apache.activemq.transport.amqp.AMQ5273Test-output.txt
>
>
> When multiple AMQP clients try to connect to the broker at exactly the same 
> time, the broker can end up in a state where it gets an AMQP parsing error 
> during the connection handshake and then all future AMQP connections fail 
> until the broker is stopped.  This was reproduced with C proton clients and 
> QPID JMS clients but it seemed to depend on the speed of the machine where 
> the broker was running and the network speed to ensure that the timing window 
> would be hit.  Turning on remote debugging in the ActiveMQ startup script 
> made it happen much more frequently.  The QPID JMS clients end up staying 
> hung in the ConnectionEndpoint.open function and the C proton clients return 
> a SASL error.  Code analysis in the broker appeared to point to an incorrect 
> use of static for the list data structure in the AMQPProtocolDiscriminator 
> class.  I am planning to attach  a patch and unit test that demonstrate the 
> behavior as well as some logs.  The unit test fails with a "timeout" as all 
> of the threads get hung when attempting to make connection and seems to 
> require the following MAVEN_OPTS to be set to see it fail consistently:
> export 
> MAVEN_OPTS="-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"
> When running the broker in console mode, the following would be output for 
> each failed client connection attempt:
> Could not decode AMQP frame: hex: 
> 00210201005341d000110002a309414e4f4e594d4f5553a000



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (AMQ-5273) Problem handling connections from multiple AMQP clients in ActiveMQ

[Jesse Fugitt (JIRA)]

Jesse Fugitt created AMQ-5273:
-

 Summary: Problem handling connections from multiple AMQP clients 
in ActiveMQ
 Key: AMQ-5273
 URL: https://issues.apache.org/jira/browse/AMQ-5273
 Project: ActiveMQ
  Issue Type: Bug
  Components: AMQP
Affects Versions: 5.10.0
Reporter: Jesse Fugitt
Priority: Critical


When multiple AMQP clients try to connect to the broker at exactly the same 
time, the broker can end up in a state where it gets an AMQP parsing error 
during the connection handshake and then all future AMQP connections fail until 
the broker is stopped.  This was reproduced with C proton clients and QPID JMS 
clients but it seemed to depend on the speed of the machine where the broker 
was running and the network speed to ensure that the timing window would be 
hit.  Turning on remote debugging in the ActiveMQ startup script made it happen 
much more frequently.  The QPID JMS clients end up staying hung in the 
ConnectionEndpoint.open function and the C proton clients return a SASL error.  
Code analysis in the broker appeared to point to an incorrect use of static for 
the list data structure in the AMQPProtocolDiscriminator class.  I am planning 
to attach  a patch and unit test that demonstrate the behavior as well as some 
logs.  The unit test fails with a "timeout" as all of the threads get hung when 
attempting to make connection and seems to require the following MAVEN_OPTS to 
be set to see it fail consistently:
export 
MAVEN_OPTS="-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"

When running the broker in console mode, the following would be output for each 
failed client connection attempt:
Could not decode AMQP frame: hex: 
00210201005341d000110002a309414e4f4e594d4f5553a000




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (AMQ-5272) Implement JSR 356 based WebSocket transport

[Neb Bozovic (JIRA)]

Neb Bozovic created AMQ-5272:


 Summary: Implement JSR 356 based WebSocket transport
 Key: AMQ-5272
 URL: https://issues.apache.org/jira/browse/AMQ-5272
 Project: ActiveMQ
  Issue Type: New Feature
Reporter: Neb Bozovic
Priority: Minor


The present WS transport boots up an embedded Jetty instance on its own port, 
which does not make sense when embedding ActiveMQ in a container-hosted 
application.

Although not that difficult to hack together manually, there should be a 
supported first-party mechanism to configure a WS Stomp/MQTT endpoint when 
embedded in a JSR 356 compatible container.




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (AMQ-5269) NIO transports using blocking accept calls, very slow shutdown

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AMQ-5269:
-

Github user dkulp closed the pull request at:

https://github.com/apache/activemq/pull/33


> NIO transports using blocking accept calls, very slow shutdown
> --
>
> Key: AMQ-5269
> URL: https://issues.apache.org/jira/browse/AMQ-5269
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 5.10.0
>Reporter: Daniel Kulp
>Assignee: Daniel Kulp
> Fix For: 5.11.0
>
> Attachments: AMQ-5269.patch
>
>
> Currently, all the TCP based transports are using the old blocking style of 
> socket.accept() to accept connections.   This works "OK" except that for 
> sockets that have a channel associated with them, the socket.close() doesn't 
> cause it to return immediately.  It still waits for the SoTimeout which is 
> currently set a 2 seconds.   That can cause 2 second delays for any shutdown 
> which causes long, unnecessary delays, particularly in the tests.
> One possible "fix" is to drop the socket.setSoTimeout(2000) call to something 
> much smaller.   However, that would turn the accept thread into a more "busy 
> wait" scenario which is undesirable.
> A better fix is to change the accepts for the sockets that have a 
> ServerSocketChannel to use the NIO based selectors for the accept operations. 
>   The selector.disable()/selector.close() allows the socket and everything to 
> close immediately.  The result is that the NIO based tests now take the same 
> amount of time as the non-NIO based tests (for which socket.close() causes 
> the accept to return immediately).
> Pull request forthcoming.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[GitHub] activemq pull request: [AMQ-5269] Update NIO based transports to u...

[dkulp]

Github user dkulp closed the pull request at:

https://github.com/apache/activemq/pull/33


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (AMQ-5269) NIO transports using blocking accept calls, very slow shutdown

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish resolved AMQ-5269.
---

   Resolution: Fixed
Fix Version/s: 5.11.0

Fixed on trunk, thanks.

> NIO transports using blocking accept calls, very slow shutdown
> --
>
> Key: AMQ-5269
> URL: https://issues.apache.org/jira/browse/AMQ-5269
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 5.10.0
>Reporter: Daniel Kulp
>Assignee: Daniel Kulp
> Fix For: 5.11.0
>
> Attachments: AMQ-5269.patch
>
>
> Currently, all the TCP based transports are using the old blocking style of 
> socket.accept() to accept connections.   This works "OK" except that for 
> sockets that have a channel associated with them, the socket.close() doesn't 
> cause it to return immediately.  It still waits for the SoTimeout which is 
> currently set a 2 seconds.   That can cause 2 second delays for any shutdown 
> which causes long, unnecessary delays, particularly in the tests.
> One possible "fix" is to drop the socket.setSoTimeout(2000) call to something 
> much smaller.   However, that would turn the accept thread into a more "busy 
> wait" scenario which is undesirable.
> A better fix is to change the accepts for the sockets that have a 
> ServerSocketChannel to use the NIO based selectors for the accept operations. 
>   The selector.disable()/selector.close() allows the socket and everything to 
> close immediately.  The result is that the NIO based tests now take the same 
> amount of time as the non-NIO based tests (for which socket.close() causes 
> the accept to return immediately).
> Pull request forthcoming.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (AMQ-5269) NIO transports using blocking accept calls, very slow shutdown

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-5269:
---

Reviewed and ran a bunch of the tests here and everything seems good, can 
commit if you are satisfied with the current changeset

> NIO transports using blocking accept calls, very slow shutdown
> --
>
> Key: AMQ-5269
> URL: https://issues.apache.org/jira/browse/AMQ-5269
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 5.10.0
>Reporter: Daniel Kulp
>Assignee: Daniel Kulp
> Attachments: AMQ-5269.patch
>
>
> Currently, all the TCP based transports are using the old blocking style of 
> socket.accept() to accept connections.   This works "OK" except that for 
> sockets that have a channel associated with them, the socket.close() doesn't 
> cause it to return immediately.  It still waits for the SoTimeout which is 
> currently set a 2 seconds.   That can cause 2 second delays for any shutdown 
> which causes long, unnecessary delays, particularly in the tests.
> One possible "fix" is to drop the socket.setSoTimeout(2000) call to something 
> much smaller.   However, that would turn the accept thread into a more "busy 
> wait" scenario which is undesirable.
> A better fix is to change the accepts for the sockets that have a 
> ServerSocketChannel to use the NIO based selectors for the accept operations. 
>   The selector.disable()/selector.close() allows the socket and everything to 
> close immediately.  The result is that the NIO based tests now take the same 
> amount of time as the non-NIO based tests (for which socket.close() causes 
> the accept to return immediately).
> Pull request forthcoming.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

activemq-cpp-library-3.8.2 :client throwing exception while connecting to the broker

[loranze17]

Hi

I have recently upgraded my cms library from activemq-cpp-library-3.4.5 to
activemq-cpp-library-3.8.2.
with my application client using activemq-cpp-library-3.4.5 is able to
connect to the broker without any issue.
But using latest  activemq-cpp-library-3.8.2 it is not able to connect to
the broker. It is throwing exception. Following is stacktrace of my
application

#0  0x00341f80dda3 in ?? () from /lib64/libgcc_s.so.1
#1  0x00341f80f92f in ?? () from /lib64/libgcc_s.so.1
#2  0x00341f810646 in _Unwind_RaiseException () from
/lib64/libgcc_s.so.1
#3  0x7f268436cd01 in __cxa_throw () from /usr/lib64/libstdc++.so.6
#4  0x7f2683c1b101 in
decaf::internal::util::concurrent::PlatformThread::createNewThread(unsigned
long*, void* (*)(void*), void*, int, long long, long long*) () from
/tools/apache-activemq/activemq-cpp-library-3.8.2/lib/libactivemq-cpp.so.18
#5  0x7f2683c1a693 in
decaf::internal::util::concurrent::Threading::createNewThread(decaf::lang::Thread*,
char const*, long long) () from
/tools/apache-activemq/activemq-cpp-library-3.8.2/lib/libactivemq-cpp.so.18
#6  0x7f2683c4ae7f in
decaf::lang::Thread::initializeSelf(decaf::lang::Runnable*,
std::basic_string, std::allocator >
const&, long long) () from
/tools/apache-activemq/activemq-cpp-library-3.8.2/lib/libactivemq-cpp.so.18
#7  0x7f2683c4b0df in
decaf::lang::Thread::Thread(std::basic_string, std::allocator > const&) () from
/tools/apache-activemq/activemq-cpp-library-3.8.2/lib/libactivemq-cpp.so.18
#8  0x7f2683c84724 in decaf::util::Timer::Timer(std::basic_string, std::allocator > const&) () from
/tools/apache-activemq/activemq-cpp-library-3.8.2/lib/libactivemq-cpp.so.18
#9  0x7f2683b1d978 in
activemq::transport::inactivity::InactivityMonitorData::InactivityMonitorData(decaf::lang::Pointer) () from
/tools/apache-activemq/activemq-cpp-library-3.8.2/lib/libactivemq-cpp.so.18
#10 0x7f2683b1cabe in
activemq::transport::inactivity::InactivityMonitor::InactivityMonitor(decaf::lang::Pointer, decaf::util::Properties
const&, decaf::lang::Pointer) () from
/tools/apache-activemq/activemq-cpp-library-3.8.2/lib/libactivemq-cpp.so.18
#11 0x7f2683b2b075 in
activemq::transport::tcp::TcpTransportFactory::doCreateComposite(decaf::net::URI
const&, decaf::lang::Pointer, decaf::util::Properties
const&) () from
/tools/apache-activemq/activemq-cpp-library-3.8.2/lib/libactivemq-cpp.so.18
#12 0x7f2683b29225 in
activemq::transport::tcp::TcpTransportFactory::create(decaf::net::URI
const&) () from
/tools/apache-activemq/activemq-cpp-library-3.8.2/lib/libactivemq-cpp.so.18
#13 0x7f2683936d41 in
activemq::core::ActiveMQConnectionFactory::doCreateConnection(decaf::net::URI
const&, std::basic_string,
std::allocator > const&, std::basic_string, std::allocator > const&,
std::basic_string, std::allocator >
const&) () from
/tools/apache-activemq/activemq-cpp-library-3.8.2/lib/libactivemq-cpp.so.18



Can anyone please tell why the exceptions is thrown in createNewThread at
decaf level??
How to overcome this?




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/activemq-cpp-library-3-8-2-client-throwing-exception-while-connecting-to-the-broker-tp4682958.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

OSGI ActiveMQ TCP port and webconsole

[sekaijin]

Hi,

I'm running karaf 2.3.5 ActiveMQ 5.9.0
My borker is using the 60030 tcp port
//
I can send and recive messages without problem.
I can see this broker in jmx

I've deployed the webconsole and changed the
/org.apache.activemq.webconsole.cfg/ file
corresponding to my jmx config.
I can browse all queues.
my jms url parameter is
webconsole.jms.url=tcp://localhost:*60030*
but when I send message using the console Iget an error
javax.jms.JMSException: Could not connect to broker URL:
tcp://localhost:*61616*. Reason: java.net.ConnectException: Connection
refused: connect

why the /webconsole.jms.url/ parameter is ignored ?

thank



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/OSGI-ActiveMQ-TCP-port-and-webconsole-tp4683031.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[GitHub] activemq pull request: Cleanup in ConnectTest

[dkulp]

GitHub user dkulp opened a pull request:

https://github.com/apache/activemq/pull/34

Cleanup in ConnectTest

Cleanup in ConnectTest to do two things:
1) connect/disconnect 500 (which still seems high) times instead of as many 
as possible in 25seconds.  On fast machines, this is MUCH faster.
2) Actually call Thead.start(), not Thread.run() in cases where it should 
be on a background thread.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dkulp/activemq ConnectTestCleanup

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq/pull/34.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 #34


commit 7fe431b21f70f2187afe6f28ccb3e78140c4719d
Author: Daniel Kulp 
Date:   2014-07-10T19:28:43Z

Cleanup in ConnectTest to do two things:
1) connect/disconnect 500 (which still seems high) times instead of as many 
as possible in 25seconds.  On fast machines, this is MUCH faster.
2) Actually call Thead.start(), not Thread.run() in cases where it should 
be on a background thread.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (AMQ-5269) NIO transports using blocking accept calls, very slow shutdown

[Daniel Kulp (JIRA)]

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

Daniel Kulp commented on AMQ-5269:
--

On my Mac:

Before:
{code}
Running org.apache.activemq.transport.stomp.Stomp11NIOSSLTest
Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 126.509 sec - 
in org.apache.activemq.transport.stomp.Stomp11NIOSSLTest
Running org.apache.activemq.transport.stomp.Stomp11NIOTest
Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 124.051 sec - 
in org.apache.activemq.transport.stomp.Stomp11NIOTest
Running org.apache.activemq.transport.stomp.Stomp11SslAuthTest
Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 73.105 sec - 
in org.apache.activemq.transport.stomp.Stomp11SslAuthTest
{code}

After:
{code}
Running org.apache.activemq.transport.stomp.Stomp11NIOSSLTest
Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 71.824 sec - 
in org.apache.activemq.transport.stomp.Stomp11NIOSSLTest
Running org.apache.activemq.transport.stomp.Stomp11NIOTest
Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 70.408 sec - 
in org.apache.activemq.transport.stomp.Stomp11NIOTest
Running org.apache.activemq.transport.stomp.Stomp11SslAuthTest
Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 72.747 sec - 
in org.apache.activemq.transport.stomp.Stomp11SslAuthTest
{code}

> NIO transports using blocking accept calls, very slow shutdown
> --
>
> Key: AMQ-5269
> URL: https://issues.apache.org/jira/browse/AMQ-5269
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 5.10.0
>Reporter: Daniel Kulp
>Assignee: Daniel Kulp
> Attachments: AMQ-5269.patch
>
>
> Currently, all the TCP based transports are using the old blocking style of 
> socket.accept() to accept connections.   This works "OK" except that for 
> sockets that have a channel associated with them, the socket.close() doesn't 
> cause it to return immediately.  It still waits for the SoTimeout which is 
> currently set a 2 seconds.   That can cause 2 second delays for any shutdown 
> which causes long, unnecessary delays, particularly in the tests.
> One possible "fix" is to drop the socket.setSoTimeout(2000) call to something 
> much smaller.   However, that would turn the accept thread into a more "busy 
> wait" scenario which is undesirable.
> A better fix is to change the accepts for the sockets that have a 
> ServerSocketChannel to use the NIO based selectors for the accept operations. 
>   The selector.disable()/selector.close() allows the socket and everything to 
> close immediately.  The result is that the NIO based tests now take the same 
> amount of time as the non-NIO based tests (for which socket.close() causes 
> the accept to return immediately).
> Pull request forthcoming.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (AMQ-5269) NIO transports using blocking accept calls, very slow shutdown

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AMQ-5269:
-

GitHub user dkulp opened a pull request:

https://github.com/apache/activemq/pull/33

[AMQ-5269] Update NIO based transports to use a Select mechanism

Update NIO based transports to use a Select mechanism for the accepts 
instead of the blocking select.

Cuts about 10 minutes off the activemq-stomp tests, drops the NIO test 
execution time down to equal to the non-NIO based tests.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dkulp/activemq AMQ-5269

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq/pull/33.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 #33


commit 52ef9745d9bafbeab940ed4937c014be3abc9655
Author: Daniel Kulp 
Date:   2014-07-10T14:57:44Z

[AMQ-5269] Update NIO based transports to use a Select mechanism for the 
accepts instead of the blocking select.
Cuts about 10 minutes off the activemq-stomp tests, drops the NIO test 
execution time down to equal to the non-NIO based tests.




> NIO transports using blocking accept calls, very slow shutdown
> --
>
> Key: AMQ-5269
> URL: https://issues.apache.org/jira/browse/AMQ-5269
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 5.10.0
>Reporter: Daniel Kulp
>Assignee: Daniel Kulp
> Attachments: AMQ-5269.patch
>
>
> Currently, all the TCP based transports are using the old blocking style of 
> socket.accept() to accept connections.   This works "OK" except that for 
> sockets that have a channel associated with them, the socket.close() doesn't 
> cause it to return immediately.  It still waits for the SoTimeout which is 
> currently set a 2 seconds.   That can cause 2 second delays for any shutdown 
> which causes long, unnecessary delays, particularly in the tests.
> One possible "fix" is to drop the socket.setSoTimeout(2000) call to something 
> much smaller.   However, that would turn the accept thread into a more "busy 
> wait" scenario which is undesirable.
> A better fix is to change the accepts for the sockets that have a 
> ServerSocketChannel to use the NIO based selectors for the accept operations. 
>   The selector.disable()/selector.close() allows the socket and everything to 
> close immediately.  The result is that the NIO based tests now take the same 
> amount of time as the non-NIO based tests (for which socket.close() causes 
> the accept to return immediately).
> Pull request forthcoming.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[GitHub] activemq pull request: [AMQ-5269] Update NIO based transports to u...

[dkulp]

GitHub user dkulp opened a pull request:

https://github.com/apache/activemq/pull/33

[AMQ-5269] Update NIO based transports to use a Select mechanism

Update NIO based transports to use a Select mechanism for the accepts 
instead of the blocking select.

Cuts about 10 minutes off the activemq-stomp tests, drops the NIO test 
execution time down to equal to the non-NIO based tests.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dkulp/activemq AMQ-5269

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq/pull/33.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 #33


commit 52ef9745d9bafbeab940ed4937c014be3abc9655
Author: Daniel Kulp 
Date:   2014-07-10T14:57:44Z

[AMQ-5269] Update NIO based transports to use a Select mechanism for the 
accepts instead of the blocking select.
Cuts about 10 minutes off the activemq-stomp tests, drops the NIO test 
execution time down to equal to the non-NIO based tests.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq pull request: Load into M2E, update to Java 7

[dkulp]

Github user dkulp closed the pull request at:

https://github.com/apache/activemq/pull/32


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Possible HornetQ donation to ActiveMQ

[Jean-Baptiste Onofré]

It sounds great !

+1

Regards
JB

On 07/08/2014 04:31 PM, Clebert Suconic wrote:

Hi all,

My name is Clebert Suconic, I'm the project lead for the HornetQ JMS broker
(http://hornetq.jboss.org/). The HornetQ team is currently in the planning
phase for the next release of the broker and we've been thinking about
whether it would make sense for us to collaborate more closely with the
ActiveMQ community.

There is a lot of overlap in the capabilities of the two brokers today and
it strikes us that it would be beneficial to both communities for us to join
forces to build one truly great JMS broker rather than spend our time
duplicating efforts on both brokers. ActiveMQ has a great community of
developers and users and it'd be great to be able to consolidate our work
there.

My understanding is that the Apollo sub-project aimed to provide a basis for
the next generation of ActiveMQ, addressing some of the current limitations.
Perhaps HornetQ could be an alternative. HornetQ has some good performance
and scalability numbers as well as support for JMS 2.0. It already supports
STOMP today and adding support for OpenWire would be straight-forward and
would provide continuity for existing clients. Essentially, the goal could
be to combine the existing flexibility of ActiveMQ with the performance of
HornetQ.

Anyway, these are just some initial ideas, for now I'm really just
interested to know how the ActiveMQ community would feel about a donation of
the HornetQ codebase.

Thanks and best regards,
Clebert.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

[jira] [Updated] (AMQ-5269) NIO transports using blocking accept calls, very slow shutdown

[Daniel Kulp (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Kulp updated AMQ-5269:
-

Attachment: AMQ-5269.patch

Attaching a patch for now as my "git" stuff is in a bit of a mess and I need to 
clean that up.   

> NIO transports using blocking accept calls, very slow shutdown
> --
>
> Key: AMQ-5269
> URL: https://issues.apache.org/jira/browse/AMQ-5269
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 5.10.0
>Reporter: Daniel Kulp
>Assignee: Daniel Kulp
> Attachments: AMQ-5269.patch
>
>
> Currently, all the TCP based transports are using the old blocking style of 
> socket.accept() to accept connections.   This works "OK" except that for 
> sockets that have a channel associated with them, the socket.close() doesn't 
> cause it to return immediately.  It still waits for the SoTimeout which is 
> currently set a 2 seconds.   That can cause 2 second delays for any shutdown 
> which causes long, unnecessary delays, particularly in the tests.
> One possible "fix" is to drop the socket.setSoTimeout(2000) call to something 
> much smaller.   However, that would turn the accept thread into a more "busy 
> wait" scenario which is undesirable.
> A better fix is to change the accepts for the sockets that have a 
> ServerSocketChannel to use the NIO based selectors for the accept operations. 
>   The selector.disable()/selector.close() allows the socket and everything to 
> close immediately.  The result is that the NIO based tests now take the same 
> amount of time as the non-NIO based tests (for which socket.close() causes 
> the accept to return immediately).
> Pull request forthcoming.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (AMQ-5271) Add an in-memory JobSchedulerStore implementation

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish resolved AMQ-5271.
---

Resolution: Fixed

Fixed on trunk. 

> Add an in-memory JobSchedulerStore implementation
> -
>
> Key: AMQ-5271
> URL: https://issues.apache.org/jira/browse/AMQ-5271
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Job Scheduler
>Affects Versions: 5.10.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.11.0
>
>
> For brokers that run with persistence disabled there currently no in-memory 
> job scheduler store so an embedded broker without persistence can't have 
> scheduled messages or do broker led redelivery without manually configuring 
> in the normal JobSchedulerStore impl which requires a disk based store.  We 
> should add an in memory variant that is the default if persistence is 
> disabled but scheduler support is enabled. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (AMQ-5271) Add an in-memory JobSchedulerStore implementation

[Timothy Bish (JIRA)]

Timothy Bish created AMQ-5271:
-

 Summary: Add an in-memory JobSchedulerStore implementation
 Key: AMQ-5271
 URL: https://issues.apache.org/jira/browse/AMQ-5271
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Job Scheduler
Affects Versions: 5.10.0
Reporter: Timothy Bish
Assignee: Timothy Bish
Priority: Minor
 Fix For: 5.11.0


For brokers that run with persistence disabled there currently no in-memory job 
scheduler store so an embedded broker without persistence can't have scheduled 
messages or do broker led redelivery without manually configuring in the normal 
JobSchedulerStore impl which requires a disk based store.  We should add an in 
memory variant that is the default if persistence is disabled but scheduler 
support is enabled. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Possible HornetQ donation to ActiveMQ

[Hiram Chirino]

Nice!


On Thu, Jul 10, 2014 at 12:05 PM, Clebert Suconic
 wrote:
> All the docs are part of the master.. being generated from XML... so they
> are part of the donation as well..
>
>
> The docs are developed maintained, so I don't think there would be any
> issues there.
>
> https://github.com/hornetq/hornetq/tree/master/docs
>
>
>
> these docs are later just ftp-ed to the hornetq website just to make it
> easier for users to see it.. so git master includes it all.
>
>
>
>
> On Thu, Jul 10, 2014 at 12:01 PM, Daniel Kulp  wrote:
>
>>
>> One more thing:
>>
>> HornetQ has a lot of good docs and information on the web site.   Is the
>> intention to also donate some of that?   If so, we’ll likely need a grant
>> for that, but that obviously may be a bit more difficult to identify from
>> git hash/tarball sha1/etc….   That wouldn’t need to be done immediately as
>> that could be done via a separate grant, but something to consider as well
>> while you are chasing things down inside RedHat.  If you only have to do
>> that once, you could make it a bit easier on yourself.   :-)
>>
>> Dan
>>
>>
>>
>> On Jul 10, 2014, at 11:53 AM, Hiram Chirino 
>> wrote:
>>
>> > Hi Clebert ,
>> >
>> > This is a far as I've been able to get with the IP clearance form:
>> >
>> >
>> http://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/hornetq.xml
>> >
>> > I assumed that what you guys want to donate is the code that currently
>> > exists on github master (commit
>> > 90d43fbc158a0e6e3028c7179dbcf984757b88fb).
>> >
>> > Things we still need to do:
>> >
>> > 1) Get Red Hat to file a CCLA with Schedule B filled out
>> > 2) Get a list of your active committers and make sure they have CLAs
>> filed.
>> > 3) "Check and make sure that for all items included with the
>> > distribution that is not under the Apache license, we have the right
>> > to combine with Apache-licensed code and redistribute"
>> > 4) Check and make sure that all items depended upon by the project is
>> > covered by one or more of the approved licenses.
>> > 5) Run a VOTE thread to accept the code donation.
>> >
>> > I encourage the rest of the ActiveMQ PMC members to help check and
>> > double check items #3 and #4 before doing #5.
>> >
>> >
>> > On Thu, Jul 10, 2014 at 10:58 AM, Hiram Chirino 
>> wrote:
>> >> I'll start looking into filling out the ip-clearance from.
>> >>
>> >> On Tue, Jul 8, 2014 at 10:53 AM, Gary Tully 
>> wrote:
>> >>> Hi Clebert,
>> >>> the hornetq specJMS numbers are very impressive so from my perspective
>> >>> we would love to have the code base.
>> >>> We can then evaluate how best to combine the relative strengths of
>> >>> Apollo and HornetQ for the next gen ActiveMQ.
>> >>>
>> >>> Please start the process outlined at [1] and we can look at doing an
>> import.
>> >>>
>> >>> [1] http://incubator.apache.org/ip-clearance/
>> >>>
>> >>>
>> >>> On 8 July 2014 15:37, Hiram Chirino  wrote:
>>  Hi Clebert,
>> 
>>  That sounds very interesting!  Bringing the HornetQ community into
>>  ActiveMQ would be exciting for me.  We could collaborate and bring
>>  together the best features of ActiveMQ, Apollo and HornetQ to create
>>  an amazing next generation messaging system AND grow our developer
>>  community at the same time.  Lots of folks have been asking me when
>>  will ActiveMQ get JMS 2.0 support, so the fact that HornetQ has JMS
>>  2.0 support already is big plus in my book!
>> 
>>  I was building up the Apollo codebase to be that next generation
>>  messaging backbone for ActiveMQ, but perhaps because it's mostly
>>  implemented using Scala, not too many developers got involved and
>>  that's a bit of a problem since the 'Apache Way' of building projects
>>  is more about community than code.  I have been pondering porting
>>  Apollo to be just plain Java based. Since HornetQ is Java based but
>>  and has a similar fully async threading architecture like Apollo,
>>  perhaps this donation will save me lots of work.
>> 
>>  :)
>> 
>>  On Tue, Jul 8, 2014 at 10:31 AM, Clebert Suconic
>>   wrote:
>> > Hi all,
>> >
>> > My name is Clebert Suconic, I'm the project lead for the HornetQ JMS
>> broker
>> > (http://hornetq.jboss.org/). The HornetQ team is currently in the
>> planning
>> > phase for the next release of the broker and we've been thinking
>> about
>> > whether it would make sense for us to collaborate more closely with
>> the
>> > ActiveMQ community.
>> >
>> > There is a lot of overlap in the capabilities of the two brokers
>> today and
>> > it strikes us that it would be beneficial to both communities for us
>> to join
>> > forces to build one truly great JMS broker rather than spend our time
>> > duplicating efforts on both brokers. ActiveMQ has a great community
>> of
>> > developers and users and it'd be great to be able to consolidate our
>> work
>> > there.
>> >

Re: Possible HornetQ donation to ActiveMQ

[Clebert Suconic]

All the docs are part of the master.. being generated from XML... so they
are part of the donation as well..


The docs are developed maintained, so I don't think there would be any
issues there.

https://github.com/hornetq/hornetq/tree/master/docs



these docs are later just ftp-ed to the hornetq website just to make it
easier for users to see it.. so git master includes it all.




On Thu, Jul 10, 2014 at 12:01 PM, Daniel Kulp  wrote:

>
> One more thing:
>
> HornetQ has a lot of good docs and information on the web site.   Is the
> intention to also donate some of that?   If so, we’ll likely need a grant
> for that, but that obviously may be a bit more difficult to identify from
> git hash/tarball sha1/etc….   That wouldn’t need to be done immediately as
> that could be done via a separate grant, but something to consider as well
> while you are chasing things down inside RedHat.  If you only have to do
> that once, you could make it a bit easier on yourself.   :-)
>
> Dan
>
>
>
> On Jul 10, 2014, at 11:53 AM, Hiram Chirino 
> wrote:
>
> > Hi Clebert ,
> >
> > This is a far as I've been able to get with the IP clearance form:
> >
> >
> http://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/hornetq.xml
> >
> > I assumed that what you guys want to donate is the code that currently
> > exists on github master (commit
> > 90d43fbc158a0e6e3028c7179dbcf984757b88fb).
> >
> > Things we still need to do:
> >
> > 1) Get Red Hat to file a CCLA with Schedule B filled out
> > 2) Get a list of your active committers and make sure they have CLAs
> filed.
> > 3) "Check and make sure that for all items included with the
> > distribution that is not under the Apache license, we have the right
> > to combine with Apache-licensed code and redistribute"
> > 4) Check and make sure that all items depended upon by the project is
> > covered by one or more of the approved licenses.
> > 5) Run a VOTE thread to accept the code donation.
> >
> > I encourage the rest of the ActiveMQ PMC members to help check and
> > double check items #3 and #4 before doing #5.
> >
> >
> > On Thu, Jul 10, 2014 at 10:58 AM, Hiram Chirino 
> wrote:
> >> I'll start looking into filling out the ip-clearance from.
> >>
> >> On Tue, Jul 8, 2014 at 10:53 AM, Gary Tully 
> wrote:
> >>> Hi Clebert,
> >>> the hornetq specJMS numbers are very impressive so from my perspective
> >>> we would love to have the code base.
> >>> We can then evaluate how best to combine the relative strengths of
> >>> Apollo and HornetQ for the next gen ActiveMQ.
> >>>
> >>> Please start the process outlined at [1] and we can look at doing an
> import.
> >>>
> >>> [1] http://incubator.apache.org/ip-clearance/
> >>>
> >>>
> >>> On 8 July 2014 15:37, Hiram Chirino  wrote:
>  Hi Clebert,
> 
>  That sounds very interesting!  Bringing the HornetQ community into
>  ActiveMQ would be exciting for me.  We could collaborate and bring
>  together the best features of ActiveMQ, Apollo and HornetQ to create
>  an amazing next generation messaging system AND grow our developer
>  community at the same time.  Lots of folks have been asking me when
>  will ActiveMQ get JMS 2.0 support, so the fact that HornetQ has JMS
>  2.0 support already is big plus in my book!
> 
>  I was building up the Apollo codebase to be that next generation
>  messaging backbone for ActiveMQ, but perhaps because it's mostly
>  implemented using Scala, not too many developers got involved and
>  that's a bit of a problem since the 'Apache Way' of building projects
>  is more about community than code.  I have been pondering porting
>  Apollo to be just plain Java based. Since HornetQ is Java based but
>  and has a similar fully async threading architecture like Apollo,
>  perhaps this donation will save me lots of work.
> 
>  :)
> 
>  On Tue, Jul 8, 2014 at 10:31 AM, Clebert Suconic
>   wrote:
> > Hi all,
> >
> > My name is Clebert Suconic, I'm the project lead for the HornetQ JMS
> broker
> > (http://hornetq.jboss.org/). The HornetQ team is currently in the
> planning
> > phase for the next release of the broker and we've been thinking
> about
> > whether it would make sense for us to collaborate more closely with
> the
> > ActiveMQ community.
> >
> > There is a lot of overlap in the capabilities of the two brokers
> today and
> > it strikes us that it would be beneficial to both communities for us
> to join
> > forces to build one truly great JMS broker rather than spend our time
> > duplicating efforts on both brokers. ActiveMQ has a great community
> of
> > developers and users and it'd be great to be able to consolidate our
> work
> > there.
> >
> > My understanding is that the Apollo sub-project aimed to provide a
> basis for
> > the next generation of ActiveMQ, addressing some of the current
> limitations.
> > Perhaps HornetQ could

Re: Possible HornetQ donation to ActiveMQ

[Daniel Kulp]

One more thing:

HornetQ has a lot of good docs and information on the web site.   Is the 
intention to also donate some of that?   If so, we’ll likely need a grant for 
that, but that obviously may be a bit more difficult to identify from git 
hash/tarball sha1/etc….   That wouldn’t need to be done immediately as that 
could be done via a separate grant, but something to consider as well while you 
are chasing things down inside RedHat.  If you only have to do that once, you 
could make it a bit easier on yourself.   :-)

Dan



On Jul 10, 2014, at 11:53 AM, Hiram Chirino  wrote:

> Hi Clebert ,
> 
> This is a far as I've been able to get with the IP clearance form:
> 
> http://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/hornetq.xml
> 
> I assumed that what you guys want to donate is the code that currently
> exists on github master (commit
> 90d43fbc158a0e6e3028c7179dbcf984757b88fb).
> 
> Things we still need to do:
> 
> 1) Get Red Hat to file a CCLA with Schedule B filled out
> 2) Get a list of your active committers and make sure they have CLAs filed.
> 3) "Check and make sure that for all items included with the
> distribution that is not under the Apache license, we have the right
> to combine with Apache-licensed code and redistribute"
> 4) Check and make sure that all items depended upon by the project is
> covered by one or more of the approved licenses.
> 5) Run a VOTE thread to accept the code donation.
> 
> I encourage the rest of the ActiveMQ PMC members to help check and
> double check items #3 and #4 before doing #5.
> 
> 
> On Thu, Jul 10, 2014 at 10:58 AM, Hiram Chirino  
> wrote:
>> I'll start looking into filling out the ip-clearance from.
>> 
>> On Tue, Jul 8, 2014 at 10:53 AM, Gary Tully  wrote:
>>> Hi Clebert,
>>> the hornetq specJMS numbers are very impressive so from my perspective
>>> we would love to have the code base.
>>> We can then evaluate how best to combine the relative strengths of
>>> Apollo and HornetQ for the next gen ActiveMQ.
>>> 
>>> Please start the process outlined at [1] and we can look at doing an import.
>>> 
>>> [1] http://incubator.apache.org/ip-clearance/
>>> 
>>> 
>>> On 8 July 2014 15:37, Hiram Chirino  wrote:
 Hi Clebert,
 
 That sounds very interesting!  Bringing the HornetQ community into
 ActiveMQ would be exciting for me.  We could collaborate and bring
 together the best features of ActiveMQ, Apollo and HornetQ to create
 an amazing next generation messaging system AND grow our developer
 community at the same time.  Lots of folks have been asking me when
 will ActiveMQ get JMS 2.0 support, so the fact that HornetQ has JMS
 2.0 support already is big plus in my book!
 
 I was building up the Apollo codebase to be that next generation
 messaging backbone for ActiveMQ, but perhaps because it's mostly
 implemented using Scala, not too many developers got involved and
 that's a bit of a problem since the 'Apache Way' of building projects
 is more about community than code.  I have been pondering porting
 Apollo to be just plain Java based. Since HornetQ is Java based but
 and has a similar fully async threading architecture like Apollo,
 perhaps this donation will save me lots of work.
 
 :)
 
 On Tue, Jul 8, 2014 at 10:31 AM, Clebert Suconic
  wrote:
> Hi all,
> 
> My name is Clebert Suconic, I'm the project lead for the HornetQ JMS 
> broker
> (http://hornetq.jboss.org/). The HornetQ team is currently in the planning
> phase for the next release of the broker and we've been thinking about
> whether it would make sense for us to collaborate more closely with the
> ActiveMQ community.
> 
> There is a lot of overlap in the capabilities of the two brokers today and
> it strikes us that it would be beneficial to both communities for us to 
> join
> forces to build one truly great JMS broker rather than spend our time
> duplicating efforts on both brokers. ActiveMQ has a great community of
> developers and users and it'd be great to be able to consolidate our work
> there.
> 
> My understanding is that the Apollo sub-project aimed to provide a basis 
> for
> the next generation of ActiveMQ, addressing some of the current 
> limitations.
> Perhaps HornetQ could be an alternative. HornetQ has some good performance
> and scalability numbers as well as support for JMS 2.0. It already 
> supports
> STOMP today and adding support for OpenWire would be straight-forward and
> would provide continuity for existing clients. Essentially, the goal could
> be to combine the existing flexibility of ActiveMQ with the performance of
> HornetQ.
> 
> Anyway, these are just some initial ideas, for now I'm really just
> interested to know how the ActiveMQ community would feel about a donation 
> of
> the HornetQ codebase.
> 

Re: Possible HornetQ donation to ActiveMQ

[Clebert Suconic]

Thanks Hiram,

Yeah.. our master
We will work through the details here and fill up the documents

I know you know this.. but just for general knowledge HornetQ codebase is
already ASL2 license. We have this on the header of every source file:


 * Red Hat licenses this file to you under the Apache License, version
 * 2.0 (the "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *http://www.apache.org/licenses/LICENSE-2.0



We are looking into filling out the forms...

On Thu, Jul 10, 2014 at 11:53 AM, Hiram Chirino 
wrote:

> Hi Clebert ,
>
> This is a far as I've been able to get with the IP clearance form:
>
>
> http://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/hornetq.xml
>
> I assumed that what you guys want to donate is the code that currently
> exists on github master (commit
> 90d43fbc158a0e6e3028c7179dbcf984757b88fb).
>
> Things we still need to do:
>
> 1) Get Red Hat to file a CCLA with Schedule B filled out
> 2) Get a list of your active committers and make sure they have CLAs filed.
> 3) "Check and make sure that for all items included with the
> distribution that is not under the Apache license, we have the right
> to combine with Apache-licensed code and redistribute"
> 4) Check and make sure that all items depended upon by the project is
> covered by one or more of the approved licenses.
> 5) Run a VOTE thread to accept the code donation.
>
> I encourage the rest of the ActiveMQ PMC members to help check and
> double check items #3 and #4 before doing #5.
>
>
> On Thu, Jul 10, 2014 at 10:58 AM, Hiram Chirino 
> wrote:
> > I'll start looking into filling out the ip-clearance from.
> >
> > On Tue, Jul 8, 2014 at 10:53 AM, Gary Tully 
> wrote:
> >> Hi Clebert,
> >> the hornetq specJMS numbers are very impressive so from my perspective
> >> we would love to have the code base.
> >> We can then evaluate how best to combine the relative strengths of
> >> Apollo and HornetQ for the next gen ActiveMQ.
> >>
> >> Please start the process outlined at [1] and we can look at doing an
> import.
> >>
> >> [1] http://incubator.apache.org/ip-clearance/
> >>
> >>
> >> On 8 July 2014 15:37, Hiram Chirino  wrote:
> >>> Hi Clebert,
> >>>
> >>> That sounds very interesting!  Bringing the HornetQ community into
> >>> ActiveMQ would be exciting for me.  We could collaborate and bring
> >>> together the best features of ActiveMQ, Apollo and HornetQ to create
> >>> an amazing next generation messaging system AND grow our developer
> >>> community at the same time.  Lots of folks have been asking me when
> >>> will ActiveMQ get JMS 2.0 support, so the fact that HornetQ has JMS
> >>> 2.0 support already is big plus in my book!
> >>>
> >>> I was building up the Apollo codebase to be that next generation
> >>> messaging backbone for ActiveMQ, but perhaps because it's mostly
> >>> implemented using Scala, not too many developers got involved and
> >>> that's a bit of a problem since the 'Apache Way' of building projects
> >>> is more about community than code.  I have been pondering porting
> >>> Apollo to be just plain Java based. Since HornetQ is Java based but
> >>> and has a similar fully async threading architecture like Apollo,
> >>> perhaps this donation will save me lots of work.
> >>>
> >>> :)
> >>>
> >>> On Tue, Jul 8, 2014 at 10:31 AM, Clebert Suconic
> >>>  wrote:
>  Hi all,
> 
>  My name is Clebert Suconic, I'm the project lead for the HornetQ JMS
> broker
>  (http://hornetq.jboss.org/). The HornetQ team is currently in the
> planning
>  phase for the next release of the broker and we've been thinking about
>  whether it would make sense for us to collaborate more closely with
> the
>  ActiveMQ community.
> 
>  There is a lot of overlap in the capabilities of the two brokers
> today and
>  it strikes us that it would be beneficial to both communities for us
> to join
>  forces to build one truly great JMS broker rather than spend our time
>  duplicating efforts on both brokers. ActiveMQ has a great community of
>  developers and users and it'd be great to be able to consolidate our
> work
>  there.
> 
>  My understanding is that the Apollo sub-project aimed to provide a
> basis for
>  the next generation of ActiveMQ, addressing some of the current
> limitations.
>  Perhaps HornetQ could be an alternative. HornetQ has some good
> performance
>  and scalability numbers as well as support for JMS 2.0. It already
> supports
>  STOMP today and adding support for OpenWire would be straight-forward
> and
>  would provide continuity for existing clients. Essentially, the goal
> could
>  be to combine the existing flexibility of ActiveMQ with the
> performance of
>  HornetQ.
> 
>  Anyway, these are just some initial ideas, for now I'm really just
>  interested to know how the ActiveMQ community would feel about a
>

Re: Possible HornetQ donation to ActiveMQ

[Hiram Chirino]

Hi Clebert ,

This is a far as I've been able to get with the IP clearance form:

http://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/hornetq.xml

I assumed that what you guys want to donate is the code that currently
exists on github master (commit
90d43fbc158a0e6e3028c7179dbcf984757b88fb).

Things we still need to do:

1) Get Red Hat to file a CCLA with Schedule B filled out
2) Get a list of your active committers and make sure they have CLAs filed.
3) "Check and make sure that for all items included with the
distribution that is not under the Apache license, we have the right
to combine with Apache-licensed code and redistribute"
4) Check and make sure that all items depended upon by the project is
covered by one or more of the approved licenses.
5) Run a VOTE thread to accept the code donation.

I encourage the rest of the ActiveMQ PMC members to help check and
double check items #3 and #4 before doing #5.


On Thu, Jul 10, 2014 at 10:58 AM, Hiram Chirino  wrote:
> I'll start looking into filling out the ip-clearance from.
>
> On Tue, Jul 8, 2014 at 10:53 AM, Gary Tully  wrote:
>> Hi Clebert,
>> the hornetq specJMS numbers are very impressive so from my perspective
>> we would love to have the code base.
>> We can then evaluate how best to combine the relative strengths of
>> Apollo and HornetQ for the next gen ActiveMQ.
>>
>> Please start the process outlined at [1] and we can look at doing an import.
>>
>> [1] http://incubator.apache.org/ip-clearance/
>>
>>
>> On 8 July 2014 15:37, Hiram Chirino  wrote:
>>> Hi Clebert,
>>>
>>> That sounds very interesting!  Bringing the HornetQ community into
>>> ActiveMQ would be exciting for me.  We could collaborate and bring
>>> together the best features of ActiveMQ, Apollo and HornetQ to create
>>> an amazing next generation messaging system AND grow our developer
>>> community at the same time.  Lots of folks have been asking me when
>>> will ActiveMQ get JMS 2.0 support, so the fact that HornetQ has JMS
>>> 2.0 support already is big plus in my book!
>>>
>>> I was building up the Apollo codebase to be that next generation
>>> messaging backbone for ActiveMQ, but perhaps because it's mostly
>>> implemented using Scala, not too many developers got involved and
>>> that's a bit of a problem since the 'Apache Way' of building projects
>>> is more about community than code.  I have been pondering porting
>>> Apollo to be just plain Java based. Since HornetQ is Java based but
>>> and has a similar fully async threading architecture like Apollo,
>>> perhaps this donation will save me lots of work.
>>>
>>> :)
>>>
>>> On Tue, Jul 8, 2014 at 10:31 AM, Clebert Suconic
>>>  wrote:
 Hi all,

 My name is Clebert Suconic, I'm the project lead for the HornetQ JMS broker
 (http://hornetq.jboss.org/). The HornetQ team is currently in the planning
 phase for the next release of the broker and we've been thinking about
 whether it would make sense for us to collaborate more closely with the
 ActiveMQ community.

 There is a lot of overlap in the capabilities of the two brokers today and
 it strikes us that it would be beneficial to both communities for us to 
 join
 forces to build one truly great JMS broker rather than spend our time
 duplicating efforts on both brokers. ActiveMQ has a great community of
 developers and users and it'd be great to be able to consolidate our work
 there.

 My understanding is that the Apollo sub-project aimed to provide a basis 
 for
 the next generation of ActiveMQ, addressing some of the current 
 limitations.
 Perhaps HornetQ could be an alternative. HornetQ has some good performance
 and scalability numbers as well as support for JMS 2.0. It already supports
 STOMP today and adding support for OpenWire would be straight-forward and
 would provide continuity for existing clients. Essentially, the goal could
 be to combine the existing flexibility of ActiveMQ with the performance of
 HornetQ.

 Anyway, these are just some initial ideas, for now I'm really just
 interested to know how the ActiveMQ community would feel about a donation 
 of
 the HornetQ codebase.

 Thanks and best regards,
 Clebert.
>>>
>>>
>>>
>>> --
>>> Hiram Chirino
>>> Engineering | Red Hat, Inc.
>>> hchir...@redhat.com | fusesource.com | redhat.com
>>> skype: hiramchirino | twitter: @hiramchirino
>>
>>
>>
>> --
>> http://redhat.com
>> http://blog.garytully.com
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino



-- 
Hiram Chirino
Engineering | Red Hat, Inc.
hchir...@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino

[jira] [Created] (AMQ-5270) JoramJmsTests hang on some platforms

[Kevin Earls (JIRA)]

Kevin Earls created AMQ-5270:


 Summary: JoramJmsTests hang on some platforms
 Key: AMQ-5270
 URL: https://issues.apache.org/jira/browse/AMQ-5270
 Project: ActiveMQ
  Issue Type: Test
Reporter: Kevin Earls
Assignee: Kevin Earls
Priority: Minor


Several of the JoramJmsTest suites (in particular JoramJmsNioTest and 
JoramJmsSslTest) hang on Windows and Solaris boxes under Jenkins.




--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Possible HornetQ donation to ActiveMQ

[Hiram Chirino]

I'll start looking into filling out the ip-clearance from.

On Tue, Jul 8, 2014 at 10:53 AM, Gary Tully  wrote:
> Hi Clebert,
> the hornetq specJMS numbers are very impressive so from my perspective
> we would love to have the code base.
> We can then evaluate how best to combine the relative strengths of
> Apollo and HornetQ for the next gen ActiveMQ.
>
> Please start the process outlined at [1] and we can look at doing an import.
>
> [1] http://incubator.apache.org/ip-clearance/
>
>
> On 8 July 2014 15:37, Hiram Chirino  wrote:
>> Hi Clebert,
>>
>> That sounds very interesting!  Bringing the HornetQ community into
>> ActiveMQ would be exciting for me.  We could collaborate and bring
>> together the best features of ActiveMQ, Apollo and HornetQ to create
>> an amazing next generation messaging system AND grow our developer
>> community at the same time.  Lots of folks have been asking me when
>> will ActiveMQ get JMS 2.0 support, so the fact that HornetQ has JMS
>> 2.0 support already is big plus in my book!
>>
>> I was building up the Apollo codebase to be that next generation
>> messaging backbone for ActiveMQ, but perhaps because it's mostly
>> implemented using Scala, not too many developers got involved and
>> that's a bit of a problem since the 'Apache Way' of building projects
>> is more about community than code.  I have been pondering porting
>> Apollo to be just plain Java based. Since HornetQ is Java based but
>> and has a similar fully async threading architecture like Apollo,
>> perhaps this donation will save me lots of work.
>>
>> :)
>>
>> On Tue, Jul 8, 2014 at 10:31 AM, Clebert Suconic
>>  wrote:
>>> Hi all,
>>>
>>> My name is Clebert Suconic, I'm the project lead for the HornetQ JMS broker
>>> (http://hornetq.jboss.org/). The HornetQ team is currently in the planning
>>> phase for the next release of the broker and we've been thinking about
>>> whether it would make sense for us to collaborate more closely with the
>>> ActiveMQ community.
>>>
>>> There is a lot of overlap in the capabilities of the two brokers today and
>>> it strikes us that it would be beneficial to both communities for us to join
>>> forces to build one truly great JMS broker rather than spend our time
>>> duplicating efforts on both brokers. ActiveMQ has a great community of
>>> developers and users and it'd be great to be able to consolidate our work
>>> there.
>>>
>>> My understanding is that the Apollo sub-project aimed to provide a basis for
>>> the next generation of ActiveMQ, addressing some of the current limitations.
>>> Perhaps HornetQ could be an alternative. HornetQ has some good performance
>>> and scalability numbers as well as support for JMS 2.0. It already supports
>>> STOMP today and adding support for OpenWire would be straight-forward and
>>> would provide continuity for existing clients. Essentially, the goal could
>>> be to combine the existing flexibility of ActiveMQ with the performance of
>>> HornetQ.
>>>
>>> Anyway, these are just some initial ideas, for now I'm really just
>>> interested to know how the ActiveMQ community would feel about a donation of
>>> the HornetQ codebase.
>>>
>>> Thanks and best regards,
>>> Clebert.
>>
>>
>>
>> --
>> Hiram Chirino
>> Engineering | Red Hat, Inc.
>> hchir...@redhat.com | fusesource.com | redhat.com
>> skype: hiramchirino | twitter: @hiramchirino
>
>
>
> --
> http://redhat.com
> http://blog.garytully.com



-- 
Hiram Chirino
Engineering | Red Hat, Inc.
hchir...@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino

[jira] [Created] (AMQ-5269) NIO transports using blocking accept calls, very slow shutdown

[Daniel Kulp (JIRA)]

Daniel Kulp created AMQ-5269:


 Summary: NIO transports using blocking accept calls, very slow 
shutdown
 Key: AMQ-5269
 URL: https://issues.apache.org/jira/browse/AMQ-5269
 Project: ActiveMQ
  Issue Type: Bug
  Components: Transport
Affects Versions: 5.10.0
Reporter: Daniel Kulp
Assignee: Daniel Kulp



Currently, all the TCP based transports are using the old blocking style of 
socket.accept() to accept connections.   This works "OK" except that for 
sockets that have a channel associated with them, the socket.close() doesn't 
cause it to return immediately.  It still waits for the SoTimeout which is 
currently set a 2 seconds.   That can cause 2 second delays for any shutdown 
which causes long, unnecessary delays, particularly in the tests.

One possible "fix" is to drop the socket.setSoTimeout(2000) call to something 
much smaller.   However, that would turn the accept thread into a more "busy 
wait" scenario which is undesirable.

A better fix is to change the accepts for the sockets that have a 
ServerSocketChannel to use the NIO based selectors for the accept operations.   
The selector.disable()/selector.close() allows the socket and everything to 
close immediately.  The result is that the NIO based tests now take the same 
amount of time as the non-NIO based tests (for which socket.close() causes the 
accept to return immediately).

Pull request forthcoming.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (AMQ-5268) PooledConnectionFactory gets in endless loop when storing into JNDI

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-5268:
---

Can you create a JUnit test that shows the problem, and create a patch that 
resolves it?

> PooledConnectionFactory gets in endless loop when storing into JNDI
> ---
>
> Key: AMQ-5268
> URL: https://issues.apache.org/jira/browse/AMQ-5268
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-pool
>Affects Versions: 5.9.0, 5.9.1, 5.10.0
> Environment: JDK-1.6.0_38, tomcat-naming (JNDI)
>Reporter: Michal Kubricht
>  Labels: jndi, pool
> Attachments: AmqJndiReference.java
>
>
> We got into troubles when upgrading from 5.7.0 to new version 5.10.0. One of 
> our tests which uses binding of *PooledConnectionFactory* into JNDI 
> (tomcat-naming) got *stuck* and computes *in endless loop*.
> Problem is implementation of interface 
> {{org.apache.activemq.jndi.JNDIStorableInterface}} in class 
> {{org.apache.activemq.pool.PooledConnectionFactory}}:
> - method {{populateProperties(Properties props)}} implementation uses 
> {{IntrospectionSupport.getProperties(...)}} in order to set properties for 
> all getters,
> - setting properties works for basic types, but causes stack overflow for 
> getters - {{getReference()}} and {{getProperties()}} which creates recursion 
> loops
> - loop #1: PooledConnectionFactory.getProperties -> 
> PooledConnectionFactory.populateProperties -> 
> IntrospectionSupport.getProperties -> PooledConnectionFactory.getProperties
> - loop #2: PooledConnectionFactory.getProperties -> 
> PooledConnectionFactory.populateProperties -> 
> IntrospectionSupport.getProperties -> PooledConnectionFactory.getReference -> 
> JNDIReferenceFactory.createReference -> PooledConnectionFactory.getProperties
> - additional info: recursion loop doesn't end with StackOverflowError, but 
> InvocationTargetException is propagated to IntrospectionSupport.getProperties 
> method where it is being ignored and causes "almost endless" computation 
> (exponential complexity)
> Example test without using JNDI, but using key methods showing the problem 
> and its possible solution/workaround for AMQ 5.10.0 is attached.
> We found that error exists for AMQ 5.9.0 and newer after resolving following 
> issue AMQ-4757.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (AMQ-5102) AMQ4914Test.testSendHugeMessage times out on CI boxes

[Kevin Earls (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Earls resolved AMQ-5102.
--

Resolution: Fixed

Fixed during upgrade to Proton 0.7

> AMQ4914Test.testSendHugeMessage times out on CI boxes
> -
>
> Key: AMQ-5102
> URL: https://issues.apache.org/jira/browse/AMQ-5102
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
>Reporter: Kevin Earls
>Assignee: Kevin Earls
>Priority: Minor
>
> This test fails intermittently with the error below.  This is a pretty 
> marginal case; it never fails on my laptop, and it doesn't fail on CI boxes 
> when run on its own, only when all tests are run.
> testSendHugeMessage(org.apache.activemq.transport.amqp.bugs.AMQ4914Test)  
> Time elapsed: 303.375 sec  <<< ERROR!
> java.lang.Exception: test timed out after 30 milliseconds
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:485)
>   at 
> org.apache.qpid.amqp_1_0.client.Receiver.receiveFromPrefetch(Receiver.java:328)
>   at org.apache.qpid.amqp_1_0.client.Receiver.receive(Receiver.java:258)
>   at 
> org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receive0(MessageConsumerImpl.java:291)
>   at 
> org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receiveImpl(MessageConsumerImpl.java:260)
>   at 
> org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receive(MessageConsumerImpl.java:235)
>   at 
> org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receive(MessageConsumerImpl.java:57)
>   at 
> org.apache.activemq.transport.amqp.bugs.AMQ4914Test.doTestSendLargeMessage(AMQ4914Test.java:104)
>   at 
> org.apache.activemq.transport.amqp.bugs.AMQ4914Test.testSendHugeMessage(AMQ4914Test.java:80)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Advisory messages for remote broker clients?

[Christian Posta]

You may need to write a little JMX query script (or see the activemq-admin
script that ships by default). You can try looking it up that way. I think
jolokia is enabled an all recent versions as well, so could use
REST/json/http to look it up as well:

http://activemq.apache.org/rest.html

In general, for dynamic discover of brokers, Fabric8 can help you:

http://fabric8.io
http://fabric8.io/gitbook/brokerClients.html




On Thu, Jul 10, 2014 at 3:26 AM, nauman73  wrote:

> Hi ceposta
>
> Thanks for quick feedback. The camel route does the trick and I am able to
> route the advisory messages to opposite broker.
>
> I have a little hiccup though that I have not been able to overcome. In
> order to route the messages to opposite broker I need to establish a
> connection with opposite broker by providing the configuration in XML. I
> have done as follows for the moment.
>
>  class="org.apache.activemq.camel.component.ActiveMQComponent" >
> 
> 
> 
> 
> 
> 
> 
> 
>
> The "brokerURL" is currently pointing to IP address of opposite broker.
> However, I would like to dynamically discover the brokerURL for the
> opposite
> broker by somehow fetching the remote address of the network bridge, as
> seen
> in attached image.
>
> 
>
> I have tried to find a way to do this via XML configuration but so far no
> luck.
>
> Is it at all possible to do it in XML configuration?
>
> Thanks
>
> Regards
> Nauman
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Advisory-messages-for-remote-broker-clients-tp4683016p4683064.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>



-- 
*Christian Posta*
http://www.christianposta.com/blog
http://fabric8.io
twitter: @christianposta

[jira] [Commented] (AMQ-5260) Cross talk over duplex network connection can lead to blocking (alternative take)

[matteo rulli (JIRA)]

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

matteo rulli commented on AMQ-5260:
---

I tried with the following patch:
{noformat}
--- 
\activemq-parent-5.9.0-orig\activemq-broker\src\main\java\org\apache\activemq\network\DemandForwardingBridgeSupport.java
Tue Oct 15 00:41:46 2013
+++ 
\activemq-parent-5.9.0\activemq-broker\src\main\java\org\apache\activemq\network\DemandForwardingBridgeSupport.java
 Thu Jul 10 11:51:44 2014
@@ -30,6 +30,8 @@
 import java.util.concurrent.TimeoutException;
 import java.util.concurrent.atomic.AtomicBoolean;
 import java.util.concurrent.atomic.AtomicLong;
+import java.util.concurrent.locks.Lock;
+import java.util.concurrent.locks.ReentrantLock;
 
 import javax.management.ObjectName;
 
@@ -125,6 +127,8 @@
 private Transport duplexInboundLocalBroker = null;
 private ProducerInfo duplexInboundLocalProducerInfo;
 
+private static final Lock consumerInfoLock = new ReentrantLock(); 
+
 public DemandForwardingBridgeSupport(NetworkBridgeConfiguration 
configuration, Transport localBroker, Transport remoteBroker) {
 this.configuration = configuration;
 this.localBroker = localBroker;
@@ -708,11 +712,16 @@
 return;
 }
 
+/* - AMQ-5260 start 
--- */
 // in a cyclic network there can be multiple bridges per broker 
that can propagate
 // a network subscription so there is a need to synchronize on a 
shared entity
-synchronized (brokerService.getVmConnectorURI()) {
-addConsumerInfo(info);
-}
+//synchronized (brokerService.getVmConnectorURI()) {
+//addConsumerInfo(info);
+//}
+// the lock has been moved in the addConsumerInfo method to 
overcome the AMQ-5260
+addConsumerInfo(info);
+/* - AMQ-5260 end 
- */
+
 } else if (data.getClass() == DestinationInfo.class) {
 // It's a destination info - we want to pass up information about 
temporary destinations
 final DestinationInfo destInfo = (DestinationInfo) data;
@@ -1115,20 +1124,31 @@
 }
 
 protected void addConsumerInfo(final ConsumerInfo consumerInfo) throws 
IOException {
-ConsumerInfo info = consumerInfo.copy();
-addRemoteBrokerToBrokerPath(info);
-DemandSubscription sub = createDemandSubscription(info);
-if (sub != null) {
-if (duplicateSuppressionIsRequired(sub)) {
-undoMapRegistration(sub);
-} else {
-if (consumerInfo.isDurable()) {
-sub.getDurableRemoteSubs().add(new 
SubscriptionInfo(sub.getRemoteInfo().getClientId(), 
consumerInfo.getSubscriptionName()));
-}
-addSubscription(sub);
-LOG.debug("{} new demand subscription: {}", 
configuration.getBrokerName(), sub);
-}
-}
+   boolean addSubscription = false;
+   DemandSubscription sub = null;
+   consumerInfoLock.lock();
+   try{
+   ConsumerInfo info = consumerInfo.copy();
+   addRemoteBrokerToBrokerPath(info);
+   sub = createDemandSubscription(info);
+   if (sub != null) {
+   if (duplicateSuppressionIsRequired(sub)) {
+   undoMapRegistration(sub);
+   } else {
+   if (consumerInfo.isDurable()) {
+   sub.getDurableRemoteSubs().add(new 
SubscriptionInfo(sub.getRemoteInfo().getClientId(), 
consumerInfo.getSubscriptionName()));
+   }
+   addSubscription = true;
+   LOG.debug("{} new demand subscription: {}", 
configuration.getBrokerName(), sub);
+   }
+   }
+   }finally{
+   consumerInfoLock.unlock();
+   }
+   if(addSubscription && sub != null) {
+   addSubscription(sub);
+   LOG.debug("{} new demand subscription: {} has beed added", 
configuration.getBrokerName(), sub);
+   }
 }
 
 private void undoMapRegistration(DemandSubscription sub) {
{noformat}

But in I run into another deadlock:

STACKTRACE 1:
{noformat}
Name: ActiveMQ BrokerService[master2] Task-106
State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@2c8aad83 
owned by: ActiveMQ Transport: tcp:///10.0.1.219:61616@64215
Total blocked: 0  Total waited: 6

Stack trace: 
 sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(Unknown Source)
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown
 Source)
j

[jira] [Resolved] (AMQ-5266) Stuck Messages in Single Broker when using JDBC Persistent Store

[Gary Tully (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Tully resolved AMQ-5266.
-

Resolution: Fixed

fix in http://git-wip-us.apache.org/repos/asf/activemq/commit/6348d119

scans are now limited to the last insert or the minimum pending insert, which 
ensures that we don't read ahead of the destination order.

> Stuck Messages in Single Broker when using JDBC Persistent Store
> 
>
> Key: AMQ-5266
> URL: https://issues.apache.org/jira/browse/AMQ-5266
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Message Store
>Affects Versions: 5.10.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>  Labels: Hanging, JDBC, Order
> Fix For: 5.11.0
>
>
> With multiple concurrent producer transactions and active fast consumers it 
> is possible to get out of order db insertions and scans resulting in a 
> skipped dispatch. This scenario is exacerbated when the cursor cache is 
> disabled because every dispatch will potentially result in a scan.
> the JDBC store maps jms transaction to jdbc connection transactions at the 
> point of a commit and these can occur in parallel. The broker tracks a 
> sequenceId to ensure ordering relative to a jms connection and  scans respect 
> that order but there is currently nothing to stop a scan seeing a later 
> sequence before an earlier sequence is stored. In other words, inserts can 
> race, but the reader needs to limit a read to the lowest outstanding sequence.
> On a restart, any stuck messages will be replayed correctly, because the 
> cursor transient state w.r.t to the last sequence id read will be reset.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: JDK requirements for 5.11?

[Hadrian Zbarcea]

+1 from me too.

Dan submitted a pull request already. If there's no objection I will commit it 
later today or tomorrow. Waiting too long will make the merge non trivial.

Cheers,
Hadrian


On Wednesday 09 July 2014 09:23:21 Hiram Chirino wrote:
> +1 lets require Java 7
> 
> On Tue, Jul 8, 2014 at 4:47 PM, Daniel Kulp  wrote:
> > Has there been a discussion and/or agreement about the Java requirements
> > for 5.11?  5.10 still support Java6.  For 5.11, would it make sense to
> > require Java7?
> >
> > I’m mostly asking as I have a pull request coming that updates all the
> > poms and such so that you can pull activemq into eclipse via M2E instead
> > of the eclipse:eclipse thing.  However, there is one small issue around
> > activemq-runtime-config that causes a problem if Eclipse is running with
> > Java7, but the project level is Java6.  I *may* be able to work around
> > it, but it’s not work spending the time if the plan is to update to Java
> > 7 anyway.
> >
> > Thoughts?
> >
> > --
> > Daniel Kulp
> > dk...@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> 

[jira] [Updated] (AMQ-5268) PooledConnectionFactory gets in endless loop when storing into JNDI

[Michal Kubricht (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michal Kubricht updated AMQ-5268:
-

Attachment: AmqJndiReference.java

> PooledConnectionFactory gets in endless loop when storing into JNDI
> ---
>
> Key: AMQ-5268
> URL: https://issues.apache.org/jira/browse/AMQ-5268
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-pool
>Affects Versions: 5.9.0, 5.9.1, 5.10.0
> Environment: JDK-1.6.0_38, tomcat-naming (JNDI)
>Reporter: Michal Kubricht
>  Labels: jndi, pool
> Attachments: AmqJndiReference.java
>
>
> We got into troubles when upgrading from 5.7.0 to new version 5.10.0. One of 
> our tests which uses binding of *PooledConnectionFactory* into JNDI 
> (tomcat-naming) got *stuck* and computes *in endless loop*.
> Problem is implementation of interface 
> {{org.apache.activemq.jndi.JNDIStorableInterface}} in class 
> {{org.apache.activemq.pool.PooledConnectionFactory}}:
> - method {{populateProperties(Properties props)}} implementation uses 
> {{IntrospectionSupport.getProperties(...)}} in order to set properties for 
> all getters,
> - setting properties works for basic types, but causes stack overflow for 
> getters - {{getReference()}} and {{getProperties()}} which creates recursion 
> loops
> - loop #1: PooledConnectionFactory.getProperties -> 
> PooledConnectionFactory.populateProperties -> 
> IntrospectionSupport.getProperties -> PooledConnectionFactory.getProperties
> - loop #2: PooledConnectionFactory.getProperties -> 
> PooledConnectionFactory.populateProperties -> 
> IntrospectionSupport.getProperties -> PooledConnectionFactory.getReference -> 
> JNDIReferenceFactory.createReference -> PooledConnectionFactory.getProperties
> - additional info: recursion loop doesn't end with StackOverflowError, but 
> InvocationTargetException is propagated to IntrospectionSupport.getProperties 
> method where it is being ignored and causes "almost endless" computation 
> (exponential complexity)
> Example test without using JNDI, but using key methods showing the problem 
> and its possible solution/workaround for AMQ 5.10.0 is attached.
> We found that error exists for AMQ 5.9.0 and newer after resolving following 
> issue AMQ-4757.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (AMQ-5268) PooledConnectionFactory gets in endless loop when storing into JNDI

[Michal Kubricht (JIRA)]

Michal Kubricht created AMQ-5268:


 Summary: PooledConnectionFactory gets in endless loop when storing 
into JNDI
 Key: AMQ-5268
 URL: https://issues.apache.org/jira/browse/AMQ-5268
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-pool
Affects Versions: 5.10.0, 5.9.1, 5.9.0
 Environment: JDK-1.6.0_38, tomcat-naming (JNDI)
Reporter: Michal Kubricht


We got into troubles when upgrading from 5.7.0 to new version 5.10.0. One of 
our tests which uses binding of *PooledConnectionFactory* into JNDI 
(tomcat-naming) got *stuck* and computes *in endless loop*.

Problem is implementation of interface 
{{org.apache.activemq.jndi.JNDIStorableInterface}} in class 
{{org.apache.activemq.pool.PooledConnectionFactory}}:
- method {{populateProperties(Properties props)}} implementation uses 
{{IntrospectionSupport.getProperties(...)}} in order to set properties for all 
getters,
- setting properties works for basic types, but causes stack overflow for 
getters - {{getReference()}} and {{getProperties()}} which creates recursion 
loops
- loop #1: PooledConnectionFactory.getProperties -> 
PooledConnectionFactory.populateProperties -> 
IntrospectionSupport.getProperties -> PooledConnectionFactory.getProperties
- loop #2: PooledConnectionFactory.getProperties -> 
PooledConnectionFactory.populateProperties -> 
IntrospectionSupport.getProperties -> PooledConnectionFactory.getReference -> 
JNDIReferenceFactory.createReference -> PooledConnectionFactory.getProperties
- additional info: recursion loop doesn't end with StackOverflowError, but 
InvocationTargetException is propagated to IntrospectionSupport.getProperties 
method where it is being ignored and causes "almost endless" computation 
(exponential complexity)

Example test without using JNDI, but using key methods showing the problem and 
its possible solution/workaround for AMQ 5.10.0 is attached.

We found that error exists for AMQ 5.9.0 and newer after resolving following 
issue AMQ-4757.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Advisory messages for remote broker clients?

[nauman73]

Hi ceposta

Thanks for quick feedback. The camel route does the trick and I am able to
route the advisory messages to opposite broker.

I have a little hiccup though that I have not been able to overcome. In
order to route the messages to opposite broker I need to establish a
connection with opposite broker by providing the configuration in XML. I
have done as follows for the moment.











The "brokerURL" is currently pointing to IP address of opposite broker.
However, I would like to dynamically discover the brokerURL for the opposite
broker by somehow fetching the remote address of the network bridge, as seen
in attached image.

 

I have tried to find a way to do this via XML configuration but so far no
luck.

Is it at all possible to do it in XML configuration?

Thanks

Regards
Nauman




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Advisory-messages-for-remote-broker-clients-tp4683016p4683064.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[jira] [Created] (AMQ-5267) Some MQTT tests hang on HP-UX

[Kevin Earls (JIRA)]

Kevin Earls created AMQ-5267:


 Summary: Some MQTT tests hang on HP-UX
 Key: AMQ-5267
 URL: https://issues.apache.org/jira/browse/AMQ-5267
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
 Environment: HP-UX 
Reporter: Kevin Earls
Priority: Minor


The MQTTNioTest and MQTTSSLTest test suites hang when run under Jenkins on 
HP-UX.  The tests all have timeouts, but the hang occurs in FailOnTimeout, as 
shown in the stack trace below.

jenkins@srt-hpux:/fuse/jenkins/>jstack 25654
2014-07-10 04:24:00
Full thread dump Java HotSpot(TM) Server VM (24.51-b03-jre1.7.0.09-rc1 mixed 
mode):

"Attach Listener" daemon prio=8 tid=0x00595000 nid=148 lwp_id=2776392 waiting 
on condition [0x]
   java.lang.Thread.State: RUNNABLE

"InactivityMonitor ReadCheck" daemon prio=8 tid=0x00595a00 nid=147 
lwp_id=2776353 in Object.wait() [0x31e0]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x3aabfda8> (a java.util.TaskQueue)
at java.util.TimerThread.mainLoop(Timer.java:552)
- locked <0x3aabfda8> (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:505)

"ActiveMQ BrokerService[localhost] Task-2" daemon prio=8 tid=0x00595600 nid=146 
lwp_id=2776352 waiting on condition [0x31f8]
   java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x3aac0b80> (a 
java.util.concurrent.SynchronousQueue$TransferStack)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359)
at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:942)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

"ActiveMQ BrokerService[localhost] Task-1" daemon prio=8 tid=0x01170600 nid=145 
lwp_id=2776351 waiting on condition [0x3210]
   java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x3aac0b80> (a 
java.util.concurrent.SynchronousQueue$TransferStack)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359)
at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:942)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

"ActiveMQ Transport Server: mqtt+nio://localhost:0?" daemon prio=8 
tid=0x01344c00 nid=144 lwp_id=2776350 runnable [0x3228]
   java.lang.Thread.State: RUNNABLE
at sun.nio.ch.PollArrayWrapper.poll0(Native Method)
at sun.nio.ch.PollArrayWrapper.poll(PollArrayWrapper.java:187)
at sun.nio.ch.PollSelectorImpl.doSelect(PollSelectorImpl.java:73)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
- locked <0x3aac13d0> (a sun.nio.ch.Util$2)
- locked <0x3aac13c0> (a java.util.Collections$UnmodifiableSet)
- locked <0x3aac1008> (a sun.nio.ch.PollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
at sun.nio.ch.ServerSocketAdaptor.accept(ServerSocketAdaptor.java:121)
- locked <0x3aac1260> (a java.lang.Object)
at 
org.apache.activemq.transport.tcp.TcpTransportServer.run(TcpTransportServer.java:301)
at java.lang.Thread.run(Thread.java:744)

"ActiveMQ Transport Server Thread Handler: mqtt+nio://localhost:0?" daemon 
prio=8 tid=0x012ffa00 nid=143 lwp_id=2776349 waiting on condition [0x324c]
   java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x3aac8368> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
at 
java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.jav