[jira] [Commented] (AMQ-4712) MQTT unit tests fail

2013-10-08 Thread JIRA 

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

Jean-Baptiste Onofré commented on AMQ-4712:
---

Thanks for the update. Let me try again.

I keep you posted.

> MQTT unit tests fail
> 
>
> Key: AMQ-4712
> URL: https://issues.apache.org/jira/browse/AMQ-4712
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT, Test Cases
>Affects Versions: 5.9.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Rob Davies
> Fix For: 5.9.0
>
>
> Running org.apache.activemq.transport.mqtt.MQTTNioTest
> Tests run: 19, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 160.808 sec 
> <<< FAILURE!
> Running org.apache.activemq.transport.mqtt.MQTTSSLTest
> Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 161.426 sec 
> <<< FAILURE!
> Running org.apache.activemq.transport.mqtt.MQTTTest
> Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 158.184 sec 
> <<< FAILURE!
> Results :
> Tests in error:
>   testPingOnMQTTNIO(org.apache.activemq.transport.mqtt.MQTTNioTest): The 
> client id MUST be configured when clean session is set to false
>   
> testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTNioTest):
>  String index out of range: -6
>   
> testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTSSLTest):
>  Command from server contained an invalid message id: 1
>   
> testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTTest):
>  Command from server contained an invalid message id: 1
> Tests run: 55, Failures: 0, Errors: 4, Skipped: 0



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4712) MQTT unit tests fail

2013-10-08 Thread Christian Posta (JIRA) 

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

Christian Posta commented on AMQ-4712:
--

Hey JB, can you re-run the tests? I think *at least one (the first one)* of 
them should be fixed now.

When I run the tests, I can only get the one Claus posted about to fail. Let us 
know what you find.

> MQTT unit tests fail
> 
>
> Key: AMQ-4712
> URL: https://issues.apache.org/jira/browse/AMQ-4712
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT, Test Cases
>Affects Versions: 5.9.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Rob Davies
> Fix For: 5.9.0
>
>
> Running org.apache.activemq.transport.mqtt.MQTTNioTest
> Tests run: 19, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 160.808 sec 
> <<< FAILURE!
> Running org.apache.activemq.transport.mqtt.MQTTSSLTest
> Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 161.426 sec 
> <<< FAILURE!
> Running org.apache.activemq.transport.mqtt.MQTTTest
> Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 158.184 sec 
> <<< FAILURE!
> Results :
> Tests in error:
>   testPingOnMQTTNIO(org.apache.activemq.transport.mqtt.MQTTNioTest): The 
> client id MUST be configured when clean session is set to false
>   
> testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTNioTest):
>  String index out of range: -6
>   
> testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTSSLTest):
>  Command from server contained an invalid message id: 1
>   
> testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTTest):
>  Command from server contained an invalid message id: 1
> Tests run: 55, Failures: 0, Errors: 4, Skipped: 0



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Build failed in Jenkins: ActiveMQ #1386

2013-10-08 Thread Apache Jenkins Server 
See 

Changes:

[claus.ibsen] Polished instructions in webconsole readme

[hiram] Implementing AMQ-4788 - Adding tests for the ZooKeeper variant of the 
partition broker plugin.

[hiram] Tweaking the activemq osgi jar so that it does not re-bundle the 
leveldbjni lib since the pure java version works fine.

[hiram] Make snappy lib an optional osgi dependency.

[hiram] Make sure we keep the resource files embedded in the bundle.

[hiram] Include the partition module in the assembly.

[gtully] https://issues.apache.org/jira/browse/AMQ-4791 - fix and test. removed 
the delay but left the warn if dispatch ocurrs before interruption processing 
is complete. Problem was a race between consumer close and sessions copy on 
write dispatchers list

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

--
[...truncated 1434 lines...]
org.apache.maven.plugin.MojoExecutionException: Unable to read repository xml: 
file:/home/jenkins/jenkins-slave/maven-repositories/0/repository.xml
at 
org.apache.felix.obrplugin.ObrUpdate.parseRepositoryXml(ObrUpdate.java:324)
at org.apache.felix.obrplugin.ObrInstall.execute(ObrInstall.java:141)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at 
org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:178)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:130)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:67)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
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.xmlpull.v1.XmlPullParserException: unexpected type 
(position:END_DOCUMENT null@3:1 in java.io.InputStreamReader@1b1f23b) 
at org.kxml2.io.KXmlParser.exception(Unknown Source)
at org.kxml2.io.KXmlParser.nextTag(Unknown Source)
at 
org.apache.felix.bundlerepository.impl.PullParser.parseRepository(PullParser.java:43)
at 
org.apache.felix.bundlerepository.impl.DataModelHelperImpl.repository(DataModelHelperImpl.java:147)
at 
org.apache.felix.bundlerepository.impl.DataModelHelperImpl.repository(DataModelHelperImpl.java:118)
at 
org.apache.felix.obrplugin.ObrUpdate.parseRepositoryXml(ObrUpdate.java:316)
... 34 more
[01:11:29] Oct 9, 2013 1:11:29 AM 
org.apache.maven.cli.event.ExecutionEventLogger projectSkipped
INFO: 
Oct 9, 2013 1:11:29 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO:

Build failed in Jenkins: ActiveMQ » ActiveMQ :: KahaDB Store #1386

2013-10-08 Thread Apache Jenkins Server 
See 


--
[00:57:45] Oct 9, 2013 12:57:50 AM 
org.apache.maven.cli.event.ExecutionEventLogger projectStarted
INFO: 
Oct 9, 2013 12:57:50 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: 
Oct 9, 2013 12:57:50 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: Building ActiveMQ :: KahaDB Store 5.9-SNAPSHOT
Oct 9, 2013 12:57:50 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: 
Oct 9, 2013 12:57:51 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 12:57:51 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-clean-plugin:2.5:clean (default-clean) @ activemq-kahadb-store 
---
[INFO] Deleting 

