[jira] [Resolved] (AMQ-8971) ActiveMQ OSGI feature, activemq-client, using JMS 2.0 bundle, which fails resolution, from 5.16.3 on
[
https://issues.apache.org/jira/browse/AMQ-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arthur Naseef resolved AMQ-8971.
Fix Version/s: 5.18.0
5.17.2
Assignee: Arthur Naseef (was: Jean-Baptiste Onofré)
Resolution: Fixed
Feature file updated so the bundles will work for both JMS spec versions 1.1
and 2.0.
> ActiveMQ OSGI feature, activemq-client, using JMS 2.0 bundle, which fails
> resolution, from 5.16.3 on
>
>
> Key: AMQ-8971
> URL: https://issues.apache.org/jira/browse/AMQ-8971
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Arthur Naseef
>Assignee: Arthur Naseef
>Priority: Major
> Fix For: 5.18.0, 5.17.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Building an ActiveMQ client application in OSGI. Using AMQ versions 5.16.3
> through 5.17.1.
> After building the application and loading it together with the ActiveMQ
> feature named {{{}activemq-client{}}}, a resolution error occurs with the
> following details:
>
> {code:java}
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=javax.jms)(version>=1.1.0)(!(version>=2.0.0)))"
> {code}
> Tracking this down, the {{activemq-client}} feature definition contains the
> following:
>
>
> {code:java}
> dependency="true">mvn:org.apache.geronimo.specs/geronimo-jms_2.0_spec/1.0-alpha-2
> {code}
> Using the karaf console command, package:exports | grep javax.jms, after
> loading the activemq-client feature, shows that this bundle ONLY exports the
> 2.0.0 version:
>
>
> {code:java}
> javax.jms │ 2.0.0 │ 73 │
> org.apache.geronimo.specs.geronimo-jms_2.0_spec {code}
>
> The same feature in 5.16.2 contains the following definition:
>
> {code:java}
> dependency="true">mvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/1.1.1
> {code}
>
> All of the ACTIVEMQ modules, except for activemq-karaf are using the
> following dependency:
>
> {code:java}
>
> org.apache.geronimo.specs
> geronimo-jms_1.1_spec
> {code}
>
> In Summary, compiling an ActiveMQ client application using activemq-client
> from versions 5.16.3 through 5.17.1, the application fails to resovle in
> Karaf by loading the activemq-client feature.
> *STEPS TO REPRODUCE*
> * feature:repo-add
> mvn:org.apache.activemq/activemq-karaf/5.17.1/xml/features-core
> * feature:install activemq-client
> * bundle:install ...application-bundle...
> *EXPECTED RESULTS*
> * Successful load of the application bundle built against version 5.17.1 of
> ActiveMQ artifacts after loading the activemq-client feature
> *ROOT CAUSE*
> * Replacing the JMS 1.0 geronimo specification bundle with the 2.0 one in
> the activemq-client feature causes this problem. It also seems very odd
> since no other internals of ActiveMQ use the JMS 2.0 spec at all.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-8971) ActiveMQ OSGI feature, activemq-client, using JMS 2.0 bundle, which fails resolution, from 5.16.3 on
[
https://issues.apache.org/jira/browse/AMQ-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570361#comment-17570361
]
Arthur Naseef commented on AMQ-8971:
PR created [https://github.com/apache/activemq/pull/861.]
Created the PR instead of directly pushing to encourage discussion and
additional testing of interested parties.
> ActiveMQ OSGI feature, activemq-client, using JMS 2.0 bundle, which fails
> resolution, from 5.16.3 on
>
>
> Key: AMQ-8971
> URL: https://issues.apache.org/jira/browse/AMQ-8971
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Arthur Naseef
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Building an ActiveMQ client application in OSGI. Using AMQ versions 5.16.3
> through 5.17.1.
> After building the application and loading it together with the ActiveMQ
> feature named {{{}activemq-client{}}}, a resolution error occurs with the
> following details:
>
> {code:java}
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=javax.jms)(version>=1.1.0)(!(version>=2.0.0)))"
> {code}
> Tracking this down, the {{activemq-client}} feature definition contains the
> following:
>
>
> {code:java}
> dependency="true">mvn:org.apache.geronimo.specs/geronimo-jms_2.0_spec/1.0-alpha-2
> {code}
> Using the karaf console command, package:exports | grep javax.jms, after
> loading the activemq-client feature, shows that this bundle ONLY exports the
> 2.0.0 version:
>
>
> {code:java}
> javax.jms │ 2.0.0 │ 73 │
> org.apache.geronimo.specs.geronimo-jms_2.0_spec {code}
>
> The same feature in 5.16.2 contains the following definition:
>
> {code:java}
> dependency="true">mvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/1.1.1
> {code}
>
> All of the ACTIVEMQ modules, except for activemq-karaf are using the
> following dependency:
>
> {code:java}
>
> org.apache.geronimo.specs
> geronimo-jms_1.1_spec
> {code}
>
> In Summary, compiling an ActiveMQ client application using activemq-client
> from versions 5.16.3 through 5.17.1, the application fails to resovle in
> Karaf by loading the activemq-client feature.
> *STEPS TO REPRODUCE*
> * feature:repo-add
> mvn:org.apache.activemq/activemq-karaf/5.17.1/xml/features-core
> * feature:install activemq-client
> * bundle:install ...application-bundle...
> *EXPECTED RESULTS*
> * Successful load of the application bundle built against version 5.17.1 of
> ActiveMQ artifacts after loading the activemq-client feature
> *ROOT CAUSE*
> * Replacing the JMS 1.0 geronimo specification bundle with the 2.0 one in
> the activemq-client feature causes this problem. It also seems very odd
> since no other internals of ActiveMQ use the JMS 2.0 spec at all.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-8971) ActiveMQ OSGI feature, activemq-client, using JMS 2.0 bundle, which fails resolution, from 5.16.3 on
[
https://issues.apache.org/jira/browse/AMQ-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17556504#comment-17556504
]
Arthur Naseef commented on AMQ-8971:
Please do not take unilateral action on this ticket Matt
> ActiveMQ OSGI feature, activemq-client, using JMS 2.0 bundle, which fails
> resolution, from 5.16.3 on
>
>
> Key: AMQ-8971
> URL: https://issues.apache.org/jira/browse/AMQ-8971
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Arthur Naseef
>Priority: Major
>
> Building an ActiveMQ client application in OSGI. Using AMQ versions 5.16.3
> through 5.17.1.
> After building the application and loading it together with the ActiveMQ
> feature named {{{}activemq-client{}}}, a resolution error occurs with the
> following details:
>
> {code:java}
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=javax.jms)(version>=1.1.0)(!(version>=2.0.0)))"
> {code}
> Tracking this down, the {{activemq-client}} feature definition contains the
> following:
>
>
> {code:java}
> dependency="true">mvn:org.apache.geronimo.specs/geronimo-jms_2.0_spec/1.0-alpha-2
> {code}
> Using the karaf console command, package:exports | grep javax.jms, after
> loading the activemq-client feature, shows that this bundle ONLY exports the
> 2.0.0 version:
>
>
> {code:java}
> javax.jms │ 2.0.0 │ 73 │
> org.apache.geronimo.specs.geronimo-jms_2.0_spec {code}
>
> The same feature in 5.16.2 contains the following definition:
>
> {code:java}
> dependency="true">mvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/1.1.1
> {code}
>
> All of the ACTIVEMQ modules, except for activemq-karaf are using the
> following dependency:
>
> {code:java}
>
> org.apache.geronimo.specs
> geronimo-jms_1.1_spec
> {code}
>
> In Summary, compiling an ActiveMQ client application using activemq-client
> from versions 5.16.3 through 5.17.1, the application fails to resovle in
> Karaf by loading the activemq-client feature.
> *STEPS TO REPRODUCE*
> * feature:repo-add
> mvn:org.apache.activemq/activemq-karaf/5.17.1/xml/features-core
> * feature:install activemq-client
> * bundle:install ...application-bundle...
> *EXPECTED RESULTS*
> * Successful load of the application bundle built against version 5.17.1 of
> ActiveMQ artifacts after loading the activemq-client feature
> *ROOT CAUSE*
> * Replacing the JMS 1.0 geronimo specification bundle with the 2.0 one in
> the activemq-client feature causes this problem. It also seems very odd
> since no other internals of ActiveMQ use the JMS 2.0 spec at all.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (AMQ-8971) ActiveMQ OSGI feature, activemq-client, using JMS 2.0 bundle, which fails resolution, from 5.16.3 on
[
https://issues.apache.org/jira/browse/AMQ-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17556503#comment-17556503
]
Arthur Naseef commented on AMQ-8971:
100% disagree with this response.
Breaking the common case for an edge case is not right.
Saying 2.0 impl is underway is just a distraction from the current state of
affairs.
> ActiveMQ OSGI feature, activemq-client, using JMS 2.0 bundle, which fails
> resolution, from 5.16.3 on
>
>
> Key: AMQ-8971
> URL: https://issues.apache.org/jira/browse/AMQ-8971
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Arthur Naseef
>Assignee: Matt Pavlovich
>Priority: Major
>
> Building an ActiveMQ client application in OSGI. Using AMQ versions 5.16.3
> through 5.17.1.
> After building the application and loading it together with the ActiveMQ
> feature named {{{}activemq-client{}}}, a resolution error occurs with the
> following details:
>
> {code:java}
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=javax.jms)(version>=1.1.0)(!(version>=2.0.0)))"
> {code}
> Tracking this down, the {{activemq-client}} feature definition contains the
> following:
>
>
> {code:java}
> dependency="true">mvn:org.apache.geronimo.specs/geronimo-jms_2.0_spec/1.0-alpha-2
> {code}
> Using the karaf console command, package:exports | grep javax.jms, after
> loading the activemq-client feature, shows that this bundle ONLY exports the
> 2.0.0 version:
>
>
> {code:java}
> javax.jms │ 2.0.0 │ 73 │
> org.apache.geronimo.specs.geronimo-jms_2.0_spec {code}
>
> The same feature in 5.16.2 contains the following definition:
>
> {code:java}
> dependency="true">mvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/1.1.1
> {code}
>
> All of the ACTIVEMQ modules, except for activemq-karaf are using the
> following dependency:
>
> {code:java}
>
> org.apache.geronimo.specs
> geronimo-jms_1.1_spec
> {code}
>
> In Summary, compiling an ActiveMQ client application using activemq-client
> from versions 5.16.3 through 5.17.1, the application fails to resovle in
> Karaf by loading the activemq-client feature.
> *STEPS TO REPRODUCE*
> * feature:repo-add
> mvn:org.apache.activemq/activemq-karaf/5.17.1/xml/features-core
> * feature:install activemq-client
> * bundle:install ...application-bundle...
> *EXPECTED RESULTS*
> * Successful load of the application bundle built against version 5.17.1 of
> ActiveMQ artifacts after loading the activemq-client feature
> *ROOT CAUSE*
> * Replacing the JMS 1.0 geronimo specification bundle with the 2.0 one in
> the activemq-client feature causes this problem. It also seems very odd
> since no other internals of ActiveMQ use the JMS 2.0 spec at all.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Reopened] (AMQ-8971) ActiveMQ OSGI feature, activemq-client, using JMS 2.0 bundle, which fails resolution, from 5.16.3 on
[
https://issues.apache.org/jira/browse/AMQ-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arthur Naseef reopened AMQ-8971:
Assignee: (was: Matt Pavlovich)
> ActiveMQ OSGI feature, activemq-client, using JMS 2.0 bundle, which fails
> resolution, from 5.16.3 on
>
>
> Key: AMQ-8971
> URL: https://issues.apache.org/jira/browse/AMQ-8971
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Arthur Naseef
>Priority: Major
>
> Building an ActiveMQ client application in OSGI. Using AMQ versions 5.16.3
> through 5.17.1.
> After building the application and loading it together with the ActiveMQ
> feature named {{{}activemq-client{}}}, a resolution error occurs with the
> following details:
>
> {code:java}
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=javax.jms)(version>=1.1.0)(!(version>=2.0.0)))"
> {code}
> Tracking this down, the {{activemq-client}} feature definition contains the
> following:
>
>
> {code:java}
> dependency="true">mvn:org.apache.geronimo.specs/geronimo-jms_2.0_spec/1.0-alpha-2
> {code}
> Using the karaf console command, package:exports | grep javax.jms, after
> loading the activemq-client feature, shows that this bundle ONLY exports the
> 2.0.0 version:
>
>
> {code:java}
> javax.jms │ 2.0.0 │ 73 │
> org.apache.geronimo.specs.geronimo-jms_2.0_spec {code}
>
> The same feature in 5.16.2 contains the following definition:
>
> {code:java}
> dependency="true">mvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/1.1.1
> {code}
>
> All of the ACTIVEMQ modules, except for activemq-karaf are using the
> following dependency:
>
> {code:java}
>
> org.apache.geronimo.specs
> geronimo-jms_1.1_spec
> {code}
>
> In Summary, compiling an ActiveMQ client application using activemq-client
> from versions 5.16.3 through 5.17.1, the application fails to resovle in
> Karaf by loading the activemq-client feature.
> *STEPS TO REPRODUCE*
> * feature:repo-add
> mvn:org.apache.activemq/activemq-karaf/5.17.1/xml/features-core
> * feature:install activemq-client
> * bundle:install ...application-bundle...
> *EXPECTED RESULTS*
> * Successful load of the application bundle built against version 5.17.1 of
> ActiveMQ artifacts after loading the activemq-client feature
> *ROOT CAUSE*
> * Replacing the JMS 1.0 geronimo specification bundle with the 2.0 one in
> the activemq-client feature causes this problem. It also seems very odd
> since no other internals of ActiveMQ use the JMS 2.0 spec at all.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (AMQ-8971) ActiveMQ OSGI feature, activemq-client, using JMS 2.0 bundle, which fails resolution, from 5.16.3 on
[
https://issues.apache.org/jira/browse/AMQ-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17556482#comment-17556482
]
Arthur Naseef commented on AMQ-8971:
I propose the *correct* fix for this is to revert the feature to use the JMS
1.1 spec, since that's was ActiveMQ uses internally, and "advertises" to all
the applications building against AMQ dependencies.
Anyone that needs 2.0 can do the extra work to make it work. If we really feel
strongly the need to assist, then perhaps one of the following is worth
considering:
* A separate feature (e.g. activemq-client-jms2_spec) that uses the 2.0 spec
instead of the 1.0, OR
* A custom JMS spec bundle that resolves aginst both 1.1 and 2.0
> ActiveMQ OSGI feature, activemq-client, using JMS 2.0 bundle, which fails
> resolution, from 5.16.3 on
>
>
> Key: AMQ-8971
> URL: https://issues.apache.org/jira/browse/AMQ-8971
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Arthur Naseef
>Priority: Major
>
> Building an ActiveMQ client application in OSGI. Using AMQ versions 5.16.3
> through 5.17.1.
> After building the application and loading it together with the ActiveMQ
> feature named {{{}activemq-client{}}}, a resolution error occurs with the
> following details:
>
> {code:java}
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=javax.jms)(version>=1.1.0)(!(version>=2.0.0)))"
> {code}
> Tracking this down, the {{activemq-client}} feature definition contains the
> following:
>
>
> {code:java}
> dependency="true">mvn:org.apache.geronimo.specs/geronimo-jms_2.0_spec/1.0-alpha-2
> {code}
> Using the karaf console command, package:exports | grep javax.jms, after
> loading the activemq-client feature, shows that this bundle ONLY exports the
> 2.0.0 version:
>
>
> {code:java}
> javax.jms │ 2.0.0 │ 73 │
> org.apache.geronimo.specs.geronimo-jms_2.0_spec {code}
>
> The same feature in 5.16.2 contains the following definition:
>
> {code:java}
> dependency="true">mvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/1.1.1
> {code}
>
> All of the ACTIVEMQ modules, except for activemq-karaf are using the
> following dependency:
>
> {code:java}
>
> org.apache.geronimo.specs
> geronimo-jms_1.1_spec
> {code}
>
> In Summary, compiling an ActiveMQ client application using activemq-client
> from versions 5.16.3 through 5.17.1, the application fails to resovle in
> Karaf by loading the activemq-client feature.
> *STEPS TO REPRODUCE*
> * feature:repo-add
> mvn:org.apache.activemq/activemq-karaf/5.17.1/xml/features-core
> * feature:install activemq-client
> * bundle:install ...application-bundle...
> *EXPECTED RESULTS*
> * Successful load of the application bundle built against version 5.17.1 of
> ActiveMQ artifacts after loading the activemq-client feature
> *ROOT CAUSE*
> * Replacing the JMS 1.0 geronimo specification bundle with the 2.0 one in
> the activemq-client feature causes this problem. It also seems very odd
> since no other internals of ActiveMQ use the JMS 2.0 spec at all.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (AMQ-8971) ActiveMQ OSGI feature, activemq-client, using JMS 2.0 bundle, which fails resolution, from 5.16.3 on
Arthur Naseef created AMQ-8971:
--
Summary: ActiveMQ OSGI feature, activemq-client, using JMS 2.0
bundle, which fails resolution, from 5.16.3 on
Key: AMQ-8971
URL: https://issues.apache.org/jira/browse/AMQ-8971
Project: ActiveMQ
Issue Type: Bug
Reporter: Arthur Naseef
Building an ActiveMQ client application in OSGI. Using AMQ versions 5.16.3
through 5.17.1.
After building the application and loading it together with the ActiveMQ
feature named {{{}activemq-client{}}}, a resolution error occurs with the
following details:
{code:java}
osgi.wiring.package;
filter:="(&(osgi.wiring.package=javax.jms)(version>=1.1.0)(!(version>=2.0.0)))"
{code}
Tracking this down, the {{activemq-client}} feature definition contains the
following:
{code:java}
mvn:org.apache.geronimo.specs/geronimo-jms_2.0_spec/1.0-alpha-2
{code}
Using the karaf console command, package:exports | grep javax.jms, after
loading the activemq-client feature, shows that this bundle ONLY exports the
2.0.0 version:
{code:java}
javax.jms │ 2.0.0 │ 73 │
org.apache.geronimo.specs.geronimo-jms_2.0_spec {code}
The same feature in 5.16.2 contains the following definition:
{code:java}
mvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/1.1.1
{code}
All of the ACTIVEMQ modules, except for activemq-karaf are using the following
dependency:
{code:java}
org.apache.geronimo.specs
geronimo-jms_1.1_spec
{code}
In Summary, compiling an ActiveMQ client application using activemq-client from
versions 5.16.3 through 5.17.1, the application fails to resovle in Karaf by
loading the activemq-client feature.
*STEPS TO REPRODUCE*
* feature:repo-add
mvn:org.apache.activemq/activemq-karaf/5.17.1/xml/features-core
* feature:install activemq-client
* bundle:install ...application-bundle...
*EXPECTED RESULTS*
* Successful load of the application bundle built against version 5.17.1 of
ActiveMQ artifacts after loading the activemq-client feature
*ROOT CAUSE*
* Replacing the JMS 1.0 geronimo specification bundle with the 2.0 one in the
activemq-client feature causes this problem. It also seems very odd since no
other internals of ActiveMQ use the JMS 2.0 spec at all.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (ARTEMIS-3766) Race condition with Dual Mirror and Expiry
[ https://issues.apache.org/jira/browse/ARTEMIS-3766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519677#comment-17519677 ] Arthur Naseef commented on ARTEMIS-3766: Would internal mirror messages that tell when a message moved from one queue to another help? > Race condition with Dual Mirror and Expiry > -- > > Key: ARTEMIS-3766 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3766 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.21.0 >Reporter: Stephen Baker >Priority: Major > > When dual mirroring is in play there is a race condition which can result in > missing or duplicate messages on the brokers. > > Scenario 1: > # Bring up two artemis instances with broker-connection mirroring between > each other. (A and B) > # Send a message to A with a short TTL (I used 30 seconds in my test) > # After the message mirrors but before it expires, pause the Mirror queue on > both sides > # Wait for the message to expire, and the reaper thread to pick it up > # Observe that on both sides the message has moved to the ExpiryQueue. In > the Mirror queue there are 2 messages on A (a message destined to the > ExpiryQueue and an ack on the original message). On B there is a single > message in the mirror, which is the message to the expiry queue. > # Resume the mirror, I'm not sure the order matters, but I did B and then A. > # Observe that on A there is a single message in the ExpiryQueue, but on B > there are now 2 messages in the expiry queue. > Scenario 2: > # Bring up two artemis instances with broker-connection mirroring between > each other. (A and B). On A disable the reaper thread by setting > `-1` > # Send a message to A with a short TTL > # Wait for the TTL to expire > # On B the message moves to the ExpiryQueue, on A the message ends > disappears (no longer in the ExpiryQueue nor the original queue) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3766) Race condition with Dual Mirror and Expiry
[ https://issues.apache.org/jira/browse/ARTEMIS-3766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519676#comment-17519676 ] Arthur Naseef commented on ARTEMIS-3766: This one is a little complicated by the different scenarios that can occur, especially with dual mirroring. If there were explicit broker "HOT" and "COLD" states for the mirror source and target, that would make this simpler to resolve, but of course adds the complexity of maintaining that HOT/COLD status. Anytime we have "live/live" operations and attempt to keep both sides in-sync, it gets to be complicated. Having one side designated as live (or HOT) and the other side as idle/COLD can eliminate a lot of challenges there. Here are some scenarios I can think of: *Scenario 1* * Message with TTL copied across mirror to target * Message expiration processed on the source, causing the message to move into the ExpiryQueue * ExpiryQueue message copied across mirror to target * ExpiryQueue message is consumed/removed on the mirror source * Message expiration processed on the target Expected outcome: * Message is removed everywhere (i.e. removed from original queue and ExpiryQueue on both source and target mirrors) *Scenario 2* * Message with TTL copied across mirror to target * Source broker shuts down * (A) Message expiration processed on the target, causing the message to move into the ExpiryQueue * (B) Source broker resumes operation * Message expiration processed on the source, causing the message to move into the ExpiryQueue * ExpiryQueue message is consumed/removed on the mirror source Expected outcome: * After (A) completes, message exists in the target's ExpiryQueue * After (B) completes, the source broker still has the message in the original queue and does not see the ExpiryQueue message * On completion, the message again is removed everywhere *Scenario 3* * Message with TTL copied across mirror to target * Message is consumed from the mirror source * Message expiration processed on the target before the mirrored ACK is processed, causing the message to move into the ExpiryQueue Expected outcome: * On completion, the message again is removed everywhere Is there a way to keep track of the ExpiryQueue message and tie its state to the original message such that mirror operations can map incoming message ACKs to both unexpired and expired messages? Does DLQ handling create more of the same? Hope this helps. > Race condition with Dual Mirror and Expiry > -- > > Key: ARTEMIS-3766 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3766 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.21.0 >Reporter: Stephen Baker >Priority: Major > > When dual mirroring is in play there is a race condition which can result in > missing or duplicate messages on the brokers. > > Scenario 1: > # Bring up two artemis instances with broker-connection mirroring between > each other. (A and B) > # Send a message to A with a short TTL (I used 30 seconds in my test) > # After the message mirrors but before it expires, pause the Mirror queue on > both sides > # Wait for the message to expire, and the reaper thread to pick it up > # Observe that on both sides the message has moved to the ExpiryQueue. In > the Mirror queue there are 2 messages on A (a message destined to the > ExpiryQueue and an ack on the original message). On B there is a single > message in the mirror, which is the message to the expiry queue. > # Resume the mirror, I'm not sure the order matters, but I did B and then A. > # Observe that on A there is a single message in the ExpiryQueue, but on B > there are now 2 messages in the expiry queue. > Scenario 2: > # Bring up two artemis instances with broker-connection mirroring between > each other. (A and B). On A disable the reaper thread by setting > `-1` > # Send a message to A with a short TTL > # Wait for the TTL to expire > # On B the message moves to the ExpiryQueue, on A the message ends > disappears (no longer in the ExpiryQueue nor the original queue) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (AMQ-6954) Queue page on web console displays URL parameter without proper encoding
[ https://issues.apache.org/jira/browse/AMQ-6954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16572384#comment-16572384 ] Arthur Naseef commented on AMQ-6954: Additional update to resolve: [https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=d8c80a98212ee5d73a281483a2f8b3f517465f62] > Queue page on web console displays URL parameter without proper encoding > > > Key: AMQ-6954 > URL: https://issues.apache.org/jira/browse/AMQ-6954 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.3 >Reporter: Arthur Naseef >Assignee: Arthur Naseef >Priority: Major > Fix For: 5.16.0, 5.15.5 > > > Using a URL with the parameter, QueryFilter, the value of that parameter is > included in the output page without proper encoding. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-6954) Queue page on web console displays URL parameter without proper encoding
Arthur Naseef created AMQ-6954: -- Summary: Queue page on web console displays URL parameter without proper encoding Key: AMQ-6954 URL: https://issues.apache.org/jira/browse/AMQ-6954 Project: ActiveMQ Issue Type: Bug Components: webconsole Affects Versions: 5.15.3 Reporter: Arthur Naseef Assignee: Arthur Naseef Using a URL with the parameter, QueryFilter, the value of that parameter is included in the output page without proper encoding. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-5414) stored XSS via MQ message
[
https://issues.apache.org/jira/browse/AMQ-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456948#comment-16456948
]
Arthur Naseef commented on AMQ-5414:
I tried the following test:
* Post a message to a queue with the body
{code:java}
{code}
* View in the web console (shows correctly - I see the literal body displayed
on the web console)
* "Show Sources" - looks correct:
{code:java}
script
src=abc/script
{code}
Not sure what else might be the problem.
Here's the code, by the way (in message.jsp) - note the use of c:out
{code:java}
{code}
> stored XSS via MQ message
> --
>
> Key: AMQ-5414
> URL: https://issues.apache.org/jira/browse/AMQ-5414
> Project: ActiveMQ
> Issue Type: Bug
> Components: webconsole
>Affects Versions: 5.10.0
>Reporter: Atholl Stewart
>Priority: Major
>
> When a MQ message is received containing a maliciously crafted payload via
> STOMP, AMQP etc. then a stored XSS is created when the message is viewed in
> the management interface.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-5414) stored XSS via MQ message
[ https://issues.apache.org/jira/browse/AMQ-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456711#comment-16456711 ] Arthur Naseef commented on AMQ-5414: Are there any details on how XSS is created when viewing the message in the management console? > stored XSS via MQ message > -- > > Key: AMQ-5414 > URL: https://issues.apache.org/jira/browse/AMQ-5414 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.10.0 >Reporter: Atholl Stewart >Priority: Major > > When a MQ message is received containing a maliciously crafted payload via > STOMP, AMQP etc. then a stored XSS is created when the message is viewed in > the management interface. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMQ-6930) bin/activemq should allow stdout/stderr to some file instead of /dev/null for daemon mode
[ https://issues.apache.org/jira/browse/AMQ-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arthur Naseef resolved AMQ-6930. Resolution: Fixed > bin/activemq should allow stdout/stderr to some file instead of /dev/null for > daemon mode > - > > Key: AMQ-6930 > URL: https://issues.apache.org/jira/browse/AMQ-6930 > Project: ActiveMQ > Issue Type: Wish >Affects Versions: 5.15.0, 5.15.1, 5.15.2, 5.15.3 >Reporter: Alvin Lin >Priority: Major > > if I do "bin/activemq start" the ActiveMQ process is started with > stdout/stdin redirected to /dev/null. > This makes it hard to debug issue like out of memory error because we can't > see any log, for example, when the JVM flag "ExitOnOutOfMemoryError" is > turned on. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6930) bin/activemq should allow stdout/stderr to some file instead of /dev/null for daemon mode
[ https://issues.apache.org/jira/browse/AMQ-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432867#comment-16432867 ] Arthur Naseef commented on AMQ-6930: Since the update is fully backward compatible, and adds new functionality that is definitely useful, I agree with the update. After successfully building locally (which required skipping the faulty, and unrelated, PooledConnectionSecurityExceptionTest.java test), I merged the commits. Commits merged with thanks to Alvin Lin. > bin/activemq should allow stdout/stderr to some file instead of /dev/null for > daemon mode > - > > Key: AMQ-6930 > URL: https://issues.apache.org/jira/browse/AMQ-6930 > Project: ActiveMQ > Issue Type: Wish >Affects Versions: 5.15.0, 5.15.1, 5.15.2, 5.15.3 >Reporter: Alvin Lin >Priority: Major > > if I do "bin/activemq start" the ActiveMQ process is started with > stdout/stdin redirected to /dev/null. > This makes it hard to debug issue like out of memory error because we can't > see any log, for example, when the JVM flag "ExitOnOutOfMemoryError" is > turned on. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-6573) CSRF attack complaint on webconsole on purge or delete after navigating
Arthur Naseef created AMQ-6573: -- Summary: CSRF attack complaint on webconsole on purge or delete after navigating Key: AMQ-6573 URL: https://issues.apache.org/jira/browse/AMQ-6573 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.14.3 Reporter: Arthur Naseef CSRF protection causes a failure on attempting to purge or delete messages on the webconsole after navigating; the following steps will reproduce the problem: 1. login to webconsole 2. click "Queues" 3. click on a queue name to browse the queue 4. click the browser back button 5. click "Purge" or "Delete" next to any queue The result is a CSRF exception failing the attempt. It turns out that browsing queue causes a new secret key to be generated. This is easy to see by hovering over the "delete" link on both the main Queues page (queues.jsp) and the queue-browser page (admin/browse.jsp). Perhaps passing the secret key into the browser page is the best way to avoid this frustration for users? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6203) KahaDB: Allow rewrite of message acks in older logs which prevent cleanup
[ https://issues.apache.org/jira/browse/AMQ-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232711#comment-15232711 ] Arthur Naseef commented on AMQ-6203: I agree with this - sounds like a great approach. > KahaDB: Allow rewrite of message acks in older logs which prevent cleanup > - > > Key: AMQ-6203 > URL: https://issues.apache.org/jira/browse/AMQ-6203 > Project: ActiveMQ > Issue Type: Improvement > Components: KahaDB >Affects Versions: 5.13.0, 5.13.1, 5.12.3, 5.13.2 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 5.14.0 > > > There are cases where a chain of journal logs can grow due to acks for > messages in older logs needing to be kept so that on recovery proper state > can be restored and older messages not be resurrected. > In many cases just moving the acks from one log forward to a new log can free > an entire chain during subsequent GC cycles. The 'compacted' ack log can be > written during the time between GC cycles without the index lock being held > meaning normal broker operations can continue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ
[
https://issues.apache.org/jira/browse/AMQ-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15116284#comment-15116284
]
Arthur Naseef commented on AMQ-5100:
This seems like a reasonable scenario and fix. Anytime the SSL context needs
to be customized, this is how it must be done.
Can we close this ticket?
> PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ
> --
>
> Key: AMQ-5100
> URL: https://issues.apache.org/jira/browse/AMQ-5100
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Reporter: Jesse Sightler
>
> I have attempted to configure PKCS11/NSS support in ActiveMQ, however, I am
> receiving the following exception:
> Caused by: java.io.FileNotFoundException: class path resource [NONE] cannot
> be opened because it does not exist
> at
> org.springframework.core.io.ClassPathResource.getInputStream(ClassPathResource.java:157)
> at
> org.apache.activemq.spring.SpringSslContext.createKeyManagerKeyStore(SpringSslContext.java:119)
> at
> org.apache.activemq.spring.SpringSslContext.createKeyManagers(SpringSslContext.java:88)
> at
> org.apache.activemq.spring.SpringSslContext.afterPropertiesSet(SpringSslContext.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1581)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1522)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
> ... 40 more
> My configured sslContext for the broker looks like this:
>
> keyStore="NONE" keyStoreType="PKCS11"
> keyStorePassword="password"
> trustStore="/etc/activemqssl/truststore.jks"
> trustStorePassword="password"
> />
>
> AFAIK, setting keyStore to "NONE" is the generally accepted way to do with
> with PKCS11. The code should generate a warning at most for this, but instead
> I receive the above exception and a failure to load the keystore.
> The activemq code looks like this (in
> org.apache.activemq.spring.SpringSslContext):
> private KeyStore createKeyManagerKeyStore() throws Exception {
> if( keyStore ==null ) {
> return null;
> }
> KeyStore ks = KeyStore.getInstance(keyStoreType);
> InputStream is=Utils.resourceFromString(keyStore).getInputStream();
> try {
> ks.load(is, keyStorePassword==null? null :
> keyStorePassword.toCharArray());
> } finally {
> is.close();
> }
> return ks;
> }
> It looks like this should just be setting "is" to null, generating a warning,
> and then calling ks.load with the null inputstream (the nss library will load
> the nss files based upon the nss.cfg file).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5695) KahaDB not cleaning up log files
[ https://issues.apache.org/jira/browse/AMQ-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arthur Naseef updated AMQ-5695: --- Assignee: (was: Arthur Naseef) > KahaDB not cleaning up log files > > > Key: AMQ-5695 > URL: https://issues.apache.org/jira/browse/AMQ-5695 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.11.1 >Reporter: Stefan Warten > > Since we have upgraded ActiveMQ from 5.10.0 to 5.11.1, KahaDB is not cleaning > up log files properly. It seems to keep all of them. It helped once to > restart the service and minutes later, ActiveMQ cleaned up 95% of log files > but mostly it is not cleaning up at all. > When partition was full, I stopped ActiveMQ, copied the KahaDB to another > host and started it with empty queues again. Then I forwarded all messages > from that other host back. Even when all messages were forwarded and all > queues were empty, the old KahaDB log files were not cleaned up. > I stopped ActiveMQ, removed db.data and db.redo to rebuild index which took > around 3h (350GB of log files) but still, the log files are not cleaned up. > [...] > 2015-03-30 18:21:55,532 | INFO | @13786:158508, 32130 entries recovered > .. | org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain > 2015-03-30 18:22:02,090 | INFO | Recovery replayed 321378917 operations from > the journal in 9226.159 seconds. | > org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain > 2015-03-30 18:22:02,402 | INFO | installing runtimeConfiguration plugin | > org.apache.activemq.plugin.RuntimeConfigurationPlugin | WrapperSimpleAppMain > 2015-03-30 18:22:04,576 | INFO | Apache ActiveMQ 5.11.1 > (prd-mig-02-sat.example.com, > ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) is starting | > org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain > 2015-03-30 18:22:04,946 | INFO | pending local transactions: [] | > org.apache.activemq.store.kahadb.MultiKahaDBTransactionStore | > WrapperSimpleAppMain > 2015-03-30 18:22:08,488 | INFO | Configuration class path resource > [activemq.xml] | org.apache.activemq.plugin.RuntimeConfigurationBroker | > WrapperSimpleAppMain > 2015-03-30 18:22:12,198 | INFO | Listening for connections at: > nio://prd-mig-02-sat.example.com:61616?transport.reuseAddress=true | > org.apache.activemq.transport.TransportServerThreadSupport | > WrapperSimpleAppMain > 2015-03-30 18:22:12,199 | INFO | Connector openwire started | > org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain > 2015-03-30 18:22:12,232 | INFO | Listening for connections at: > stomp+nio://prd-mig-02-sat.example.com:61613?transport.closeAsync=false=true > | org.apache.activemq.transport.TransportServerThreadSupport | > WrapperSimpleAppMain > 2015-03-30 18:22:12,234 | INFO | Connector stomp started | > org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain > 2015-03-30 18:22:12,237 | INFO | Establishing network connection from > vm://prd-mig-02-sat.example.com?async=false=true to > tcp://172.42.15.40:61616 | > org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain > 2015-03-30 18:22:12,286 | INFO | Connector vm://prd-mig-02-sat.example.com > started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain > 2015-03-30 18:22:12,318 | INFO | Establishing network connection from > vm://prd-mig-02-sat.example.com?async=false=true to > tcp://172.42.15.39:61616 | > org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain > 2015-03-30 18:22:12,321 | INFO | Network Connector > DiscoveryNetworkConnector:FORWARDER:BrokerService[prd-mig-02-sat.example.com] > started | org.apache.activemq.network.NetworkConnector | WrapperSimpleAppMain > 2015-03-30 18:22:12,325 | INFO | Apache ActiveMQ 5.11.1 > (prd-mig-02-sat.example.com, > ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) started | > org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain > 2015-03-30 18:22:12,326 | INFO | For help or more information please see: > http://activemq.apache.org | org.apache.activemq.broker.BrokerService | > WrapperSimpleAppMain > 2015-03-30 18:22:12,381 | INFO | Network connection between > vm://prd-mig-02-sat.example.com#0 and tcp:///172.42.15.40:61616@58567 > (prdvip-amq-01-sat.example.com) has been established. | > org.apache.activemq.network.DemandForwardingBridgeSupport | > triggerStartAsyncNetworkBridgeCreation: > remoteBroker=tcp:///172.42.15.40:61616@58567, localBroker= > vm://prd-mig-02-sat.example.com#0 > 2015-03-30 18:22:12,381 | INFO | Network connection between > vm://prd-mig-02-sat.example.com#2 and tcp:///172.42.15.39:61616@4523 > (prdvip-amq-02-sat.example.com) has been established. | > org.apache.activemq.network.DemandForwardingBridgeSupport | >
[jira] [Updated] (AMQ-5695) KahaDB not cleaning up log files
[ https://issues.apache.org/jira/browse/AMQ-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arthur Naseef updated AMQ-5695: --- Priority: Blocker (was: Major) > KahaDB not cleaning up log files > > > Key: AMQ-5695 > URL: https://issues.apache.org/jira/browse/AMQ-5695 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.11.1 >Reporter: Stefan Warten >Priority: Blocker > > Since we have upgraded ActiveMQ from 5.10.0 to 5.11.1, KahaDB is not cleaning > up log files properly. It seems to keep all of them. It helped once to > restart the service and minutes later, ActiveMQ cleaned up 95% of log files > but mostly it is not cleaning up at all. > When partition was full, I stopped ActiveMQ, copied the KahaDB to another > host and started it with empty queues again. Then I forwarded all messages > from that other host back. Even when all messages were forwarded and all > queues were empty, the old KahaDB log files were not cleaned up. > I stopped ActiveMQ, removed db.data and db.redo to rebuild index which took > around 3h (350GB of log files) but still, the log files are not cleaned up. > [...] > 2015-03-30 18:21:55,532 | INFO | @13786:158508, 32130 entries recovered > .. | org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain > 2015-03-30 18:22:02,090 | INFO | Recovery replayed 321378917 operations from > the journal in 9226.159 seconds. | > org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain > 2015-03-30 18:22:02,402 | INFO | installing runtimeConfiguration plugin | > org.apache.activemq.plugin.RuntimeConfigurationPlugin | WrapperSimpleAppMain > 2015-03-30 18:22:04,576 | INFO | Apache ActiveMQ 5.11.1 > (prd-mig-02-sat.example.com, > ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) is starting | > org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain > 2015-03-30 18:22:04,946 | INFO | pending local transactions: [] | > org.apache.activemq.store.kahadb.MultiKahaDBTransactionStore | > WrapperSimpleAppMain > 2015-03-30 18:22:08,488 | INFO | Configuration class path resource > [activemq.xml] | org.apache.activemq.plugin.RuntimeConfigurationBroker | > WrapperSimpleAppMain > 2015-03-30 18:22:12,198 | INFO | Listening for connections at: > nio://prd-mig-02-sat.example.com:61616?transport.reuseAddress=true | > org.apache.activemq.transport.TransportServerThreadSupport | > WrapperSimpleAppMain > 2015-03-30 18:22:12,199 | INFO | Connector openwire started | > org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain > 2015-03-30 18:22:12,232 | INFO | Listening for connections at: > stomp+nio://prd-mig-02-sat.example.com:61613?transport.closeAsync=false=true > | org.apache.activemq.transport.TransportServerThreadSupport | > WrapperSimpleAppMain > 2015-03-30 18:22:12,234 | INFO | Connector stomp started | > org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain > 2015-03-30 18:22:12,237 | INFO | Establishing network connection from > vm://prd-mig-02-sat.example.com?async=false=true to > tcp://172.42.15.40:61616 | > org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain > 2015-03-30 18:22:12,286 | INFO | Connector vm://prd-mig-02-sat.example.com > started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain > 2015-03-30 18:22:12,318 | INFO | Establishing network connection from > vm://prd-mig-02-sat.example.com?async=false=true to > tcp://172.42.15.39:61616 | > org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain > 2015-03-30 18:22:12,321 | INFO | Network Connector > DiscoveryNetworkConnector:FORWARDER:BrokerService[prd-mig-02-sat.example.com] > started | org.apache.activemq.network.NetworkConnector | WrapperSimpleAppMain > 2015-03-30 18:22:12,325 | INFO | Apache ActiveMQ 5.11.1 > (prd-mig-02-sat.example.com, > ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) started | > org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain > 2015-03-30 18:22:12,326 | INFO | For help or more information please see: > http://activemq.apache.org | org.apache.activemq.broker.BrokerService | > WrapperSimpleAppMain > 2015-03-30 18:22:12,381 | INFO | Network connection between > vm://prd-mig-02-sat.example.com#0 and tcp:///172.42.15.40:61616@58567 > (prdvip-amq-01-sat.example.com) has been established. | > org.apache.activemq.network.DemandForwardingBridgeSupport | > triggerStartAsyncNetworkBridgeCreation: > remoteBroker=tcp:///172.42.15.40:61616@58567, localBroker= > vm://prd-mig-02-sat.example.com#0 > 2015-03-30 18:22:12,381 | INFO | Network connection between > vm://prd-mig-02-sat.example.com#2 and tcp:///172.42.15.39:61616@4523 > (prdvip-amq-02-sat.example.com) has been established. | >
[jira] [Commented] (AMQ-4264) ActiveMQ dying with exception detected missing/corrupt journal files
[ https://issues.apache.org/jira/browse/AMQ-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715254#comment-14715254 ] Arthur Naseef commented on AMQ-4264: Hey Tim - can you provide a link to a public version of that KahaDB-Recovery.html Fuse documentation? I get a generic RedHat product documentation page with that link. ActiveMQ dying with exception detected missing/corrupt journal files Key: AMQ-4264 URL: https://issues.apache.org/jira/browse/AMQ-4264 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.6.0 Environment: linux Reporter: Bhanu Hi, Yesterday, our ActiveMQ broker suddenly died with the exception pasted below. It failed to come up on repeated attempts and we could only bring it back after clearing the kahadb data and redo files. We havent seen this issue in the past. Can you suggest some pointers here on why this would have happened suddenly? Is this a known issue which is going to be fixed in future versions ? ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in URL [file:/prod/tools/base/etc/config/activemq/amq_prod_broker_config.xml]: Invocation of init method failed; nested exception is java.io.IOException: Detected missing/corrupt journal files. 124512 messages affected. java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in URL [file:/prod/tools/base/etc/config/activemq/amq_prod_broker_config.xml]: Invocation of init method failed; nested exception is java.io.IOException: Detected missing/corrupt journal files. 124512 messages affected. at org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:98) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57) at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:148) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57) at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:90) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.activemq.console.Main.runTaskClass(Main.java:257) at org.apache.activemq.console.Main.main(Main.java:111) Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in URL [file:/prod/tools/base/etc/config/activemq/amq_prod_broker_config.xml]: Invocation of init method failed; nested exception is java.io.IOException: Detected missing/corrupt journal files. 124512 messages affected. at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1420) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.init(ResourceXmlApplicationContext.java:64) at
[jira] [Closed] (AMQ-5903) Message headers are lost when using the Broker Component for Camel
[ https://issues.apache.org/jira/browse/AMQ-5903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arthur Naseef closed AMQ-5903. -- Resolution: Fixed Fix Version/s: 5.12.0 Closing with thanks to Heath Kesler Message headers are lost when using the Broker Component for Camel -- Key: AMQ-5903 URL: https://issues.apache.org/jira/browse/AMQ-5903 Project: ActiveMQ Issue Type: Bug Components: activemq-camel Affects Versions: 5.11.1 Reporter: Heath Kesler Fix For: 5.12.0 Attachments: amq-5903.patch When using the broker camel component as defined here: http://activemq.apache.org/broker-camel-component.html There appears to be an undocumented limitation of the broker component's current implementation. I need to know whether said limitation is by design or an oversight. If it's an oversight then I can submit a patch for it. This example route does not work as expected - the JMSXGroupID header is lost when received by the broker component. route from uri=broker:queue:test/ setHeader headerName=JMSXGroupID constant123/constant /setHeader to uri=broker:queue:test/ /route After single stepping with a debugger the component executes this code: https://github.com/apache/activemq/blob/master/activemq-camel/src/main/java/org/apache/activemq/camel/component/broker/BrokerProducer.java#L102 As you can see from the method's implementation it only copies over a fixed set of six well-known headers. All other headers on the inbound message are discarded. Why not copy over every header? Consequently the JMSXGroupID header is not copied, despite being present on the inbound message. This would appear to be a bug in my opinion as I do not believe we should be loosing any headers on a message in this case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5224) XA pooled connection factories are not recoverable
[
https://issues.apache.org/jira/browse/AMQ-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635349#comment-14635349
]
Arthur Naseef commented on AMQ-5224:
This change breaks backward compatibility by changing the signature of the
public method. Here is one example impact:
{noformat}
Error during dispatch. (java.lang.NoSuchMethodError:
org.apache.activemq.jms.pool.PooledConnectionFactory.setConnectionFactory(Ljavax/jms/ConnectionFactory;)V)
java.lang.NoSuchMethodError:
org.apache.activemq.jms.pool.PooledConnectionFactory.setConnectionFactory(Ljavax/jms/ConnectionFactory;)V
{noformat}
It seems to me that rather than changing the appropriate method signature
taking a {{ConnectionFactory}} to accepting any {{Object}} because some
XAConnectionFactory implementations do not properly implement
{{ConnectionFactory}} is a bad way to go - introducing complexity where it is
unneeded. It would be far simpler to wrap those XAConnectionFactory with thin
ConnectionFactory implementations.
Anyway, the damage is done here - if we change the signature back, another
non-backward-compatible change will be introduced.
Please consider all the impacts of these changes, especially since we do not
have plans to bump the ActiveMQ major version number.
XA pooled connection factories are not recoverable
--
Key: AMQ-5224
URL: https://issues.apache.org/jira/browse/AMQ-5224
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.9.1, 5.10.0
Reporter: Guillaume Nodet
Fix For: 5.11.0
PooledConnectionFactory#setConnectionFactory hides the XAConnectionFactory
interface which is used by the resource manager.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5695) KahaDB not cleaning up log files
[ https://issues.apache.org/jira/browse/AMQ-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14592975#comment-14592975 ] Arthur Naseef commented on AMQ-5695: CORRECTION: the destination holding the first data file was not the same one in the error message - the latter contained the former, hence the mis-identification. KahaDB not cleaning up log files Key: AMQ-5695 URL: https://issues.apache.org/jira/browse/AMQ-5695 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.11.1 Reporter: Stefan Warten Assignee: Arthur Naseef Since we have upgraded ActiveMQ from 5.10.0 to 5.11.1, KahaDB is not cleaning up log files properly. It seems to keep all of them. It helped once to restart the service and minutes later, ActiveMQ cleaned up 95% of log files but mostly it is not cleaning up at all. When partition was full, I stopped ActiveMQ, copied the KahaDB to another host and started it with empty queues again. Then I forwarded all messages from that other host back. Even when all messages were forwarded and all queues were empty, the old KahaDB log files were not cleaned up. I stopped ActiveMQ, removed db.data and db.redo to rebuild index which took around 3h (350GB of log files) but still, the log files are not cleaned up. [...] 2015-03-30 18:21:55,532 | INFO | @13786:158508, 32130 entries recovered .. | org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain 2015-03-30 18:22:02,090 | INFO | Recovery replayed 321378917 operations from the journal in 9226.159 seconds. | org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain 2015-03-30 18:22:02,402 | INFO | installing runtimeConfiguration plugin | org.apache.activemq.plugin.RuntimeConfigurationPlugin | WrapperSimpleAppMain 2015-03-30 18:22:04,576 | INFO | Apache ActiveMQ 5.11.1 (prd-mig-02-sat.example.com, ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) is starting | org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain 2015-03-30 18:22:04,946 | INFO | pending local transactions: [] | org.apache.activemq.store.kahadb.MultiKahaDBTransactionStore | WrapperSimpleAppMain 2015-03-30 18:22:08,488 | INFO | Configuration class path resource [activemq.xml] | org.apache.activemq.plugin.RuntimeConfigurationBroker | WrapperSimpleAppMain 2015-03-30 18:22:12,198 | INFO | Listening for connections at: nio://prd-mig-02-sat.example.com:61616?transport.reuseAddress=true | org.apache.activemq.transport.TransportServerThreadSupport | WrapperSimpleAppMain 2015-03-30 18:22:12,199 | INFO | Connector openwire started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,232 | INFO | Listening for connections at: stomp+nio://prd-mig-02-sat.example.com:61613?transport.closeAsync=falsetransport.reuseAddress=true | org.apache.activemq.transport.TransportServerThreadSupport | WrapperSimpleAppMain 2015-03-30 18:22:12,234 | INFO | Connector stomp started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,237 | INFO | Establishing network connection from vm://prd-mig-02-sat.example.com?async=falsenetwork=true to tcp://172.42.15.40:61616 | org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,286 | INFO | Connector vm://prd-mig-02-sat.example.com started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,318 | INFO | Establishing network connection from vm://prd-mig-02-sat.example.com?async=falsenetwork=true to tcp://172.42.15.39:61616 | org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,321 | INFO | Network Connector DiscoveryNetworkConnector:FORWARDER:BrokerService[prd-mig-02-sat.example.com] started | org.apache.activemq.network.NetworkConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,325 | INFO | Apache ActiveMQ 5.11.1 (prd-mig-02-sat.example.com, ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) started | org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain 2015-03-30 18:22:12,326 | INFO | For help or more information please see: http://activemq.apache.org | org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain 2015-03-30 18:22:12,381 | INFO | Network connection between vm://prd-mig-02-sat.example.com#0 and tcp:///172.42.15.40:61616@58567 (prdvip-amq-01-sat.example.com) has been established. | org.apache.activemq.network.DemandForwardingBridgeSupport | triggerStartAsyncNetworkBridgeCreation: remoteBroker=tcp:///172.42.15.40:61616@58567, localBroker= vm://prd-mig-02-sat.example.com#0 2015-03-30 18:22:12,381 | INFO | Network connection between
[jira] [Commented] (AMQ-5695) KahaDB not cleaning up log files
[
https://issues.apache.org/jira/browse/AMQ-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14592176#comment-14592176
]
Arthur Naseef commented on AMQ-5695:
When this problem occurs, do you see the journal files in the kahadb folder are
all sequential?
Also, in what state are the destinations? Are there any queues, or durable
topic subscriptions, with old messages sitting around?
BTW, the following log setting will get more details (it does generate a lot of
output when there are a lot of files):
{{log4j.logger.org.apache.activemq.store.kahadb.MessageDatabase=TRACE}}
KahaDB not cleaning up log files
Key: AMQ-5695
URL: https://issues.apache.org/jira/browse/AMQ-5695
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.11.1
Reporter: Stefan Warten
Since we have upgraded ActiveMQ from 5.10.0 to 5.11.1, KahaDB is not cleaning
up log files properly. It seems to keep all of them. It helped once to
restart the service and minutes later, ActiveMQ cleaned up 95% of log files
but mostly it is not cleaning up at all.
When partition was full, I stopped ActiveMQ, copied the KahaDB to another
host and started it with empty queues again. Then I forwarded all messages
from that other host back. Even when all messages were forwarded and all
queues were empty, the old KahaDB log files were not cleaned up.
I stopped ActiveMQ, removed db.data and db.redo to rebuild index which took
around 3h (350GB of log files) but still, the log files are not cleaned up.
[...]
2015-03-30 18:21:55,532 | INFO | @13786:158508, 32130 entries recovered
.. | org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain
2015-03-30 18:22:02,090 | INFO | Recovery replayed 321378917 operations from
the journal in 9226.159 seconds. |
org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain
2015-03-30 18:22:02,402 | INFO | installing runtimeConfiguration plugin |
org.apache.activemq.plugin.RuntimeConfigurationPlugin | WrapperSimpleAppMain
2015-03-30 18:22:04,576 | INFO | Apache ActiveMQ 5.11.1
(prd-mig-02-sat.example.com,
ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) is starting |
org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
2015-03-30 18:22:04,946 | INFO | pending local transactions: [] |
org.apache.activemq.store.kahadb.MultiKahaDBTransactionStore |
WrapperSimpleAppMain
2015-03-30 18:22:08,488 | INFO | Configuration class path resource
[activemq.xml] | org.apache.activemq.plugin.RuntimeConfigurationBroker |
WrapperSimpleAppMain
2015-03-30 18:22:12,198 | INFO | Listening for connections at:
nio://prd-mig-02-sat.example.com:61616?transport.reuseAddress=true |
org.apache.activemq.transport.TransportServerThreadSupport |
WrapperSimpleAppMain
2015-03-30 18:22:12,199 | INFO | Connector openwire started |
org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain
2015-03-30 18:22:12,232 | INFO | Listening for connections at:
stomp+nio://prd-mig-02-sat.example.com:61613?transport.closeAsync=falsetransport.reuseAddress=true
| org.apache.activemq.transport.TransportServerThreadSupport |
WrapperSimpleAppMain
2015-03-30 18:22:12,234 | INFO | Connector stomp started |
org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain
2015-03-30 18:22:12,237 | INFO | Establishing network connection from
vm://prd-mig-02-sat.example.com?async=falsenetwork=true to
tcp://172.42.15.40:61616 |
org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain
2015-03-30 18:22:12,286 | INFO | Connector vm://prd-mig-02-sat.example.com
started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain
2015-03-30 18:22:12,318 | INFO | Establishing network connection from
vm://prd-mig-02-sat.example.com?async=falsenetwork=true to
tcp://172.42.15.39:61616 |
org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain
2015-03-30 18:22:12,321 | INFO | Network Connector
DiscoveryNetworkConnector:FORWARDER:BrokerService[prd-mig-02-sat.example.com]
started | org.apache.activemq.network.NetworkConnector | WrapperSimpleAppMain
2015-03-30 18:22:12,325 | INFO | Apache ActiveMQ 5.11.1
(prd-mig-02-sat.example.com,
ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) started |
org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
2015-03-30 18:22:12,326 | INFO | For help or more information please see:
http://activemq.apache.org | org.apache.activemq.broker.BrokerService |
WrapperSimpleAppMain
2015-03-30 18:22:12,381 | INFO | Network connection between
vm://prd-mig-02-sat.example.com#0 and tcp:///172.42.15.40:61616@58567
(prdvip-amq-01-sat.example.com) has been established. |
org.apache.activemq.network.DemandForwardingBridgeSupport |
[jira] [Commented] (AMQ-5695) KahaDB not cleaning up log files
[ https://issues.apache.org/jira/browse/AMQ-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14592196#comment-14592196 ] Arthur Naseef commented on AMQ-5695: This issue may have been introduced by the fix for AMQ-5542. KahaDB not cleaning up log files Key: AMQ-5695 URL: https://issues.apache.org/jira/browse/AMQ-5695 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.11.1 Reporter: Stefan Warten Assignee: Arthur Naseef Since we have upgraded ActiveMQ from 5.10.0 to 5.11.1, KahaDB is not cleaning up log files properly. It seems to keep all of them. It helped once to restart the service and minutes later, ActiveMQ cleaned up 95% of log files but mostly it is not cleaning up at all. When partition was full, I stopped ActiveMQ, copied the KahaDB to another host and started it with empty queues again. Then I forwarded all messages from that other host back. Even when all messages were forwarded and all queues were empty, the old KahaDB log files were not cleaned up. I stopped ActiveMQ, removed db.data and db.redo to rebuild index which took around 3h (350GB of log files) but still, the log files are not cleaned up. [...] 2015-03-30 18:21:55,532 | INFO | @13786:158508, 32130 entries recovered .. | org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain 2015-03-30 18:22:02,090 | INFO | Recovery replayed 321378917 operations from the journal in 9226.159 seconds. | org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain 2015-03-30 18:22:02,402 | INFO | installing runtimeConfiguration plugin | org.apache.activemq.plugin.RuntimeConfigurationPlugin | WrapperSimpleAppMain 2015-03-30 18:22:04,576 | INFO | Apache ActiveMQ 5.11.1 (prd-mig-02-sat.example.com, ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) is starting | org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain 2015-03-30 18:22:04,946 | INFO | pending local transactions: [] | org.apache.activemq.store.kahadb.MultiKahaDBTransactionStore | WrapperSimpleAppMain 2015-03-30 18:22:08,488 | INFO | Configuration class path resource [activemq.xml] | org.apache.activemq.plugin.RuntimeConfigurationBroker | WrapperSimpleAppMain 2015-03-30 18:22:12,198 | INFO | Listening for connections at: nio://prd-mig-02-sat.example.com:61616?transport.reuseAddress=true | org.apache.activemq.transport.TransportServerThreadSupport | WrapperSimpleAppMain 2015-03-30 18:22:12,199 | INFO | Connector openwire started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,232 | INFO | Listening for connections at: stomp+nio://prd-mig-02-sat.example.com:61613?transport.closeAsync=falsetransport.reuseAddress=true | org.apache.activemq.transport.TransportServerThreadSupport | WrapperSimpleAppMain 2015-03-30 18:22:12,234 | INFO | Connector stomp started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,237 | INFO | Establishing network connection from vm://prd-mig-02-sat.example.com?async=falsenetwork=true to tcp://172.42.15.40:61616 | org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,286 | INFO | Connector vm://prd-mig-02-sat.example.com started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,318 | INFO | Establishing network connection from vm://prd-mig-02-sat.example.com?async=falsenetwork=true to tcp://172.42.15.39:61616 | org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,321 | INFO | Network Connector DiscoveryNetworkConnector:FORWARDER:BrokerService[prd-mig-02-sat.example.com] started | org.apache.activemq.network.NetworkConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,325 | INFO | Apache ActiveMQ 5.11.1 (prd-mig-02-sat.example.com, ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) started | org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain 2015-03-30 18:22:12,326 | INFO | For help or more information please see: http://activemq.apache.org | org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain 2015-03-30 18:22:12,381 | INFO | Network connection between vm://prd-mig-02-sat.example.com#0 and tcp:///172.42.15.40:61616@58567 (prdvip-amq-01-sat.example.com) has been established. | org.apache.activemq.network.DemandForwardingBridgeSupport | triggerStartAsyncNetworkBridgeCreation: remoteBroker=tcp:///172.42.15.40:61616@58567, localBroker= vm://prd-mig-02-sat.example.com#0 2015-03-30 18:22:12,381 | INFO | Network connection between vm://prd-mig-02-sat.example.com#2 and tcp:///172.42.15.39:61616@4523 (prdvip-amq-02-sat.example.com) has been established. |
[jira] [Commented] (AMQ-5695) KahaDB not cleaning up log files
[ https://issues.apache.org/jira/browse/AMQ-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14592408#comment-14592408 ] Arthur Naseef commented on AMQ-5695: May relate to AMQ-5394; unclear right now. KahaDB not cleaning up log files Key: AMQ-5695 URL: https://issues.apache.org/jira/browse/AMQ-5695 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.11.1 Reporter: Stefan Warten Assignee: Arthur Naseef Since we have upgraded ActiveMQ from 5.10.0 to 5.11.1, KahaDB is not cleaning up log files properly. It seems to keep all of them. It helped once to restart the service and minutes later, ActiveMQ cleaned up 95% of log files but mostly it is not cleaning up at all. When partition was full, I stopped ActiveMQ, copied the KahaDB to another host and started it with empty queues again. Then I forwarded all messages from that other host back. Even when all messages were forwarded and all queues were empty, the old KahaDB log files were not cleaned up. I stopped ActiveMQ, removed db.data and db.redo to rebuild index which took around 3h (350GB of log files) but still, the log files are not cleaned up. [...] 2015-03-30 18:21:55,532 | INFO | @13786:158508, 32130 entries recovered .. | org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain 2015-03-30 18:22:02,090 | INFO | Recovery replayed 321378917 operations from the journal in 9226.159 seconds. | org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain 2015-03-30 18:22:02,402 | INFO | installing runtimeConfiguration plugin | org.apache.activemq.plugin.RuntimeConfigurationPlugin | WrapperSimpleAppMain 2015-03-30 18:22:04,576 | INFO | Apache ActiveMQ 5.11.1 (prd-mig-02-sat.example.com, ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) is starting | org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain 2015-03-30 18:22:04,946 | INFO | pending local transactions: [] | org.apache.activemq.store.kahadb.MultiKahaDBTransactionStore | WrapperSimpleAppMain 2015-03-30 18:22:08,488 | INFO | Configuration class path resource [activemq.xml] | org.apache.activemq.plugin.RuntimeConfigurationBroker | WrapperSimpleAppMain 2015-03-30 18:22:12,198 | INFO | Listening for connections at: nio://prd-mig-02-sat.example.com:61616?transport.reuseAddress=true | org.apache.activemq.transport.TransportServerThreadSupport | WrapperSimpleAppMain 2015-03-30 18:22:12,199 | INFO | Connector openwire started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,232 | INFO | Listening for connections at: stomp+nio://prd-mig-02-sat.example.com:61613?transport.closeAsync=falsetransport.reuseAddress=true | org.apache.activemq.transport.TransportServerThreadSupport | WrapperSimpleAppMain 2015-03-30 18:22:12,234 | INFO | Connector stomp started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,237 | INFO | Establishing network connection from vm://prd-mig-02-sat.example.com?async=falsenetwork=true to tcp://172.42.15.40:61616 | org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,286 | INFO | Connector vm://prd-mig-02-sat.example.com started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,318 | INFO | Establishing network connection from vm://prd-mig-02-sat.example.com?async=falsenetwork=true to tcp://172.42.15.39:61616 | org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,321 | INFO | Network Connector DiscoveryNetworkConnector:FORWARDER:BrokerService[prd-mig-02-sat.example.com] started | org.apache.activemq.network.NetworkConnector | WrapperSimpleAppMain 2015-03-30 18:22:12,325 | INFO | Apache ActiveMQ 5.11.1 (prd-mig-02-sat.example.com, ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) started | org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain 2015-03-30 18:22:12,326 | INFO | For help or more information please see: http://activemq.apache.org | org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain 2015-03-30 18:22:12,381 | INFO | Network connection between vm://prd-mig-02-sat.example.com#0 and tcp:///172.42.15.40:61616@58567 (prdvip-amq-01-sat.example.com) has been established. | org.apache.activemq.network.DemandForwardingBridgeSupport | triggerStartAsyncNetworkBridgeCreation: remoteBroker=tcp:///172.42.15.40:61616@58567, localBroker= vm://prd-mig-02-sat.example.com#0 2015-03-30 18:22:12,381 | INFO | Network connection between vm://prd-mig-02-sat.example.com#2 and tcp:///172.42.15.39:61616@4523 (prdvip-amq-02-sat.example.com) has been established. |
[jira] [Commented] (AMQ-5695) KahaDB not cleaning up log files
[
https://issues.apache.org/jira/browse/AMQ-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14592494#comment-14592494
]
Arthur Naseef commented on AMQ-5695:
The broker configuration with this issue has {{persistJMSRedelivered=true}}.
KahaDB not cleaning up log files
Key: AMQ-5695
URL: https://issues.apache.org/jira/browse/AMQ-5695
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.11.1
Reporter: Stefan Warten
Assignee: Arthur Naseef
Since we have upgraded ActiveMQ from 5.10.0 to 5.11.1, KahaDB is not cleaning
up log files properly. It seems to keep all of them. It helped once to
restart the service and minutes later, ActiveMQ cleaned up 95% of log files
but mostly it is not cleaning up at all.
When partition was full, I stopped ActiveMQ, copied the KahaDB to another
host and started it with empty queues again. Then I forwarded all messages
from that other host back. Even when all messages were forwarded and all
queues were empty, the old KahaDB log files were not cleaned up.
I stopped ActiveMQ, removed db.data and db.redo to rebuild index which took
around 3h (350GB of log files) but still, the log files are not cleaned up.
[...]
2015-03-30 18:21:55,532 | INFO | @13786:158508, 32130 entries recovered
.. | org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain
2015-03-30 18:22:02,090 | INFO | Recovery replayed 321378917 operations from
the journal in 9226.159 seconds. |
org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain
2015-03-30 18:22:02,402 | INFO | installing runtimeConfiguration plugin |
org.apache.activemq.plugin.RuntimeConfigurationPlugin | WrapperSimpleAppMain
2015-03-30 18:22:04,576 | INFO | Apache ActiveMQ 5.11.1
(prd-mig-02-sat.example.com,
ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) is starting |
org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
2015-03-30 18:22:04,946 | INFO | pending local transactions: [] |
org.apache.activemq.store.kahadb.MultiKahaDBTransactionStore |
WrapperSimpleAppMain
2015-03-30 18:22:08,488 | INFO | Configuration class path resource
[activemq.xml] | org.apache.activemq.plugin.RuntimeConfigurationBroker |
WrapperSimpleAppMain
2015-03-30 18:22:12,198 | INFO | Listening for connections at:
nio://prd-mig-02-sat.example.com:61616?transport.reuseAddress=true |
org.apache.activemq.transport.TransportServerThreadSupport |
WrapperSimpleAppMain
2015-03-30 18:22:12,199 | INFO | Connector openwire started |
org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain
2015-03-30 18:22:12,232 | INFO | Listening for connections at:
stomp+nio://prd-mig-02-sat.example.com:61613?transport.closeAsync=falsetransport.reuseAddress=true
| org.apache.activemq.transport.TransportServerThreadSupport |
WrapperSimpleAppMain
2015-03-30 18:22:12,234 | INFO | Connector stomp started |
org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain
2015-03-30 18:22:12,237 | INFO | Establishing network connection from
vm://prd-mig-02-sat.example.com?async=falsenetwork=true to
tcp://172.42.15.40:61616 |
org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain
2015-03-30 18:22:12,286 | INFO | Connector vm://prd-mig-02-sat.example.com
started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain
2015-03-30 18:22:12,318 | INFO | Establishing network connection from
vm://prd-mig-02-sat.example.com?async=falsenetwork=true to
tcp://172.42.15.39:61616 |
org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain
2015-03-30 18:22:12,321 | INFO | Network Connector
DiscoveryNetworkConnector:FORWARDER:BrokerService[prd-mig-02-sat.example.com]
started | org.apache.activemq.network.NetworkConnector | WrapperSimpleAppMain
2015-03-30 18:22:12,325 | INFO | Apache ActiveMQ 5.11.1
(prd-mig-02-sat.example.com,
ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) started |
org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
2015-03-30 18:22:12,326 | INFO | For help or more information please see:
http://activemq.apache.org | org.apache.activemq.broker.BrokerService |
WrapperSimpleAppMain
2015-03-30 18:22:12,381 | INFO | Network connection between
vm://prd-mig-02-sat.example.com#0 and tcp:///172.42.15.40:61616@58567
(prdvip-amq-01-sat.example.com) has been established. |
org.apache.activemq.network.DemandForwardingBridgeSupport |
triggerStartAsyncNetworkBridgeCreation:
remoteBroker=tcp:///172.42.15.40:61616@58567, localBroker=
vm://prd-mig-02-sat.example.com#0
2015-03-30 18:22:12,381 | INFO | Network connection between
vm://prd-mig-02-sat.example.com#2 and tcp:///172.42.15.39:61616@4523
(prdvip-amq-02-sat.example.com) has been
[jira] [Reopened] (AMQ-5582) Queues stop sending to consumers after a threshold
[ https://issues.apache.org/jira/browse/AMQ-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arthur Naseef reopened AMQ-5582: Assignee: Arthur Naseef I'm sorry -- this is expected state of operation? Really? I know selectors tend to be problematic, but until we put a big notice on the front ActiveMQ page that states this limitation exists and will not be fixed, this is not an acceptable response. The JMS specification does not state that selectors only work with small limits on numbers of pending messages. Therefore, ActiveMQ stating it supports the JMS specification is misleading. Queues stop sending to consumers after a threshold -- Key: AMQ-5582 URL: https://issues.apache.org/jira/browse/AMQ-5582 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.10.0 Reporter: Krishna Assignee: Arthur Naseef If a consumer of a queue is consuming based on a selector after about 500 messages the queue stops sending any message to the consumer (even matching messages). I have a standalone test case here. The test case by default uses a VirtualTopic changing it to a queue will exhibit the problem as well. https://bitbucket.org/calvinkrishy/camel-jms-test Discussion in the mailing list: http://activemq.2283324.n4.nabble.com/Consumer-queues-of-virtual-topic-and-the-web-console-td4689995.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
