[jira] [Commented] (AMQ-5977) Init script should provide LSB headers
[
https://issues.apache.org/jira/browse/AMQ-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14904053#comment-14904053
]
ASF GitHub Bot commented on AMQ-5977:
-
GitHub user gzurowski opened a pull request:
https://github.com/apache/activemq/pull/146
AMQ-5977: Add LSB headers to init script
Add LSB headers to init script to fix problems when setting up ActiveMQ
as a daemon with chkconfig on RHEL and clones.
See: https://issues.apache.org/jira/browse/AMQ-5977
Signed-off-by: Gregor Zurowski
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gzurowski/activemq init-lsb-fix
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq/pull/146.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 #146
commit b7a57876102911a2a5cc406e3f85f80b28e9e16c
Author: Gregor Zurowski
Date: 2015-09-23T06:31:00Z
AMQ-5977: Add LSB headers to init script
Add LSB headers to init script to fix problems when setting up ActiveMQ
as a daemon with chkconfig on RHEL and clones.
Signed-off-by: Gregor Zurowski
> Init script should provide LSB headers
> --
>
> Key: AMQ-5977
> URL: https://issues.apache.org/jira/browse/AMQ-5977
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.12.0
>Reporter: Gregor Zurowski
>Priority: Minor
>
> The current init script 'bin/activemq'
> (https://github.com/apache/activemq/blob/master/assembly/src/release/bin/activemq)
> does not provide any LSB headers. Because of this, setting up the service
> using chkconfig on RHEL and clones as described in the documentation (see
> http://activemq.apache.org/unix-shell-script.html) fails with the following
> error message:
> {code}
> $ chkconfig --add activemq
> service activemq does not support chkconfig
> {code}
> Ubuntu systems will print the following warning:
> {code}
> $ update-rc.d activemq defaults
> update-rc.d: warning: /etc/init.d/activemq missing LSB information
> update-rc.d: see
> Adding system startup for /etc/init.d/activemq ...
> [...]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (AMQ-5977) Init script should provide LSB headers
[
https://issues.apache.org/jira/browse/AMQ-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregor Zurowski updated AMQ-5977:
-
Comment: was deleted
(was: Created pull request: https://github.com/apache/activemq/pull/145)
> Init script should provide LSB headers
> --
>
> Key: AMQ-5977
> URL: https://issues.apache.org/jira/browse/AMQ-5977
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.12.0
>Reporter: Gregor Zurowski
>Priority: Minor
>
> The current init script 'bin/activemq'
> (https://github.com/apache/activemq/blob/master/assembly/src/release/bin/activemq)
> does not provide any LSB headers. Because of this, setting up the service
> using chkconfig on RHEL and clones as described in the documentation (see
> http://activemq.apache.org/unix-shell-script.html) fails with the following
> error message:
> {code}
> $ chkconfig --add activemq
> service activemq does not support chkconfig
> {code}
> Ubuntu systems will print the following warning:
> {code}
> $ update-rc.d activemq defaults
> update-rc.d: warning: /etc/init.d/activemq missing LSB information
> update-rc.d: see
> Adding system startup for /etc/init.d/activemq ...
> [...]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5977) Init script should provide LSB headers
[
https://issues.apache.org/jira/browse/AMQ-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14904048#comment-14904048
]
ASF GitHub Bot commented on AMQ-5977:
-
Github user gzurowski closed the pull request at:
https://github.com/apache/activemq/pull/145
> Init script should provide LSB headers
> --
>
> Key: AMQ-5977
> URL: https://issues.apache.org/jira/browse/AMQ-5977
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.12.0
>Reporter: Gregor Zurowski
>Priority: Minor
>
> The current init script 'bin/activemq'
> (https://github.com/apache/activemq/blob/master/assembly/src/release/bin/activemq)
> does not provide any LSB headers. Because of this, setting up the service
> using chkconfig on RHEL and clones as described in the documentation (see
> http://activemq.apache.org/unix-shell-script.html) fails with the following
> error message:
> {code}
> $ chkconfig --add activemq
> service activemq does not support chkconfig
> {code}
> Ubuntu systems will print the following warning:
> {code}
> $ update-rc.d activemq defaults
> update-rc.d: warning: /etc/init.d/activemq missing LSB information
> update-rc.d: see
> Adding system startup for /etc/init.d/activemq ...
> [...]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5961) Deadlock in client blocks all application server threads
[ https://issues.apache.org/jira/browse/AMQ-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14904020#comment-14904020 ] Erik Wramner commented on AMQ-5961: --- Pull request 143 (https://github.com/apache/activemq/pull/143) is open, 141 is closed. As for all threads becoming stuck I don't agree for two reasons. First it might be that the thread that is supposed to reestablish communication is blocked on the locked HashMap. I don't know the code base well enough to easily find out, but I can dig into the stack trace. If that is the case we have a true deadlock and it would help to get rid of the global lock. Second even if afterRollback blocks forever that will kill one thread and one transaction, but without the global lock it may be possible for the other 169 threads to proceed with their work for new transactions (possibly for other queues/topics if the queue/topic is broken). They may also get blocked by other things, but it is possible that they can proceed. That could make the difference between a panic and a planned restart after peak times. By the way, I changed the code again so that it doesn't lock the list when it has been removed from the map. Instead all additions to the list are within the map's lock. That way additions are protected and nothing can modify the list when it has been removed, so it can be processed safely without locks. That gets rid of the possible global lock in isInXATransaction, where the previous version locked the map and then tried to get a lock on the list. > Deadlock in client blocks all application server threads > > > Key: AMQ-5961 > URL: https://issues.apache.org/jira/browse/AMQ-5961 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client, RAR >Affects Versions: 5.11.0, 5.11.1 > Environment: Platform independent >Reporter: Erik Wramner > > When we run JBoss EAP 6.4 with high load using AMQ 6.2 (ActiveMQ 5.11) > everything grinds to a halt after a few hours. We have 170 threads blocked on > the same lock: > "default-threads - 1400" #406720 prio=5 os_prio=0 tid=0x7f1b8402b800 > nid=0xfe2d waiting for monitor entry [0x7f19ccdd5000] >java.lang.Thread.State: BLOCKED (on object monitor) > at > org.apache.activemq.TransactionContext.setXid(TransactionContext.java:729) > - waiting to lock <0x00063ac688b8> (a java.util.HashMap) > at > org.apache.activemq.TransactionContext.end(TransactionContext.java:418) > at > org.apache.activemq.ra.LocalAndXATransaction.end(LocalAndXATransaction.java:98) > at > org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.end(XAResourceWrapperImpl.java:118) > at > com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare(XAResourceRecord.java:208) > at > com.arjuna.ats.arjuna.coordinator.BasicAction.doPrepare(BasicAction.java:2530) > at > com.arjuna.ats.arjuna.coordinator.BasicAction.doPrepare(BasicAction.java:2497) > at > com.arjuna.ats.arjuna.coordinator.BasicAction.prepare(BasicAction.java:2074) > - locked <0x00067461c090> (a > com.arjuna.ats.internal.jta.transaction.arjunacore.AtomicAction) > at > com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1485) > - locked <0x00067461c090> (a > com.arjuna.ats.internal.jta.transaction.arjunacore.AtomicAction) > at > com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > This lock is owned by a thread that is waiting for another lock: > "default-threads - 1381" #404073 prio=5 os_prio=0 tid=0x7f1a6403c000 > nid=0x7d49 waiting on condition [0x7f19d8a91000] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00063ab2a260> (a > java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) > at > java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) > at > org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:66) > at > org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60) > at > org.apache.activemq.ActiveMQCo
[jira] [Closed] (AMQ-5978) ActiveMQ 5.12.0 Spring CustomScopeConfigurer class conflict
[ https://issues.apache.org/jira/browse/AMQ-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Divya Gopalakrishnan closed AMQ-5978. - > ActiveMQ 5.12.0 Spring CustomScopeConfigurer class conflict > --- > > Key: AMQ-5978 > URL: https://issues.apache.org/jira/browse/AMQ-5978 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.12.0 >Reporter: Divya Gopalakrishnan >Assignee: Christopher L. Shannon > Fix For: 5.13.0 > > > CustomScopeConfigurer class poses a conflict in a Spring based application > when there's a dependency on activemq-all (5.12.0) > The spring class packaged inside of activemq-all.jar conflicts with the > application's Spring dependency. The method "addScope(String, Session)" is > NOT found and is causing runtime errors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5978) ActiveMQ 5.12.0 Spring CustomScopeConfigurer class conflict
[ https://issues.apache.org/jira/browse/AMQ-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14903296#comment-14903296 ] Divya Gopalakrishnan edited comment on AMQ-5978 at 9/22/15 7:33 PM: You guys rock! thank you! I was able to avert the issue for 5.12.0 by including individual jars instead of the activemq-all. was (Author: divvu224): You guys rock! thank you! > ActiveMQ 5.12.0 Spring CustomScopeConfigurer class conflict > --- > > Key: AMQ-5978 > URL: https://issues.apache.org/jira/browse/AMQ-5978 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.12.0 >Reporter: Divya Gopalakrishnan >Assignee: Christopher L. Shannon > Fix For: 5.13.0 > > > CustomScopeConfigurer class poses a conflict in a Spring based application > when there's a dependency on activemq-all (5.12.0) > The spring class packaged inside of activemq-all.jar conflicts with the > application's Spring dependency. The method "addScope(String, Session)" is > NOT found and is causing runtime errors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5978) ActiveMQ 5.12.0 Spring CustomScopeConfigurer class conflict
[ https://issues.apache.org/jira/browse/AMQ-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14903296#comment-14903296 ] Divya Gopalakrishnan commented on AMQ-5978: --- You guys rock! thank you! > ActiveMQ 5.12.0 Spring CustomScopeConfigurer class conflict > --- > > Key: AMQ-5978 > URL: https://issues.apache.org/jira/browse/AMQ-5978 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.12.0 >Reporter: Divya Gopalakrishnan >Assignee: Christopher L. Shannon > Fix For: 5.13.0 > > > CustomScopeConfigurer class poses a conflict in a Spring based application > when there's a dependency on activemq-all (5.12.0) > The spring class packaged inside of activemq-all.jar conflicts with the > application's Spring dependency. The method "addScope(String, Session)" is > NOT found and is causing runtime errors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5978) ActiveMQ 5.12.0 Spring CustomScopeConfigurer class conflict
[
https://issues.apache.org/jira/browse/AMQ-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14903247#comment-14903247
]
Christopher L. Shannon edited comment on AMQ-5978 at 9/22/15 7:13 PM:
--
This has already been fixed for 5.13.0. The method {{addScope}} was added in
the Spring Framework in version 4.1.1. The Spring dependency was just updated
to 4.1.7.RELEASE in AMQ-5973, with this commit:
https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=ebf27cb
For 5.12.0 you will have to avoid using the activemq-all jar if you want to use
a newer version of Spring and instead use the exact ActiveMQ jars that you need
which don't include Spring.
was (Author: christopher.l.shannon):
This has already been fixed for 5.13.0. The method {{addScope}} was added in
the Spring Framework in version 4.1.1. The Spring dependency was just updated
to 4.1.7.RELEASE in AMQ-5973, with this commit:
https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=ebf27cb
For 5.12.0 you will have to avoid using the activemq-all jar if you want to use
a newer version of Spring and instead using the exact ActiveMQ jars that you
need which don't include Spring.
> ActiveMQ 5.12.0 Spring CustomScopeConfigurer class conflict
> ---
>
> Key: AMQ-5978
> URL: https://issues.apache.org/jira/browse/AMQ-5978
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.12.0
>Reporter: Divya Gopalakrishnan
>Assignee: Christopher L. Shannon
> Fix For: 5.13.0
>
>
> CustomScopeConfigurer class poses a conflict in a Spring based application
> when there's a dependency on activemq-all (5.12.0)
> The spring class packaged inside of activemq-all.jar conflicts with the
> application's Spring dependency. The method "addScope(String, Session)" is
> NOT found and is causing runtime errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQ-5978) ActiveMQ 5.12.0 Spring CustomScopeConfigurer class conflict
[
https://issues.apache.org/jira/browse/AMQ-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon resolved AMQ-5978.
-
Resolution: Fixed
Assignee: Christopher L. Shannon
Fix Version/s: 5.13.0
This has already been fixed for 5.13.0. The method {{addScope}} was added in
the Spring Framework in version 4.1.1. The Spring dependency was just updated
to 4.1.7.RELEASE in AMQ-5973, with this commit:
https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=ebf27cb
For 5.12.0 you will have to avoid using the activemq-all jar if you want to use
a newer version of Spring and instead using the exact ActiveMQ jars that you
need which don't include Spring.
> ActiveMQ 5.12.0 Spring CustomScopeConfigurer class conflict
> ---
>
> Key: AMQ-5978
> URL: https://issues.apache.org/jira/browse/AMQ-5978
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.12.0
>Reporter: Divya Gopalakrishnan
>Assignee: Christopher L. Shannon
> Fix For: 5.13.0
>
>
> CustomScopeConfigurer class poses a conflict in a Spring based application
> when there's a dependency on activemq-all (5.12.0)
> The spring class packaged inside of activemq-all.jar conflicts with the
> application's Spring dependency. The method "addScope(String, Session)" is
> NOT found and is causing runtime errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-5978) ActiveMQ 5.12.0 Spring CustomScopeConfigurer class conflict
Divya Gopalakrishnan created AMQ-5978: - Summary: ActiveMQ 5.12.0 Spring CustomScopeConfigurer class conflict Key: AMQ-5978 URL: https://issues.apache.org/jira/browse/AMQ-5978 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.12.0 Reporter: Divya Gopalakrishnan CustomScopeConfigurer class poses a conflict in a Spring based application when there's a dependency on activemq-all (5.12.0) The spring class packaged inside of activemq-all.jar conflicts with the application's Spring dependency. The method "addScope(String, Session)" is NOT found and is causing runtime errors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-225) Incomplete Activation Validation
[ https://issues.apache.org/jira/browse/ARTEMIS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14903236#comment-14903236 ] ASF GitHub Bot commented on ARTEMIS-225: Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/173 > Incomplete Activation Validation > > > Key: ARTEMIS-225 > URL: https://issues.apache.org/jira/browse/ARTEMIS-225 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.0.0, 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > When a MDB is deployed with the activation config property > subscriptionDurability set to Durable but without a required clientId > property, it generates NPE in our app server since the RA tries to create a > queue which name is an non-null empty string. > When the Activation validate its spec, it should verify the presence of the > clientId property if the subscriptionDurability is Durable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ARTEMIS-225) Incomplete Activation Validation
[ https://issues.apache.org/jira/browse/ARTEMIS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-225. --- Resolution: Not A Problem Fix Version/s: (was: 1.1.1) (was: 1.2.0) Jeff, clientID==null means a shared subscription. We couldn't replicate any NPEs on Artemis. Maybe it's an issue on your integration code... If this turns out an Artemis issue, please provide us a stack trace on where the NPE is happening and we will avoid it. > Incomplete Activation Validation > > > Key: ARTEMIS-225 > URL: https://issues.apache.org/jira/browse/ARTEMIS-225 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.0.0, 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > When a MDB is deployed with the activation config property > subscriptionDurability set to Durable but without a required clientId > property, it generates NPE in our app server since the RA tries to create a > queue which name is an non-null empty string. > When the Activation validate its spec, it should verify the presence of the > clientId property if the subscriptionDurability is Durable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-225) Incomplete Activation Validation
[ https://issues.apache.org/jira/browse/ARTEMIS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14903235#comment-14903235 ] ASF subversion and git services commented on ARTEMIS-225: - Commit 7a337a7e552c0679d80ef2600c2ef6f7daf954ba in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=7a337a7 ] Revert "ARTEMIS-225 validate clientID is set for durable sub" This reverts commit 1c933cfbaeae6518e2fcf55bcb58f3b714f04370. > Incomplete Activation Validation > > > Key: ARTEMIS-225 > URL: https://issues.apache.org/jira/browse/ARTEMIS-225 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.0.0, 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > When a MDB is deployed with the activation config property > subscriptionDurability set to Durable but without a required clientId > property, it generates NPE in our app server since the RA tries to create a > queue which name is an non-null empty string. > When the Activation validate its spec, it should verify the presence of the > clientId property if the subscriptionDurability is Durable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-225) Incomplete Activation Validation
[ https://issues.apache.org/jira/browse/ARTEMIS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14903230#comment-14903230 ] ASF GitHub Bot commented on ARTEMIS-225: GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/173 Revert "ARTEMIS-225 validate clientID is set for durable sub" This reverts commit 1c933cfbaeae6518e2fcf55bcb58f3b714f04370. You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis master-revert Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/173.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 #173 commit 7a337a7e552c0679d80ef2600c2ef6f7daf954ba Author: Clebert Suconic Date: 2015-09-22T00:39:07Z Revert "ARTEMIS-225 validate clientID is set for durable sub" This reverts commit 1c933cfbaeae6518e2fcf55bcb58f3b714f04370. > Incomplete Activation Validation > > > Key: ARTEMIS-225 > URL: https://issues.apache.org/jira/browse/ARTEMIS-225 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.0.0, 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > Fix For: 1.2.0, 1.1.1 > > > When a MDB is deployed with the activation config property > subscriptionDurability set to Durable but without a required clientId > property, it generates NPE in our app server since the RA tries to create a > queue which name is an non-null empty string. > When the Activation validate its spec, it should verify the presence of the > clientId property if the subscriptionDurability is Durable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5977) Init script should provide LSB headers
[
https://issues.apache.org/jira/browse/AMQ-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902989#comment-14902989
]
Gregor Zurowski commented on AMQ-5977:
--
Created pull request: https://github.com/apache/activemq/pull/145
> Init script should provide LSB headers
> --
>
> Key: AMQ-5977
> URL: https://issues.apache.org/jira/browse/AMQ-5977
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.12.0
>Reporter: Gregor Zurowski
>Priority: Minor
>
> The current init script 'bin/activemq'
> (https://github.com/apache/activemq/blob/master/assembly/src/release/bin/activemq)
> does not provide any LSB headers. Because of this, setting up the service
> using chkconfig on RHEL and clones as described in the documentation (see
> http://activemq.apache.org/unix-shell-script.html) fails with the following
> error message:
> {code}
> $ chkconfig --add activemq
> service activemq does not support chkconfig
> {code}
> Ubuntu systems will print the following warning:
> {code}
> $ update-rc.d activemq defaults
> update-rc.d: warning: /etc/init.d/activemq missing LSB information
> update-rc.d: see
> Adding system startup for /etc/init.d/activemq ...
> [...]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5977) Init script should provide LSB headers
[
https://issues.apache.org/jira/browse/AMQ-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902985#comment-14902985
]
ASF GitHub Bot commented on AMQ-5977:
-
GitHub user gzurowski opened a pull request:
https://github.com/apache/activemq/pull/145
AMQ-5977: Add LSB headers to ínit script
Add LSB headers to init script to fix problems when setting up ActiveMQ
as a daemon with chkconfig on RHEL and clones.
Signed-off-by: Gregor Zurowski
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gzurowski/activemq init-lsb
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq/pull/145.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 #145
commit 8e70075a2d5ba2379fd0d46ed0f5fa56de2baad5
Author: Gregor Zurowski
Date: 2015-09-22T16:58:50Z
AMQ-5977: Add LSB headers to ínit script
Add LSB headers to init script to fix problems when setting up ActiveMQ
as a daemon with chkconfig on RHEL and clones.
Signed-off-by: Gregor Zurowski
> Init script should provide LSB headers
> --
>
> Key: AMQ-5977
> URL: https://issues.apache.org/jira/browse/AMQ-5977
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.12.0
>Reporter: Gregor Zurowski
>Priority: Minor
>
> The current init script 'bin/activemq'
> (https://github.com/apache/activemq/blob/master/assembly/src/release/bin/activemq)
> does not provide any LSB headers. Because of this, setting up the service
> using chkconfig on RHEL and clones as described in the documentation (see
> http://activemq.apache.org/unix-shell-script.html) fails with the following
> error message:
> {code}
> $ chkconfig --add activemq
> service activemq does not support chkconfig
> {code}
> Ubuntu systems will print the following warning:
> {code}
> $ update-rc.d activemq defaults
> update-rc.d: warning: /etc/init.d/activemq missing LSB information
> update-rc.d: see
> Adding system startup for /etc/init.d/activemq ...
> [...]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-5977) Init script should provide LSB headers
Gregor Zurowski created AMQ-5977:
Summary: Init script should provide LSB headers
Key: AMQ-5977
URL: https://issues.apache.org/jira/browse/AMQ-5977
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Affects Versions: 5.12.0
Reporter: Gregor Zurowski
Priority: Minor
The current init script 'bin/activemq'
(https://github.com/apache/activemq/blob/master/assembly/src/release/bin/activemq)
does not provide any LSB headers. Because of this, setting up the service
using chkconfig on RHEL and clones as described in the documentation (see
http://activemq.apache.org/unix-shell-script.html) fails with the following
error message:
{code}
$ chkconfig --add activemq
service activemq does not support chkconfig
{code}
Ubuntu systems will print the following warning:
{code}
$ update-rc.d activemq defaults
update-rc.d: warning: /etc/init.d/activemq missing LSB information
update-rc.d: see
Adding system startup for /etc/init.d/activemq ...
[...]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5966) ActiveMQ client hangs after rollback of a transacted JMS session
[ https://issues.apache.org/jira/browse/AMQ-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902889#comment-14902889 ] Christopher L. Shannon commented on AMQ-5966: - I think the test case code throws that exception just to demonstrate that the same listener was called twice. I was able to show the RuntimeException when running the code which is how I found the commit where the behavior changed. That being said, I haven't looked into it enough yet to figure out if there is an actual issue with the same listener being called again or if a new one is necessary. > ActiveMQ client hangs after rollback of a transacted JMS session > > > Key: AMQ-5966 > URL: https://issues.apache.org/jira/browse/AMQ-5966 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.12.0 > Environment: Reproduced standalone under Linux, but any environment > should be affected. >Reporter: Andreas Mattes > Attachments: AMQRollbackTest.java > > > The ActiveMQ JMS client is accessed through the ConnectionConsumer protocol. > A ServerSessionPool is provided which creates ServerSessions with transacted > JMS sessions. Up to ActiveMQ 5.11.2, everything has worked fine, but with > ActiveMQ 5.12.0, after rollback of a sesseion, the application hangs until > JMS re-connect happens. Further investigation reveals that with ActiveMQ > 5.11.2 and earlier, after rollback a new ServerSession is taken from the pool > and loaded with the message of the rolled back session. With ActiveMQ 5.12.0, > however, the MessageListener of the same session is called again. This is a > problem with the ConnectionConsumer protocol, because the may have claimed > the session for recycling. > The attached piece of test code (AMQRollbackTest.java) demonstrates the > issue. It runs fine with ActiveMQ 5.11.2 and hangs with ActiveMQ 5.12.0. It > demonstrates the issue for QueueSessions, but TopicSessions are affected > equally. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5942) CachedMessageGroupMapFactory fails with large key sets
[ https://issues.apache.org/jira/browse/AMQ-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902871#comment-14902871 ] Ben O'Day commented on AMQ-5942: I'd don't buy the memory usage argument...many default configs are unbounded (destination memoryLimit comes to mind)...and a memory issue would be preferable/easier to diagnose than silently causing concurrent/out of order processing...the whole reason to use message groups in the first place... at the very least, it should throw an error in the logs when the max LRU cache size is exceeded stating just that... > CachedMessageGroupMapFactory fails with large key sets > -- > > Key: AMQ-5942 > URL: https://issues.apache.org/jira/browse/AMQ-5942 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.11.1 >Reporter: Ben O'Day > Attachments: MessageGroupFactoryRouteTest.java > > > the current default factory is the CachedMessageGroupMapFactory which uses an > LRUMap with a maxSize of 1024 keys. If you use this with more than 1024 keys > and fail to explicitly increase the maxSize, then the message groups fails to > ensure ordering by group, same thread processing by group and overlapping > execution. > I have reproduced this behavior in the attached unit test (using Camel routes > as consumers)...if you switch to the SimpleMessageGroupMapFactory or increase > the max size of the cache above the number of keys...the issues go away > two suggestions > -throw an error when the maxSize is exceeded if using the > CachedMessageGroupMapFactory > -make the SimpleMessageGroupMapFactory the default (unlimited) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5966) ActiveMQ client hangs after rollback of a transacted JMS session
[
https://issues.apache.org/jira/browse/AMQ-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902859#comment-14902859
]
Christian Schneider commented on AMQ-5966:
--
I can not reproduce a hang from the Test class.
This looks a bit weird though:
public void onMessage(Message message) {
if (rolledBack) {
throw new RuntimeException("Session rolled back.");
}
Why does the code assume a session that experienced a rollback can not receive
any more messages?
> ActiveMQ client hangs after rollback of a transacted JMS session
>
>
> Key: AMQ-5966
> URL: https://issues.apache.org/jira/browse/AMQ-5966
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
>Affects Versions: 5.12.0
> Environment: Reproduced standalone under Linux, but any environment
> should be affected.
>Reporter: Andreas Mattes
> Attachments: AMQRollbackTest.java
>
>
> The ActiveMQ JMS client is accessed through the ConnectionConsumer protocol.
> A ServerSessionPool is provided which creates ServerSessions with transacted
> JMS sessions. Up to ActiveMQ 5.11.2, everything has worked fine, but with
> ActiveMQ 5.12.0, after rollback of a sesseion, the application hangs until
> JMS re-connect happens. Further investigation reveals that with ActiveMQ
> 5.11.2 and earlier, after rollback a new ServerSession is taken from the pool
> and loaded with the message of the rolled back session. With ActiveMQ 5.12.0,
> however, the MessageListener of the same session is called again. This is a
> problem with the ConnectionConsumer protocol, because the may have claimed
> the session for recycling.
> The attached piece of test code (AMQRollbackTest.java) demonstrates the
> issue. It runs fine with ActiveMQ 5.11.2 and hangs with ActiveMQ 5.12.0. It
> demonstrates the issue for QueueSessions, but TopicSessions are affected
> equally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-225) Incomplete Activation Validation
[ https://issues.apache.org/jira/browse/ARTEMIS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902861#comment-14902861 ] Justin Bertram commented on ARTEMIS-225: [~jmesnil], I don't believe my fix is valid per Clebert's comment above so I'd like to address the NPE at a different level. Can you provide a stack-trace or any further details on the specific API call from the RA which caused the NPE? > Incomplete Activation Validation > > > Key: ARTEMIS-225 > URL: https://issues.apache.org/jira/browse/ARTEMIS-225 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.0.0, 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > Fix For: 1.2.0, 1.1.1 > > > When a MDB is deployed with the activation config property > subscriptionDurability set to Durable but without a required clientId > property, it generates NPE in our app server since the RA tries to create a > queue which name is an non-null empty string. > When the Activation validate its spec, it should verify the presence of the > clientId property if the subscriptionDurability is Durable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-225) Incomplete Activation Validation
[ https://issues.apache.org/jira/browse/ARTEMIS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902790#comment-14902790 ] clebert suconic commented on ARTEMIS-225: - That fix is breaking deployments of MDBs through the RA... We need to provide some test for it. > Incomplete Activation Validation > > > Key: ARTEMIS-225 > URL: https://issues.apache.org/jira/browse/ARTEMIS-225 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.0.0, 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > Fix For: 1.2.0, 1.1.1 > > > When a MDB is deployed with the activation config property > subscriptionDurability set to Durable but without a required clientId > property, it generates NPE in our app server since the RA tries to create a > queue which name is an non-null empty string. > When the Activation validate its spec, it should verify the presence of the > clientId property if the subscriptionDurability is Durable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (ARTEMIS-225) Incomplete Activation Validation
[ https://issues.apache.org/jira/browse/ARTEMIS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-225: Comment: was deleted (was: The "fix" I sent to validate the activation spec breaks the TCK so I'm going to revert that and focus on resolving the NPE itself. [~jmesnil], can you provide a stack-trace for the NPE you're seeing?) > Incomplete Activation Validation > > > Key: ARTEMIS-225 > URL: https://issues.apache.org/jira/browse/ARTEMIS-225 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.0.0, 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > Fix For: 1.2.0, 1.1.1 > > > When a MDB is deployed with the activation config property > subscriptionDurability set to Durable but without a required clientId > property, it generates NPE in our app server since the RA tries to create a > queue which name is an non-null empty string. > When the Activation validate its spec, it should verify the presence of the > clientId property if the subscriptionDurability is Durable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-225) Incomplete Activation Validation
[ https://issues.apache.org/jira/browse/ARTEMIS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902763#comment-14902763 ] Justin Bertram commented on ARTEMIS-225: The "fix" I sent to validate the activation spec breaks the TCK so I'm going to revert that and focus on resolving the NPE itself. [~jmesnil], can you provide a stack-trace for the NPE you're seeing? > Incomplete Activation Validation > > > Key: ARTEMIS-225 > URL: https://issues.apache.org/jira/browse/ARTEMIS-225 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.0.0, 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > Fix For: 1.2.0, 1.1.1 > > > When a MDB is deployed with the activation config property > subscriptionDurability set to Durable but without a required clientId > property, it generates NPE in our app server since the RA tries to create a > queue which name is an non-null empty string. > When the Activation validate its spec, it should verify the presence of the > clientId property if the subscriptionDurability is Durable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (AMQ-5970) Weak ethereal DH key bug
[ https://issues.apache.org/jira/browse/AMQ-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon closed AMQ-5970. --- Resolution: Won't Fix I don't think it is a good idea to automatically choose a different SSL implementation for a user. The expected behavior is to use the JDK implementation and I think we should stick with the default and document the issue like Apollo does so that if a user runs into a problem they can switch out the implementation if they want. I have added documentation to this page: http://activemq.apache.org/how-do-i-use-ssl.html > Weak ethereal DH key bug > > > Key: AMQ-5970 > URL: https://issues.apache.org/jira/browse/AMQ-5970 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.12.0 > Environment: JDK 1.7.0_79 >Reporter: Laura Mann > Labels: ssl, ssl3, sslContext, websocket > > All modern browser's throw " SSL received a weak ephemeral Diffie-Hellman key > in Server Key Exchange handshake message. (Error code: > ssl_error_weak_server_ephemeral_dh_key) " when attempting to connect to a > secure websocket via activemq. This appears to be related to enabling and > disabling the correct cipher suite (though no combination using the > transport.enabledCipherSuites=… option seems to work). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-226) Fix typo in Netty TransportConstants
Jeff Mesnil created ARTEMIS-226: --- Summary: Fix typo in Netty TransportConstants Key: ARTEMIS-226 URL: https://issues.apache.org/jira/browse/ARTEMIS-226 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Jeff Mesnil Value of HTTP_UPGRADE_ENDPOINT_PROP_NAME is "httpPpgradeEndpoint". It should be fixed to "httpUpgradeEndpoint" https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/impl/netty/TransportConstants.java#L44 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (AMQ-5942) CachedMessageGroupMapFactory fails with large key sets
[ https://issues.apache.org/jira/browse/AMQ-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon closed AMQ-5942. --- Resolution: Not A Problem Based on my initial thoughts on this and after discussing this issue with [~tabish121], I don't think we should change this. We don't want to leave a potential for unbounded memory usage in the broker. Plus, the current expectation is that the LRU implementation is the default. We should update the documentation to describe this so that if someone needs more than 1024 groups they can change the policy configuration to increase the number of groups or to use a different implementation such as SimpleMessageGroupMapFactory. > CachedMessageGroupMapFactory fails with large key sets > -- > > Key: AMQ-5942 > URL: https://issues.apache.org/jira/browse/AMQ-5942 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.11.1 >Reporter: Ben O'Day > Attachments: MessageGroupFactoryRouteTest.java > > > the current default factory is the CachedMessageGroupMapFactory which uses an > LRUMap with a maxSize of 1024 keys. If you use this with more than 1024 keys > and fail to explicitly increase the maxSize, then the message groups fails to > ensure ordering by group, same thread processing by group and overlapping > execution. > I have reproduced this behavior in the attached unit test (using Camel routes > as consumers)...if you switch to the SimpleMessageGroupMapFactory or increase > the max size of the cache above the number of keys...the issues go away > two suggestions > -throw an error when the maxSize is exceeded if using the > CachedMessageGroupMapFactory > -make the SimpleMessageGroupMapFactory the default (unlimited) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5568) Deleting lock file on broker shut down can take a master broker down
[
https://issues.apache.org/jira/browse/AMQ-5568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902447#comment-14902447
]
ASF subversion and git services commented on AMQ-5568:
--
Commit 86c826c4615d5f4d90cc3f75fef845640369458d in activemq's branch
refs/heads/master from [~gtully]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=86c826c ]
https://issues.apache.org/jira/browse/AMQ-5568 - verify delete return code for
win platform failure. Thanks to Erik Wramner for the heads up
> Deleting lock file on broker shut down can take a master broker down
>
>
> Key: AMQ-5568
> URL: https://issues.apache.org/jira/browse/AMQ-5568
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Message Store
>Affects Versions: 5.11.0
>Reporter: Torsten Mielke
>Assignee: Gary Tully
> Labels: persistence
> Fix For: 5.12.0
>
>
> This problem may only occur on a shared file system master/slave setup.
> I can reproduce reliably on a NFSv4 mount using a persistence adapter
> configuration like
> {code}
>
>
>
>
>
> {code}
> However the problem is also reproducible using kahaDB.
> Two broker instances competing for the lock on the shared storage (e.g.
> leveldb or kahadb). Lets say brokerA becomes master, broker B slave.
> If brokerA looses access to the NFS share, it will shut down. As part of
> shutting down, it tries delete the lock file of the persistence adapter. Now
> since the NFS share is gone, all file i/o calls hang for a good while before
> returning errors. As such the broker shut down gets delayed.
> In the meantime the slave broker B (not affected by the NFS problem) grabs
> the lock and becomes master.
> If the NFS mount is restored while broker A (the previous master) still hangs
> on the file i/o operations (as part of its shutdown routine), the attempt to
> delete the persistence adapter lock file will finally succeed and broker A
> shuts down.
> Deleting the lock file however also affects the new master broker B who
> periodically runs a keepAlive() check on the lock. That check verifies the
> file still exists and the FileLock is still valid. As the lock file got
> deleted, keepAlive() fails on broker B and that broker shuts down as well.
> The overall result is that both broker instances have shut down despite an
> initially successful failover.
> Using restartAllowed=true is not an option either as this can cause other
> problems in an NFS based master/slave setup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5975) invalid header errror
[ https://issues.apache.org/jira/browse/AMQ-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902078#comment-14902078 ] Abhi edited comment on AMQ-5975 at 9/22/15 7:14 AM: Is there any specific reason to use ':' in session-id (which is derived from client-id)? Why can't we use any other character in the client-id? The util class do contain a getsanitizedId() method for this purpose only where ':' can cause issues on client side. Using getSanitizedId() should avoid this issue whether we use STOMP protocol v1.0,1.1 or 1.2. Thanks for the help! -xabhi was (Author: xabhi): Is there any specific reason to use ':' in session-id (which is derived from client-id)? Why can't we use any other character in the client-id? The util class do contain a getsanitizedId() method for this purpose only where ':' can cause issues on client side. Using getSanitizedId() should avoid this issue whether we use STOMP protocol v1.0,1.1 or 1.2. I will log a bug for client library as well but would still like to know the reasons for above. Thanks for the help! -xabhi > invalid header errror > - > > Key: AMQ-5975 > URL: https://issues.apache.org/jira/browse/AMQ-5975 > Project: ActiveMQ > Issue Type: Bug > Components: stomp >Affects Versions: 5.11.1 >Reporter: Abhi > Labels: stomp, v1.1, v1.2 > > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: encoding CONNECT frame > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H passcode: > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H > accept-version:1.0,1.1,1.2 > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H host:bismuth31.nyc > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H login: > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: sent 73 bytes > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: received 123 bytes > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: decoding CONNECTED frame > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H server:ActiveMQ/5.11.1 > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H heart-beat:0,0 > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H > session:ID:bismuth31.nyc-47753-1442302511794-1:3 > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H version:1.2 > [20150915 03:35:13.507 Net::Stomp::connect():332 WARN] Error while connecting > to the message broker: invalid header: > session:ID:bismuth31.nyc-47753-1442302511794-1:3 > This is happening because session header contains ':' in its value which > fails the check when using STOMPv1.1 protocol. > ActiveMQ generates a default client id if one is not provided at the start > and uses that to set session-id. But the session header cannot contain ':'. > (https://github.com/apache/activemq/blob/138e52b08c2f49b730817932a6e63f2a135854f1/activemq-client/src/main/java/org/apache/activemq/util/IdGenerator.java > and > https://github.com/apache/activemq/blob/87fd0a9e054017254c3857b245ca6fb9047ccc4f/activemq-stomp/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java#L797) > We can use generateSanitizedId() here to avoid this > issue(https://github.com/apache/activemq/blob/87fd0a9e054017254c3857b245ca6fb9047ccc4f/activemq-stomp/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java#L797) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5975) invalid header errror
[ https://issues.apache.org/jira/browse/AMQ-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902078#comment-14902078 ] Abhi commented on AMQ-5975: --- Is there any specific reason to use ':' in session-id (which is derived from client-id)? Why can't we use any other character in the client-id? The util class do contain a getsanitizedId() method for this purpose only where ':' can cause issues on client side. Using getSanitizedId() should avoid this issue whether we use STOMP protocol v1.0,1.1 or 1.2. I will log a bug on client side as well but would still like to know the reasons for above. Thanks for the help! -xabhi > invalid header errror > - > > Key: AMQ-5975 > URL: https://issues.apache.org/jira/browse/AMQ-5975 > Project: ActiveMQ > Issue Type: Bug > Components: stomp >Affects Versions: 5.11.1 >Reporter: Abhi > Labels: stomp, v1.1, v1.2 > > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: encoding CONNECT frame > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H passcode: > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H > accept-version:1.0,1.1,1.2 > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H host:bismuth31.nyc > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H login: > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: sent 73 bytes > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: received 123 bytes > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: decoding CONNECTED frame > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H server:ActiveMQ/5.11.1 > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H heart-beat:0,0 > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H > session:ID:bismuth31.nyc-47753-1442302511794-1:3 > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H version:1.2 > [20150915 03:35:13.507 Net::Stomp::connect():332 WARN] Error while connecting > to the message broker: invalid header: > session:ID:bismuth31.nyc-47753-1442302511794-1:3 > This is happening because session header contains ':' in its value which > fails the check when using STOMPv1.1 protocol. > ActiveMQ generates a default client id if one is not provided at the start > and uses that to set session-id. But the session header cannot contain ':'. > (https://github.com/apache/activemq/blob/138e52b08c2f49b730817932a6e63f2a135854f1/activemq-client/src/main/java/org/apache/activemq/util/IdGenerator.java > and > https://github.com/apache/activemq/blob/87fd0a9e054017254c3857b245ca6fb9047ccc4f/activemq-stomp/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java#L797) > We can use generateSanitizedId() here to avoid this > issue(https://github.com/apache/activemq/blob/87fd0a9e054017254c3857b245ca6fb9047ccc4f/activemq-stomp/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java#L797) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5975) invalid header errror
[ https://issues.apache.org/jira/browse/AMQ-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902078#comment-14902078 ] Abhi edited comment on AMQ-5975 at 9/22/15 7:03 AM: Is there any specific reason to use ':' in session-id (which is derived from client-id)? Why can't we use any other character in the client-id? The util class do contain a getsanitizedId() method for this purpose only where ':' can cause issues on client side. Using getSanitizedId() should avoid this issue whether we use STOMP protocol v1.0,1.1 or 1.2. I will log a bug for client library as well but would still like to know the reasons for above. Thanks for the help! -xabhi was (Author: xabhi): Is there any specific reason to use ':' in session-id (which is derived from client-id)? Why can't we use any other character in the client-id? The util class do contain a getsanitizedId() method for this purpose only where ':' can cause issues on client side. Using getSanitizedId() should avoid this issue whether we use STOMP protocol v1.0,1.1 or 1.2. I will log a bug on client side as well but would still like to know the reasons for above. Thanks for the help! -xabhi > invalid header errror > - > > Key: AMQ-5975 > URL: https://issues.apache.org/jira/browse/AMQ-5975 > Project: ActiveMQ > Issue Type: Bug > Components: stomp >Affects Versions: 5.11.1 >Reporter: Abhi > Labels: stomp, v1.1, v1.2 > > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: encoding CONNECT frame > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H passcode: > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H > accept-version:1.0,1.1,1.2 > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H host:bismuth31.nyc > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H login: > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: sent 73 bytes > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: received 123 bytes > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: decoding CONNECTED frame > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H server:ActiveMQ/5.11.1 > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H heart-beat:0,0 > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H > session:ID:bismuth31.nyc-47753-1442302511794-1:3 > # 2015/09/15-03:35:13 stomp_producer.pl[29263.0]: H version:1.2 > [20150915 03:35:13.507 Net::Stomp::connect():332 WARN] Error while connecting > to the message broker: invalid header: > session:ID:bismuth31.nyc-47753-1442302511794-1:3 > This is happening because session header contains ':' in its value which > fails the check when using STOMPv1.1 protocol. > ActiveMQ generates a default client id if one is not provided at the start > and uses that to set session-id. But the session header cannot contain ':'. > (https://github.com/apache/activemq/blob/138e52b08c2f49b730817932a6e63f2a135854f1/activemq-client/src/main/java/org/apache/activemq/util/IdGenerator.java > and > https://github.com/apache/activemq/blob/87fd0a9e054017254c3857b245ca6fb9047ccc4f/activemq-stomp/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java#L797) > We can use generateSanitizedId() here to avoid this > issue(https://github.com/apache/activemq/blob/87fd0a9e054017254c3857b245ca6fb9047ccc4f/activemq-stomp/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java#L797) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