Oct 9, 2013 12:57:53 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 12:57:53 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-kahadb-store 
---
Oct 9, 2013 12:57:53 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 12:57:53 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-consolets-plugin:1.30:install (default) @ activemq-kahadb-store 
---
Oct 9, 2013 12:57:54 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 12:57:54 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-kahadb-store ---
Oct 9, 2013 12:57:54 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 12:57:54 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- activemq-protobuf:1.1:compile (default) @ activemq-kahadb-store ---
[INFO] Compiling: 

Oct 9, 2013 12:57:54 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 12:57:54 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-remote-resources-plugin:1.3:process (default) @ 
activemq-kahadb-store ---
Oct 9, 2013 12:57:54 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 12:57:54 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-kahadb-store ---
[00:57:54] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
Oct 9, 2013 12:57:54 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 12:57:54 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
activemq-kahadb-store ---
[INFO] Compiling 75 source files to 

Oct 9, 2013 12:57:55 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 12:57:55 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
activemq-kahadb-store ---
[00:57:55] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 3 resources
Oct 9, 2013 12:57:56 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 12:57:56 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
activemq-kahadb-store ---
[INFO] Compiling 11 source files to 

Oct 9, 2013 12:57:56 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 12:57:56 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-surefire-plugin:2.10:test (default-test) @ 
activemq-kahadb-store ---
[INFO] Surefire report directory: 

[00:57:56] 
[00:57:56] ---
[00:57:56]  T E S T S
[00:57:56] -

Build failed in Jenkins: ActiveMQ » ActiveMQ :: MQTT Protocol #1386

2013-10-08 Thread Apache Jenkins Server 
See 


--
Oct 9, 2013 1:02:29 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: 
Oct 9, 2013 1:02:29 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: 
Oct 9, 2013 1:02:29 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: Skipping ActiveMQ :: STOMP Protocol
Oct 9, 2013 1:02:29 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: This project has been banned from the build due to previous failures.
Oct 9, 2013 1:02:29 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: 
[01:02:29] Oct 9, 2013 1:02:33 AM 
org.apache.maven.cli.event.ExecutionEventLogger projectStarted
INFO: 
Oct 9, 2013 1:02:33 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: 
Oct 9, 2013 1:02:33 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: Building ActiveMQ :: MQTT Protocol 5.9-SNAPSHOT
Oct 9, 2013 1:02:33 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: 
Oct 9, 2013 1:02:34 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 1:02:34 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-clean-plugin:2.5:clean (default-clean) @ activemq-mqtt ---
[INFO] Deleting 

Oct 9, 2013 1:02:35 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 1:02:35 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-mqtt ---
Oct 9, 2013 1:02:36 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 1:02:36 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-consolets-plugin:1.30:install (default) @ activemq-mqtt ---
Oct 9, 2013 1:02:36 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 1:02:36 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-mqtt ---
Oct 9, 2013 1:02:36 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 1:02:36 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- activemq-protobuf:1.1:compile (default) @ activemq-mqtt ---
[WARNING] No proto files found in directory: 

Oct 9, 2013 1:02:36 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 1:02:36 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-remote-resources-plugin:1.3:process (default) @ activemq-mqtt 
---
Oct 9, 2013 1:02:36 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 1:02:36 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-mqtt ---
[01:02:36] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 5 resources
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
Oct 9, 2013 1:02:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 1:02:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-compiler-plugin:2.5.1:compile (default-compile) @ activemq-mqtt 
---
[INFO] Compiling 16 source files to 

Oct 9, 2013 1:02:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 1:02:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
activemq-mqtt ---
[01:02:37] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] Copying 3 resources
Oct 9, 2013 1:02:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 9, 2013 1:02:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
activemq-mqtt ---
[INFO] Compiling 6 sour

[jira] [Commented] (AMQ-4753) amqp+nio+ssl: infinite loop during inital handshake with SSL + client certs

2013-10-08 Thread Timothy Bish (JIRA) 

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

Timothy Bish commented on AMQ-4753:
---

Submitted a patch to the AmqpNIOSSLTransport to get things working a bit 
better.  There's still no real tests there for this one so wouldn't count on 
this being a complete fix but it gets past the initial protocol discriminator 
phase and starts passing down proper Buffers to the protocol converter.  

> amqp+nio+ssl: infinite loop during inital handshake with SSL + client certs
> ---
>
> Key: AMQ-4753
> URL: https://issues.apache.org/jira/browse/AMQ-4753
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.8.0
> Environment: java version "1.7.0_25"
> Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
>Reporter: Graham Leggett
>  Labels: amqp, nio, ssl
> Attachments: AMQ-4753.patch
>
>
> Start with a client application running qpid v0.24 connecting to activemq 
> v5.8.0 server over amqps. Configure the activemq server to use client SSL 
> certificates for authentication.
> {code}
> 
>   uri="amqp+ssl://0.0.0.0:5672?maximumConnections=1000&wireformat.maxFrameSize=104857600&transport.transformer=jms&needClientAuth=true"/>
> {code}
> This works and messages successfully flow from server to client. Qpid however 
> has a fatal bug where it cannot recover from broken connections, and so 
> attempt to switch to the activemq amqp client to work around this problem.
> On the client, we initialise activemq-amqp with the following parameters:
> {code}
> 
>value="org.apache.activemq.jndi.ActiveMQInitialContextFactory" />
>   
>   
> 
>value="amqp+nio+ssl://amqp.${env:SERVER_ENV}.example.com:5672" />
> {code}
> With activemq-amqp in place instead of qpid, the client starts up, but no 
> messages are processed. Instead, it is found that the aqmp+nio+ssl provider 
> is spinning the CPU at 100% part of the way through the SSL handshake process.
> A thread dump of the spinning thread is as follows:
> {code}
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.25-b01 mixed mode):
> "localhost-startStop-1" daemon prio=10 tid=0x0179b800 nid=0x638e 
> runnable [0x7fd1fd84a000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:225)
> at sun.nio.ch.IOUtil.read(IOUtil.java:198)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:375)
> - locked <0xc4da50e8> (a java.lang.Object)
> at 
> org.apache.activemq.transport.nio.NIOSSLTransport.secureRead(NIOSSLTransport.java:285)
> at 
> org.apache.activemq.transport.nio.NIOSSLTransport.doHandshake(NIOSSLTransport.java:333)
> at 
> org.apache.activemq.transport.nio.NIOSSLTransport.initializeStreams(NIOSSLTransport.java:128)
> at 
> org.apache.activemq.transport.amqp.AmqpNioSslTransport.initializeStreams(AmqpNioSslTransport.java:43)
> at 
> org.apache.activemq.transport.tcp.TcpTransport.connect(TcpTransport.java:514)
> at 
> org.apache.activemq.transport.nio.NIOTransport.doStart(NIOTransport.java:156)
> at 
> org.apache.activemq.transport.nio.NIOSSLTransport.doStart(NIOSSLTransport.java:356)
> at 
> org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
> at 
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
> at 
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
> at 
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
> at 
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:273)
> at 
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:238)
> at 
> org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:184)
> ...
> {code}
> If an attempt is made to restart the activemq server, despite the spinning 
> thread on the client the server side disconnection is detected by the client 
> and the following exception is logged and the connection is successfully 
> aborted:
> {code}
> Caused by: java.io.IOException: javax.net.ssl.SSLException: Received 
> close_notify during handshake
> at 
> org.apache.activemq.transport.nio.NIOSSLTransport.initializeStreams(NIOSSLTransport.java:130)
> at 
> org.apache.activemq.transport.amqp.AmqpNioSslTransport.

[jira] [Commented] (AMQ-4753) amqp+nio+ssl: infinite loop during inital handshake with SSL + client certs

2013-10-08 Thread Timothy Bish (JIRA) 

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

Timothy Bish commented on AMQ-4753:
---

>From a brief glance it looks as though the NIOSSL AMQP Transport is not 
>complete, it appears to be passing a raw ByteBuffer onto the protocol 
>converter before processing it into an AMQPHeader so an IllegalStateException 
>is being thrown. 

> amqp+nio+ssl: infinite loop during inital handshake with SSL + client certs
> ---
>
> Key: AMQ-4753
> URL: https://issues.apache.org/jira/browse/AMQ-4753
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.8.0
> Environment: java version "1.7.0_25"
> Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
>Reporter: Graham Leggett
>  Labels: amqp, nio, ssl
> Attachments: AMQ-4753.patch
>
>
> Start with a client application running qpid v0.24 connecting to activemq 
> v5.8.0 server over amqps. Configure the activemq server to use client SSL 
> certificates for authentication.
> {code}
> 
>   uri="amqp+ssl://0.0.0.0:5672?maximumConnections=1000&wireformat.maxFrameSize=104857600&transport.transformer=jms&needClientAuth=true"/>
> {code}
> This works and messages successfully flow from server to client. Qpid however 
> has a fatal bug where it cannot recover from broken connections, and so 
> attempt to switch to the activemq amqp client to work around this problem.
> On the client, we initialise activemq-amqp with the following parameters:
> {code}
> 
>value="org.apache.activemq.jndi.ActiveMQInitialContextFactory" />
>   
>   
> 
>value="amqp+nio+ssl://amqp.${env:SERVER_ENV}.example.com:5672" />
> {code}
> With activemq-amqp in place instead of qpid, the client starts up, but no 
> messages are processed. Instead, it is found that the aqmp+nio+ssl provider 
> is spinning the CPU at 100% part of the way through the SSL handshake process.
> A thread dump of the spinning thread is as follows:
> {code}
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.25-b01 mixed mode):
> "localhost-startStop-1" daemon prio=10 tid=0x0179b800 nid=0x638e 
> runnable [0x7fd1fd84a000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:225)
> at sun.nio.ch.IOUtil.read(IOUtil.java:198)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:375)
> - locked <0xc4da50e8> (a java.lang.Object)
> at 
> org.apache.activemq.transport.nio.NIOSSLTransport.secureRead(NIOSSLTransport.java:285)
> at 
> org.apache.activemq.transport.nio.NIOSSLTransport.doHandshake(NIOSSLTransport.java:333)
> at 
> org.apache.activemq.transport.nio.NIOSSLTransport.initializeStreams(NIOSSLTransport.java:128)
> at 
> org.apache.activemq.transport.amqp.AmqpNioSslTransport.initializeStreams(AmqpNioSslTransport.java:43)
> at 
> org.apache.activemq.transport.tcp.TcpTransport.connect(TcpTransport.java:514)
> at 
> org.apache.activemq.transport.nio.NIOTransport.doStart(NIOTransport.java:156)
> at 
> org.apache.activemq.transport.nio.NIOSSLTransport.doStart(NIOSSLTransport.java:356)
> at 
> org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
> at 
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
> at 
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
> at 
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
> at 
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:273)
> at 
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:238)
> at 
> org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:184)
> ...
> {code}
> If an attempt is made to restart the activemq server, despite the spinning 
> thread on the client the server side disconnection is detected by the client 
> and the following exception is logged and the connection is successfully 
> aborted:
> {code}
> Caused by: java.io.IOException: javax.net.ssl.SSLException: Received 
> close_notify during handshake
> at 
> org.apache.activemq.transport.nio.NIOSSLTransport.initializeStreams(NIOSSLTransport.java:130)
> at 
> org.apache.activemq.transport.amqp.AmqpNioSslTransport.initializeStreams(AmqpNioSslTransport.java:43)
> at

[jira] [Resolved] (AMQ-4791) [org.apache.activemq.ActiveMQConnection] dispatch paused, waiting for outstanding dispatch interruption processing (1) to complete..

2013-10-08 Thread Gary Tully (JIRA) 

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

Gary Tully resolved AMQ-4791.
-

Resolution: Fixed

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

> [org.apache.activemq.ActiveMQConnection] dispatch paused, waiting for 
> outstanding dispatch interruption processing (1) to complete..
> 
>
> Key: AMQ-4791
> URL: https://issues.apache.org/jira/browse/AMQ-4791
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 5.8.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>  Labels: DMLC, RAR, failover
> Fix For: 5.9.0
>
>
> Race condition between consumer close and transport calculation of 
> outstanding interruption processing. Transport thinks there are more 
> responses required before allowing dispatch due to a mis count of active 
> consumers.
> NOTE: This is issue was initially reported using the Spring DMLC with the AMQ 
> rar deployed in a J2EE container. However it can be replicated the issue with 
> a simple JMS client creating a new consumer and closing the consumer for 
> every call to consumer.receive(1000).
> The client AMQ connection appears to stop dispatching messages to the 
> consumer and continuously logs the following message
> WARN  [org.apache.activemq.ActiveMQConnection] (ActiveMQ Transport: 
> tcp://localhost/127.0.0.1:61616@51487) dispatch paused, waiting for 
> outstanding dispatch interruption processing (1) to complete..
> Thread appears to remain in following state {code}
> - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may 
> be imprecise)
>  - java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object, long) 
> @bci=20, line=226 (Compiled frame)
>  - 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(int,
>  long) @bci=122, line=1033 (Interpreted frame)
>  - 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(int,
>  long) @bci=25, line=1326 (Compiled frame)
>  - java.util.concurrent.CountDownLatch.await(long, 
> java.util.concurrent.TimeUnit) @bci=10, line=282 (Compiled frame)
>  - 
> org.apache.activemq.ActiveMQConnection.waitForTransportInterruptionProcessingToComplete()
>  @bci=82, line=2455 (Compiled frame)
>  - 
> org.apache.activemq.ActiveMQConnection$3.processMessageDispatch(org.apache.activemq.command.MessageDispatch)
>  @bci=4, line=1841 (Compiled frame)
>  - 
> org.apache.activemq.command.MessageDispatch.visit(org.apache.activemq.state.CommandVisitor)
>  @bci=2, line=113 (Compiled frame)
>  - org.apache.activemq.ActiveMQConnection.onCommand(java.lang.Object) 
> @bci=29, line=1838 (Compiled frame)
>  - 
> org.apache.activemq.transport.ResponseCorrelator.onCommand(java.lang.Object) 
> @bci=172, line=116 (Compiled frame)
>  - org.apache.activemq.transport.MutexTransport.onCommand(java.lang.Object) 
> @bci=52, line=50 (Compiled frame)
>  - 
> org.apache.activemq.transport.failover.FailoverTransport$3.onCommand(java.lang.Object)
>  @bci=148, line=203 (Compiled frame)
>  - 
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(java.lang.Object)
>  @bci=29, line=113 (Compiled frame)
>  - 
> org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(java.lang.Object)
>  @bci=156, line=288 (Compiled frame)
>  - org.apache.activemq.transport.TransportSupport.doConsume(java.lang.Object) 
> @bci=16, line=83 (Compiled frame)
>  - org.apache.activemq.transport.tcp.TcpTransport.doRun() @bci=7, line=214 
> (Compiled frame)
>  - org.apache.activemq.transport.tcp.TcpTransport.run() @bci=47, line=196 
> (Compiled frame)
>  - java.lang.Thread.run() @bci=11, line=722 (Interpreted frame) {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (AMQ-4791) [org.apache.activemq.ActiveMQConnection] dispatch paused, waiting for outstanding dispatch interruption processing (1) to complete..

2013-10-08 Thread Gary Tully (JIRA) 
Gary Tully created AMQ-4791:
---

 Summary: [org.apache.activemq.ActiveMQConnection] dispatch paused, 
waiting for outstanding dispatch interruption processing (1) to complete..
 Key: AMQ-4791
 URL: https://issues.apache.org/jira/browse/AMQ-4791
 Project: ActiveMQ
  Issue Type: Bug
  Components: Transport
Affects Versions: 5.8.0
Reporter: Gary Tully
Assignee: Gary Tully
 Fix For: 5.9.0


Race condition between consumer close and transport calculation of outstanding 
interruption processing. Transport thinks there are more responses required 
before allowing dispatch due to a mis count of active consumers.

NOTE: This is issue was initially reported using the Spring DMLC with the AMQ 
rar deployed in a J2EE container. However it can be replicated the issue with a 
simple JMS client creating a new consumer and closing the consumer for every 
call to consumer.receive(1000).

The client AMQ connection appears to stop dispatching messages to the consumer 
and continuously logs the following message

WARN  [org.apache.activemq.ActiveMQConnection] (ActiveMQ Transport: 
tcp://localhost/127.0.0.1:61616@51487) dispatch paused, waiting for outstanding 
dispatch interruption processing (1) to complete..
Thread appears to remain in following state {code}

- sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may 
be imprecise)
 - java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object, long) 
@bci=20, line=226 (Compiled frame)
 - 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(int, 
long) @bci=122, line=1033 (Interpreted frame)
 - 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(int,
 long) @bci=25, line=1326 (Compiled frame)
 - java.util.concurrent.CountDownLatch.await(long, 
java.util.concurrent.TimeUnit) @bci=10, line=282 (Compiled frame)
 - 
org.apache.activemq.ActiveMQConnection.waitForTransportInterruptionProcessingToComplete()
 @bci=82, line=2455 (Compiled frame)
 - 
org.apache.activemq.ActiveMQConnection$3.processMessageDispatch(org.apache.activemq.command.MessageDispatch)
 @bci=4, line=1841 (Compiled frame)
 - 
org.apache.activemq.command.MessageDispatch.visit(org.apache.activemq.state.CommandVisitor)
 @bci=2, line=113 (Compiled frame)
 - org.apache.activemq.ActiveMQConnection.onCommand(java.lang.Object) @bci=29, 
line=1838 (Compiled frame)
 - org.apache.activemq.transport.ResponseCorrelator.onCommand(java.lang.Object) 
@bci=172, line=116 (Compiled frame)
 - org.apache.activemq.transport.MutexTransport.onCommand(java.lang.Object) 
@bci=52, line=50 (Compiled frame)
 - 
org.apache.activemq.transport.failover.FailoverTransport$3.onCommand(java.lang.Object)
 @bci=148, line=203 (Compiled frame)
 - 
org.apache.activemq.transport.WireFormatNegotiator.onCommand(java.lang.Object) 
@bci=29, line=113 (Compiled frame)
 - 
org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(java.lang.Object)
 @bci=156, line=288 (Compiled frame)
 - org.apache.activemq.transport.TransportSupport.doConsume(java.lang.Object) 
@bci=16, line=83 (Compiled frame)
 - org.apache.activemq.transport.tcp.TcpTransport.doRun() @bci=7, line=214 
(Compiled frame)
 - org.apache.activemq.transport.tcp.TcpTransport.run() @bci=47, line=196 
(Compiled frame)
 - java.lang.Thread.run() @bci=11, line=722 (Interpreted frame) {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4789) Slow leak: org.apache.activemq.broker.jmx.ManagedTransportConnection

2013-10-08 Thread Graham Leggett (JIRA) 

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

Graham Leggett commented on AMQ-4789:
-

Obviously if we could reproduce it easily it would help, but we're seeing this 
manifest itself on a live system after running for many hours, so no we don't 
have a test case.

To explain the losing state, the leak eventually causes an out of memory 
condition, which causes garbage collection to take forever, in turn triggering 
the "kill -9" behaviour of the java service wrapper, in turn causing the loss 
of data.

I have a 2.6GB heap file and can run various reports on it to show the objects 
being leaked.


> Slow leak: org.apache.activemq.broker.jmx.ManagedTransportConnection
> 
>
> Key: AMQ-4789
> URL: https://issues.apache.org/jira/browse/AMQ-4789
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMX
>Affects Versions: 5.8.0
> Environment: INFO   | jvm 1| 2013/10/07 10:17:29 | Java Runtime: 
> Sun Microsystems Inc. 1.6.0_24 
> /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre
> INFO   | jvm 1| 2013/10/07 10:17:29 |   Heap sizes: current=83008k  
> free=78872k  max=4190080k
>Reporter: Graham Leggett
>  Labels: leak
> Attachments: activemq-leak-detail.tiff, activemq-leak.tiff
>
>
> When activemq is configured with an amqp transport and SSL, and where clients 
> make short lived polled connections to the queue, a slow leak exists that 
> kills the server within about 12 hours or so (for us) with the following:
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> Obtaining a heap dump in this state reveals that about 3/4 of our heap is 
> used by the org.apache.activemq.broker.jmx.ManagedTransportConnection as per 
> the attached screenshots.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[REPORT] Apache ActiveMQ - October 2013

2013-10-08 Thread Hiram Chirino 
TLP Description:

Apache ActiveMQ is a popular and powerful open source messaging
server. Apache ActiveMQ is fast, supports many Cross Language Clients
and Protocols, comes with easy to use Enterprise Integration Patterns
and many advanced features while fully supporting JMS 1.1 and J2EE
1.4.

Community:

 * The development and user lists continue to stay active.
 * Most SCM roots in ActiveMQ have switched from SVN to Git.

Development:

 * It's been a busy quarter preparing for the The ActiveMQ 5.9
release.  It should be done soon!

Trademark / Branding Status:

 * Sub-projects need to be reviewed to make sure they are also
compliant /w TM policies
 * Documentation and readme files will also be reviewed for compliance

Releases:

* ActiveMQ-CPP v3.8.1 - Sep 19th 2013
* ActiveMQ-CPP v3.8.0 - Sep 6th 2013


-- 
Hiram Chirino

[jira] [Commented] (AMQ-4789) Slow leak: org.apache.activemq.broker.jmx.ManagedTransportConnection

2013-10-08 Thread Gary Tully (JIRA) 

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

Gary Tully commented on AMQ-4789:
-

can you provide a simple test case so we can easily reproduce? 

losing state of processed messages seems to be unrelated to a memory leak. 
There is something else going on here.

A junit test case is ideal, find some inspiration at: 
https://github.com/apache/activemq/blob/trunk/activemq-amqp/src/test/java/org/apache/activemq/transport/amqp/AmqpSslTest.java

If we can easily reproduce we can easily help :-)


> Slow leak: org.apache.activemq.broker.jmx.ManagedTransportConnection
> 
>
> Key: AMQ-4789
> URL: https://issues.apache.org/jira/browse/AMQ-4789
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMX
>Affects Versions: 5.8.0
> Environment: INFO   | jvm 1| 2013/10/07 10:17:29 | Java Runtime: 
> Sun Microsystems Inc. 1.6.0_24 
> /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre
> INFO   | jvm 1| 2013/10/07 10:17:29 |   Heap sizes: current=83008k  
> free=78872k  max=4190080k
>Reporter: Graham Leggett
>  Labels: leak
> Attachments: activemq-leak-detail.tiff, activemq-leak.tiff
>
>
> When activemq is configured with an amqp transport and SSL, and where clients 
> make short lived polled connections to the queue, a slow leak exists that 
> kills the server within about 12 hours or so (for us) with the following:
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> Obtaining a heap dump in this state reveals that about 3/4 of our heap is 
> used by the org.apache.activemq.broker.jmx.ManagedTransportConnection as per 
> the attached screenshots.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Closed] (AMQ-4790) Avoid thread creation storm after machine suspend/resume

2013-10-08 Thread Timothy Bish (JIRA) 

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

Timothy Bish closed AMQ-4790.
-

Resolution: Not A Problem

This sort of thing has been fixed in more recent releases.  

> Avoid thread creation storm after machine suspend/resume
> 
>
> Key: AMQ-4790
> URL: https://issues.apache.org/jira/browse/AMQ-4790
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.5.1
> Environment: ServiceMix 4.4.2
>Reporter: metatech
>Priority: Minor
> Attachments: activemq_jdbc_no_thread_storm.patch
>
>
> My ActiveMQ broker is running and I suspend my PC.  When I resume the machine 
> the next day or (much worse) after a week-end, my PC is busy at 100% CPU for 
> a few minutes.  Because many threads are busy in parallel, the PC is 
> completely unresponsive and the even the mouse cursor can hardly move.
> I had noticed that it only happens when my ServiceMix is started, and when 
> the embedded ActiveMQ broker is configured with a JDBC persistence adapter.
> After investigating in the code, I found out that the "lock keep alive" 
> feature uses the "scheduleWithFixedDelay" to update a DB lock every 30 
> seconds.  When the PC is resumed, this generates a "backlog" of thousands of 
> calls.  It is better to use "scheduleWithFixedDelay" instead, which waits 
> until the previous calls has finished before firing a new one.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4789) Slow leak: org.apache.activemq.broker.jmx.ManagedTransportConnection

2013-10-08 Thread Graham Leggett (JIRA) 

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

Graham Leggett commented on AMQ-4789:
-

5.9-SNAPSHOT can only be used with difficulty in our case.

We tried to switch the backend database from kahaDB to levelDB (as kahaDB 
appeared as one of the objects that was leaking the above objects) but no 
difference.

We cannot keep v5.8.0 up and running for more than a few hours at a time, and 
each time activemq hits the wall it loses all trace of messages processed, 
leaving us at an earlier state being forced to process messages again from 
scratch. Activemq is fatally broken in its current form.


> Slow leak: org.apache.activemq.broker.jmx.ManagedTransportConnection
> 
>
> Key: AMQ-4789
> URL: https://issues.apache.org/jira/browse/AMQ-4789
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMX
>Affects Versions: 5.8.0
> Environment: INFO   | jvm 1| 2013/10/07 10:17:29 | Java Runtime: 
> Sun Microsystems Inc. 1.6.0_24 
> /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre
> INFO   | jvm 1| 2013/10/07 10:17:29 |   Heap sizes: current=83008k  
> free=78872k  max=4190080k
>Reporter: Graham Leggett
>  Labels: leak
> Attachments: activemq-leak-detail.tiff, activemq-leak.tiff
>
>
> When activemq is configured with an amqp transport and SSL, and where clients 
> make short lived polled connections to the queue, a slow leak exists that 
> kills the server within about 12 hours or so (for us) with the following:
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> Obtaining a heap dump in this state reveals that about 3/4 of our heap is 
> used by the org.apache.activemq.broker.jmx.ManagedTransportConnection as per 
> the attached screenshots.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (AMQNET-447) Individual Acknowledgement seems not working in NMS

2013-10-08 Thread Timothy Bish (JIRA) 

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

Timothy Bish resolved AMQNET-447.
-

Resolution: Fixed
  Assignee: Timothy Bish  (was: Jim Gomes)

Fix applied on trunk and 1.6.x.  Throws NMSException when a durable consumer is 
being created on a session that is in Individual Ack mode.

> Individual Acknowledgement seems not working in NMS
> ---
>
> Key: AMQNET-447
> URL: https://issues.apache.org/jira/browse/AMQNET-447
> Project: ActiveMQ .Net
>  Issue Type: Test
>  Components: ActiveMQ, NMS
>Affects Versions: 1.6.0
> Environment: windows xp sp2 
> visual studio 2010 sp1
> .NET 4.0 
> JavaSE Runtime Envrionment build 1.7.0_17-b02
> ActiveMQ 5.8.0 running under RedHat 6.3
> NMS 1.6.0
>Reporter: HellKnight
>Assignee: Timothy Bish
>  Labels: test
> Fix For: 1.6.1
>
> Attachments: AMQDurableSub.rar
>
>
> I create a simple unit test to show my problem in VS2010 , coded in c#.
> The idea of my test is as follow :
> 1. Send some message to the broker by web console.
> 2. Start a durable subscriber , and receive the test messages.Then call 
> message.acknowledge() on the last message received.
> 3. Close the connection of the durable subscriber and start listening again.
> the session is using individual ack mode. Since the individual ack mode 
> acknowledges each message individually, I would expect that only the last 
> message is acked , so after restart the subscriber, the test messages except 
> the last one should be received again. However, the fact is every message is 
> acked and 
> none test message is received the second time. 
> Generally speaking, My unit test compare the number of message received 
> before ack the last message and after ack the last message. What I am 
> expecting is the second time I will receive one less message but the fact is 
> I receive 0 message.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQNET-447) Individual Acknowledgement seems not working in NMS

2013-10-08 Thread Timothy Bish (JIRA) 

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

Timothy Bish updated AMQNET-447:


Fix Version/s: 1.6.1

> Individual Acknowledgement seems not working in NMS
> ---
>
> Key: AMQNET-447
> URL: https://issues.apache.org/jira/browse/AMQNET-447
> Project: ActiveMQ .Net
>  Issue Type: Test
>  Components: ActiveMQ, NMS
>Affects Versions: 1.6.0
> Environment: windows xp sp2 
> visual studio 2010 sp1
> .NET 4.0 
> JavaSE Runtime Envrionment build 1.7.0_17-b02
> ActiveMQ 5.8.0 running under RedHat 6.3
> NMS 1.6.0
>Reporter: HellKnight
>Assignee: Jim Gomes
>  Labels: test
> Fix For: 1.6.1
>
> Attachments: AMQDurableSub.rar
>
>
> I create a simple unit test to show my problem in VS2010 , coded in c#.
> The idea of my test is as follow :
> 1. Send some message to the broker by web console.
> 2. Start a durable subscriber , and receive the test messages.Then call 
> message.acknowledge() on the last message received.
> 3. Close the connection of the durable subscriber and start listening again.
> the session is using individual ack mode. Since the individual ack mode 
> acknowledges each message individually, I would expect that only the last 
> message is acked , so after restart the subscriber, the test messages except 
> the last one should be received again. However, the fact is every message is 
> acked and 
> none test message is received the second time. 
> Generally speaking, My unit test compare the number of message received 
> before ack the last message and after ack the last message. What I am 
> expecting is the second time I will receive one less message but the fact is 
> I receive 0 message.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQNET-447) Individual Acknowledgement seems not working in NMS

2013-10-08 Thread Timothy Bish (JIRA) 

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

Timothy Bish commented on AMQNET-447:
-

This is not really a bug, its the result of durable subscribers not being 
compatible with Individual Acknowledge mode in ActiveMQ.  I've updated the 
source to throw an NMSException when you try to do this so that you aren't 
tricked into thinking it will work, the JMS and CMS clients already do this.  

> Individual Acknowledgement seems not working in NMS
> ---
>
> Key: AMQNET-447
> URL: https://issues.apache.org/jira/browse/AMQNET-447
> Project: ActiveMQ .Net
>  Issue Type: Test
>  Components: ActiveMQ, NMS
>Affects Versions: 1.6.0
> Environment: windows xp sp2 
> visual studio 2010 sp1
> .NET 4.0 
> JavaSE Runtime Envrionment build 1.7.0_17-b02
> ActiveMQ 5.8.0 running under RedHat 6.3
> NMS 1.6.0
>Reporter: HellKnight
>Assignee: Jim Gomes
>  Labels: test
> Attachments: AMQDurableSub.rar
>
>
> I create a simple unit test to show my problem in VS2010 , coded in c#.
> The idea of my test is as follow :
> 1. Send some message to the broker by web console.
> 2. Start a durable subscriber , and receive the test messages.Then call 
> message.acknowledge() on the last message received.
> 3. Close the connection of the durable subscriber and start listening again.
> the session is using individual ack mode. Since the individual ack mode 
> acknowledges each message individually, I would expect that only the last 
> message is acked , so after restart the subscriber, the test messages except 
> the last one should be received again. However, the fact is every message is 
> acked and 
> none test message is received the second time. 
> Generally speaking, My unit test compare the number of message received 
> before ack the last message and after ack the last message. What I am 
> expecting is the second time I will receive one less message but the fact is 
> I receive 0 message.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (AMQNET-446) Add an HTTP based discovery agent to the discovery transport feature.

2013-10-08 Thread Timothy Bish (JIRA) 

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

Timothy Bish resolved AMQNET-446.
-

Resolution: Fixed

Fixed on trunk and applied to 1.6.x branches

> Add an HTTP based discovery agent to the discovery transport feature.
> -
>
> Key: AMQNET-446
> URL: https://issues.apache.org/jira/browse/AMQNET-446
> Project: ActiveMQ .Net
>  Issue Type: Improvement
>  Components: ActiveMQ
>Affects Versions: 1.6.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 1.6.1
>
>




--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: [DISCUCSS] - Apache Camel 5.9 release

2013-10-08 Thread Claus Ibsen 
Hi

The web consoles is looking good. The login procedure is in place, and
there is details in the readme how to enable/disable that and how to
configure accounts.

And just noticed that Hiram fixed that leveldb jndi on the activemq
osgi features file that Jean have requested. So we use the java
leveldb driver by default now.
So that should be sorted as well.


There is 3 tickets open which has fix version 5.9.
https://issues.apache.org/jira/issues/?jql=project+%3D+AMQ+AND+fixVersion+%3D+%225.9.0%22+AND+resolution+%3D+Unresolved





-- 
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

[jira] [Commented] (AMQ-796) Client may shtudown when failover connection is reconnecting. We need to maintain at least 1 non-daemon thread alive.

2013-10-08 Thread John Bing (JIRA) 

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

John Bing commented on AMQ-796:
---

This is really very strange since the creation time for this issue is 2006. Is 
it really this tough to make the relevant thread non-daemon?

> Client may shtudown when failover connection is reconnecting.  We need to 
> maintain at least 1 non-daemon thread alive.
> --
>
> Key: AMQ-796
> URL: https://issues.apache.org/jira/browse/AMQ-796
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 4.0, 5.3.0
>Reporter: Hiram Chirino
>Assignee: Rob Davies
> Fix For: 5.6.0, 4.0.3
>
> Attachments: AMQ-796.cmd, jstack_amq_5.6.0, jstack_v5.8.0
>
>
> Dejan Reported on the User lists:
> Hi,
> after some experiments I found that this problem only exists if there are no
> other threads in the application. It seems like connection thread dies
> before it manages to reconnect. By starting another thread in the
> application, it succeeds to recover from master failure and reconnect to the
> slave broker. So I have a workaround for now, but it would be nice to make
> this work even for simple (single-threaded) clients.
> Regards,
> Dejan



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-796) Client may shtudown when failover connection is reconnecting. We need to maintain at least 1 non-daemon thread alive.

2013-10-08 Thread Bhanu (JIRA) 

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

Bhanu updated AMQ-796:
--

Attachment: jstack_v5.8.0

Attaching the jstack output for v5.8. The only non-daemon thread is the main 
thread which I stopped from exiting only for the purpose of taking a jstack 
snapshot.

> Client may shtudown when failover connection is reconnecting.  We need to 
> maintain at least 1 non-daemon thread alive.
> --
>
> Key: AMQ-796
> URL: https://issues.apache.org/jira/browse/AMQ-796
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 4.0, 5.3.0
>Reporter: Hiram Chirino
>Assignee: Rob Davies
> Fix For: 5.6.0, 4.0.3
>
> Attachments: AMQ-796.cmd, jstack_amq_5.6.0, jstack_v5.8.0
>
>
> Dejan Reported on the User lists:
> Hi,
> after some experiments I found that this problem only exists if there are no
> other threads in the application. It seems like connection thread dies
> before it manages to reconnect. By starting another thread in the
> application, it succeeds to recover from master failure and reconnect to the
> slave broker. So I have a workaround for now, but it would be nice to make
> this work even for simple (single-threaded) clients.
> Regards,
> Dejan



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-796) Client may shtudown when failover connection is reconnecting. We need to maintain at least 1 non-daemon thread alive.

2013-10-08 Thread Bhanu (JIRA) 

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

Bhanu commented on AMQ-796:
---

Still an issue with ActiveMQ v5.8 !!  Can somebody resolve this please...

> Client may shtudown when failover connection is reconnecting.  We need to 
> maintain at least 1 non-daemon thread alive.
> --
>
> Key: AMQ-796
> URL: https://issues.apache.org/jira/browse/AMQ-796
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 4.0, 5.3.0
>Reporter: Hiram Chirino
>Assignee: Rob Davies
> Fix For: 5.6.0, 4.0.3
>
> Attachments: AMQ-796.cmd, jstack_amq_5.6.0
>
>
> Dejan Reported on the User lists:
> Hi,
> after some experiments I found that this problem only exists if there are no
> other threads in the application. It seems like connection thread dies
> before it manages to reconnect. By starting another thread in the
> application, it succeeds to recover from master failure and reconnect to the
> slave broker. So I have a workaround for now, but it would be nice to make
> this work even for simple (single-threaded) clients.
> Regards,
> Dejan



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4790) Avoid thread creation storm after machine suspend/resume

2013-10-08 Thread metatech (JIRA) 

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

metatech updated AMQ-4790:
--

Attachment: activemq_jdbc_no_thread_storm.patch

> Avoid thread creation storm after machine suspend/resume
> 
>
> Key: AMQ-4790
> URL: https://issues.apache.org/jira/browse/AMQ-4790
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.5.1
> Environment: ServiceMix 4.4.2
>Reporter: metatech
>Priority: Minor
> Attachments: activemq_jdbc_no_thread_storm.patch
>
>
> My ActiveMQ broker is running and I suspend my PC.  When I resume the machine 
> the next day or (much worse) after a week-end, my PC is busy at 100% CPU for 
> a few minutes.  Because many threads are busy in parallel, the PC is 
> completely unresponsive and the even the mouse cursor can hardly move.
> I had noticed that it only happens when my ServiceMix is started, and when 
> the embedded ActiveMQ broker is configured with a JDBC persistence adapter.
> After investigating in the code, I found out that the "lock keep alive" 
> feature uses the "scheduleWithFixedDelay" to update a DB lock every 30 
> seconds.  When the PC is resumed, this generates a "backlog" of thousands of 
> calls.  It is better to use "scheduleWithFixedDelay" instead, which waits 
> until the previous calls has finished before firing a new one.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (AMQ-4790) Avoid thread creation storm after machine suspend/resume

2013-10-08 Thread metatech (JIRA) 
metatech created AMQ-4790:
-

 Summary: Avoid thread creation storm after machine suspend/resume
 Key: AMQ-4790
 URL: https://issues.apache.org/jira/browse/AMQ-4790
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.5.1
 Environment: ServiceMix 4.4.2
Reporter: metatech
Priority: Minor


My ActiveMQ broker is running and I suspend my PC.  When I resume the machine 
the next day or (much worse) after a week-end, my PC is busy at 100% CPU for a 
few minutes.  Because many threads are busy in parallel, the PC is completely 
unresponsive and the even the mouse cursor can hardly move.
I had noticed that it only happens when my ServiceMix is started, and when the 
embedded ActiveMQ broker is configured with a JDBC persistence adapter.
After investigating in the code, I found out that the "lock keep alive" feature 
uses the "scheduleWithFixedDelay" to update a DB lock every 30 seconds.  When 
the PC is resumed, this generates a "backlog" of thousands of calls.  It is 
better to use "scheduleWithFixedDelay" instead, which waits until the previous 
calls has finished before firing a new one.




--
This message was sent by Atlassian JIRA
(v6.1#6144)