[jira] [Issue Comment Deleted] (AMQ-5554) Proper support for the blueprint namespace in activemq-blueprint
[
https://issues.apache.org/jira/browse/AMQ-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5554:
-
Comment: was deleted
(was: Thanks you for email. I will be out of the office from 3/5/2015 and
will be returning on 3/22/2015. I will return your email as soon as I return.
Thank you!
)
> Proper support for the blueprint namespace in activemq-blueprint
>
>
> Key: AMQ-5554
> URL: https://issues.apache.org/jira/browse/AMQ-5554
> Project: ActiveMQ
> Issue Type: Improvement
> Components: OSGi/Karaf
>Affects Versions: 5.10.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Daniel Kulp
> Fix For: 5.10.3, 5.11.2
>
> Attachments: broker-blueprint.xml
>
>
> It would be great to support blueprint directly in broker
> when using activemq-blueprint.
> It will allow users to do configuration like:
> {code}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0"/>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5554) Proper support for the blueprint namespace in activemq-blueprint
[
https://issues.apache.org/jira/browse/AMQ-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5554:
-
Affects Version/s: 5.10.0
> Proper support for the blueprint namespace in activemq-blueprint
>
>
> Key: AMQ-5554
> URL: https://issues.apache.org/jira/browse/AMQ-5554
> Project: ActiveMQ
> Issue Type: Improvement
> Components: OSGi/Karaf
>Affects Versions: 5.10.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Daniel Kulp
> Fix For: 5.10.3, 5.11.2
>
> Attachments: broker-blueprint.xml
>
>
> It would be great to support blueprint directly in broker
> when using activemq-blueprint.
> It will allow users to do configuration like:
> {code}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0"/>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQ-5554) Proper support for the blueprint namespace in activemq-blueprint
[
https://issues.apache.org/jira/browse/AMQ-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea resolved AMQ-5554.
--
Resolution: Fixed
Fix Version/s: 5.11.2
5.10.3
This is fixed and released by [~dkulp] in ARIES-1293.
The release version indicate 5.10.3 and 5.11.2, however no changes are required
in ActiveMQ and it will work with earlier versions (it's just that these two
releases come after the aries blueprint.cm 1.0.6 which provides the fix).
In this particular case, to use custom plugins in the activemq
configuration one must use a blueprint-cm version 1.0.6 or newer and use bean
from the blueprint-ext/v1.5.0 namespace, or newer:
{code}
http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.5.0"; ... />
{code}
> Proper support for the blueprint namespace in activemq-blueprint
>
>
> Key: AMQ-5554
> URL: https://issues.apache.org/jira/browse/AMQ-5554
> Project: ActiveMQ
> Issue Type: Improvement
> Components: OSGi/Karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Daniel Kulp
> Fix For: 5.10.3, 5.11.2
>
> Attachments: broker-blueprint.xml
>
>
> It would be great to support blueprint directly in broker
> when using activemq-blueprint.
> It will allow users to do configuration like:
> {code}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0"/>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (AMQ-5554) Proper support for the blueprint namespace in activemq-blueprint
[
https://issues.apache.org/jira/browse/AMQ-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea reassigned AMQ-5554:
Assignee: Daniel Kulp (was: Jean-Baptiste Onofré)
> Proper support for the blueprint namespace in activemq-blueprint
>
>
> Key: AMQ-5554
> URL: https://issues.apache.org/jira/browse/AMQ-5554
> Project: ActiveMQ
> Issue Type: Improvement
> Components: OSGi/Karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Daniel Kulp
> Attachments: broker-blueprint.xml
>
>
> It would be great to support blueprint directly in broker
> when using activemq-blueprint.
> It will allow users to do configuration like:
> {code}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0"/>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5554) Proper support for the blueprint namespace in activemq-blueprint
[
https://issues.apache.org/jira/browse/AMQ-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305541#comment-14305541
]
Hadrian Zbarcea commented on AMQ-5554:
--
Turns out that [~dkulp] suggested a better
[solution|https://issues.apache.org/jira/browse/ARIES-1293].
> Proper support for the blueprint namespace in activemq-blueprint
>
>
> Key: AMQ-5554
> URL: https://issues.apache.org/jira/browse/AMQ-5554
> Project: ActiveMQ
> Issue Type: Improvement
> Components: OSGi/Karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Attachments: broker-blueprint.xml
>
>
> It would be great to support blueprint directly in broker
> when using activemq-blueprint.
> It will allow users to do configuration like:
> {code}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0"/>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5554) Proper support for the blueprint namespace in activemq-blueprint
[
https://issues.apache.org/jira/browse/AMQ-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305346#comment-14305346
]
Hadrian Zbarcea commented on AMQ-5554:
--
I think there are 2 separate issues, this is the simplest one. Steps to
reproduce:
Plain vanilla Karaf (2.3.9 or 2.4.1). Install *only* the activemq-blueprint
feature (otherwise we end up in the 2nd scenario, a bit more complex). ActiveMQ
5.11.0 behaves the same way.
{code}
karaf@root> features:chooseurl activemq 5.10.1
Adding feature url mvn:org.apache.activemq/activemq-karaf/5.10.1/xml/features
karaf@root> features:install activemq-blueprint
karaf@root> features:list | grep activemq
[installed ] [5.10.1 ] activemq-client
activemq-core-5.10.1ActiveMQ client libraries
[installed ] [5.10.1 ] activemq
activemq-core-5.10.1ActiveMQ broker libraries
[uninstalled] [5.10.1 ] activemq-broker-noweb activemq-5.10.1
Full ActiveMQ broker with default configuration
[uninstalled] [5.10.1 ] activemq-broker activemq-5.10.1
Full ActiveMQ broker with default configuration and web console
[uninstalled] [5.10.1 ] activemq-camelactivemq-5.10.1
[uninstalled] [5.10.1 ] activemq-web-console activemq-5.10.1
[installed ] [5.10.1 ] activemq-blueprintactivemq-5.10.1
{code}
>From the console deploy the broker-blueprint.xml (attached to the deploy
>directory. It will work. However, using a custom plugin (uncomment one of the
>two lines) gives different errors. Arguably, using the spring namespace is not
>a smart idea and shouldn't even be attempted.
> Proper support for the blueprint namespace in activemq-blueprint
>
>
> Key: AMQ-5554
> URL: https://issues.apache.org/jira/browse/AMQ-5554
> Project: ActiveMQ
> Issue Type: Improvement
> Components: OSGi/Karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Attachments: broker-blueprint.xml
>
>
> It would be great to support blueprint directly in broker
> when using activemq-blueprint.
> It will allow users to do configuration like:
> {code}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0"/>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5554) Proper support for the blueprint namespace in activemq-blueprint
[
https://issues.apache.org/jira/browse/AMQ-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5554:
-
Attachment: broker-blueprint.xml
> Proper support for the blueprint namespace in activemq-blueprint
>
>
> Key: AMQ-5554
> URL: https://issues.apache.org/jira/browse/AMQ-5554
> Project: ActiveMQ
> Issue Type: Improvement
> Components: OSGi/Karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Attachments: broker-blueprint.xml
>
>
> It would be great to support blueprint directly in broker
> when using activemq-blueprint.
> It will allow users to do configuration like:
> {code}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0"/>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5554) Proper support for the blueprint namespace in activemq-blueprint
[
https://issues.apache.org/jira/browse/AMQ-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305148#comment-14305148
]
Hadrian Zbarcea commented on AMQ-5554:
--
The way this issue was originally formulated targets just the consequence of
another issue (hence the change of the issue title).
Currently, activemq-blueprint exposes a service that allows one to deploy an
activemq broker using blueprint:
{code}
http://activemq.apache.org/schema/core"/>
http://activemq.apache.org/schema/core"/>
{code}
All good, except the last argument points to the *spring* namespace handler.
The side effect is that where extensions are provided inside the
element, as is the case for when we can add a plugin, the bean
should be in the spring namespace and all fails.
After talking to [~jbonofre], we see two solutions:
1. Add a separate namespace for plugins
(http://activemq.apache.org/schema/plugins/{blueprint|spring})
2. Provide spring and blueprint specific activemq-osgi bundles with separate
namespaces (http://activemq.apache.org/schema/{blueprint|spring}, note the
absence of 'plugins'). The spring namespace would be synonymous with 'core' and
core would be supported for a while but deprecated.
The second solution is kinda similar to what we did in camel, except Camel has
its own namespace handler. Our preference would be to go with the 2nd option.
> Proper support for the blueprint namespace in activemq-blueprint
>
>
> Key: AMQ-5554
> URL: https://issues.apache.org/jira/browse/AMQ-5554
> Project: ActiveMQ
> Issue Type: Improvement
> Components: OSGi/Karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>
> It would be great to support blueprint directly in broker
> when using activemq-blueprint.
> It will allow users to do configuration like:
> {code}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0"/>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5554) Proper support for the blueprint namespace in activemq-blueprint
[
https://issues.apache.org/jira/browse/AMQ-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5554:
-
Summary: Proper support for the blueprint namespace in activemq-blueprint
(was: Support blueprint in (activemq-blueprint))
> Proper support for the blueprint namespace in activemq-blueprint
>
>
> Key: AMQ-5554
> URL: https://issues.apache.org/jira/browse/AMQ-5554
> Project: ActiveMQ
> Issue Type: Improvement
> Components: OSGi/Karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>
> It would be great to support blueprint directly in broker
> when using activemq-blueprint.
> It will allow users to do configuration like:
> {code}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0"/>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5250) temp queue not working after long run of activemq
[ https://issues.apache.org/jira/browse/AMQ-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305018#comment-14305018 ] Hadrian Zbarcea commented on AMQ-5250: -- [~ruralhunter] You mention that you wrote a test that you're running via cron. Can you please share that and your broker config? Hopefully we'll bring this to a resolution. Otherwise we'd have to close it for lack of sufficient data. Thanks. > temp queue not working after long run of activemq > - > > Key: AMQ-5250 > URL: https://issues.apache.org/jira/browse/AMQ-5250 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.9.0 >Reporter: Rural Hunter > Fix For: WAITING_FOR_TEST > > > We encounterred a problem when using temp queue for request/reply pattern. It > worked normally but after a long time lets say several weeks, the > applications using temp queue started to report errors: > 2014-06-25 08:25:59 [WARNING] Message back to the server fails！ > javax.jms.InvalidDestinationException: Cannot publish to a deleted > Destination: temp-queue://ID:myserver-45345-1403492084155-1:1:259 > at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1748) > at > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:289) > at > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:224) > at > org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:300) > I created a test application to test the temp when the problem happened and > found this: On each connection, the temp queue worked once and the second > time it failed. I also tried to monitor messages in > ActiveMQ.Advisory.TempQueue. But I could only receive one message after I > subsribed on it everytime. > I checked the activemq log and there was nothing about the problem. Other > applications not using temp queue worked fine. This happened twice in recent > month. I just had to restart activemq to fix it. > I saw a same error in mailing list but not sure if it's the same problem: > http://activemq.2283324.n4.nabble.com/Getting-a-quot-Cannot-publish-to-a-deleted-Destination-quot-but-eventually-works-after-a-couple-of-rs-td4682497.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5565) Need to be able to start/stop brokers in karaf via commands
Hadrian Zbarcea created AMQ-5565: Summary: Need to be able to start/stop brokers in karaf via commands Key: AMQ-5565 URL: https://issues.apache.org/jira/browse/AMQ-5565 Project: ActiveMQ Issue Type: Improvement Components: OSGi/Karaf Affects Versions: 5.11.0, 5.10.1 Reporter: Hadrian Zbarcea Fix For: 5.11.1 Currently one cannot start/stop brokers from karaf. The only way to stop a broker is by stopping the bundle (and then all the jmx beans go away). This is even worse when having multiple brokers; stopping the bundle stops all brokers. We should be able to start/stop them individually. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5552) introduce a smoke-test profile that is enabled by default and during release:prepare
[ https://issues.apache.org/jira/browse/AMQ-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299612#comment-14299612 ] Hadrian Zbarcea commented on AMQ-5552: -- I agree with some of the comments, I am mostly against this proposal. Will try to explain why. I agree for instance that running tests for hours unreliably gives a bad first impression. Quite horrible, I'd think, and not only first impression, second and third too. This proposal only addresses releases from the title of this issue. Time is not a problem as this is a one time excercise. Any entity/company who uses internal builds have no problem running it overnight, however long it takes, as long as the result is pretty much guaranteed. For us as a community is it enough to say that it's a good release it passed the smoke testing? I would say not, the ASF guidelines say the same thing. If the PMC votes an official release, we guarantee that it actually works, which is demonstrated by the tests that pass. Those that don't should be fixed or removed (if they serve no purpose). I understand the need to be pragmatic. However, even if we run the tests with -fae, if tests fail in a , tests in all other modules that depend on it will not be run. Therefore failing tests may hide other failing tests, very hard or impractical to discover. There is another practical reason. At some point, I introduced a regression while merging to a branch. One of the best ways to identify the source is to use git bisect. Given the number of commits I needed some 7 iterations. Now with activemq, where it takes some 10 mins for a build skipping tests, plus running the test(s) you're interested, it would take at least 15-20 min per iteration. While a significant chunk of time, at least it's feasible. If the tests you start with are unreliable, it's a much, much harder effort. There are other arguments, community related. I don't know what would constitute resolution of this issue. In my opinon certainly not something that would be at odds with the ASF guidelines for releases, or at least they way I understand them. > introduce a smoke-test profile that is enabled by default and during > release:prepare > > > Key: AMQ-5552 > URL: https://issues.apache.org/jira/browse/AMQ-5552 > Project: ActiveMQ > Issue Type: Improvement > Components: Distribution, Test Cases >Affects Versions: 5.11.0 >Reporter: Gary Tully > Labels: distribution, mvn, smoke, tests, validation > Fix For: 5.12.0 > > > Users should be able to do $>mvn install on trunk or the source distribution > and get a validated (smoke-tested) distribution in < 10 minutes. > The smoke-test profile should be enabled for release:prepare > At the moment, more than 3k tests are run, they are not reliable enough and > the build is gone for a number of hours. This gives a bad first impression. > Or course we should continue to improve the test suite but this has a totally > different focus. > The smoke-test profile takes a smart cross section of tests in each module > that validate core functionality. > It will be an interesting challenge to get the selection right; balancing > typical use cases with coverage with speed etc. > The tests should be: > * representative of the module functionality > * clean - no hard-coded ports and use only space on target > * fast > * reliable > * can be run in parallel (maybe if it allows more tests to be run in the > same time frame) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQ-5491) Standalone Web console Session timeout with user/password input
[
https://issues.apache.org/jira/browse/AMQ-5491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea resolved AMQ-5491.
--
Resolution: Fixed
Patch applied with thanks to Dumitru Husleag (commit
8dea161d55cd74b10199e26e56e037d85ae451a0)
> Standalone Web console Session timeout with user/password input
> ---
>
> Key: AMQ-5491
> URL: https://issues.apache.org/jira/browse/AMQ-5491
> Project: ActiveMQ
> Issue Type: New Feature
> Components: webconsole
>Affects Versions: 5.11.0
> Environment: Ubuntu 13.10 64Bits
>Reporter: Dumitru HUSLEAG
>Assignee: Hadrian Zbarcea
> Fix For: 5.11.0
>
> Attachments:
> 0001-AMQ-5491-Standalone-Web-console-Session-timeout-with.patch
>
>
> We use the web console as a standalone application deployed on a Jetty
> instance.
> And we need to secure web access to it with ssl and user/password
> authentication.
> We need to have a session timeout and to force re-input of the credentials on
> each session expiry.
> As BASIC authentication does not allow easily to force login again on each
> HTTP session expiration I have to add a login form and a default session
> expiration of 30 minutes.
> I am attaching to this request the git patch proposal containing:
> - a new file login.html (modified copy of 403.html)
> - the modified site.css
> - and the modified web.xml (with extra )
> The Git patch is made on the current 5.11 SNAPSHOT.
> The top commit at the moment I cloned the project from Git on the master
> branch is:
> {quote}
> commit d25c52ccb2c9c23535f9d4488fe8be8600148852
> Author: gtully
> Date: Thu Dec 11 14:40:56 2014 +
> https://issues.apache.org/jira/browse/AMQ-5483 - fix and test - assigned
> group counts are updated when lru map evicts a group assignment
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQ-5505) Add support for the BrokerView MBean to get the up-time in milliseconds
[ https://issues.apache.org/jira/browse/AMQ-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea resolved AMQ-5505. -- Resolution: Fixed PR applied. Thanks [~paulgale] for patch. > Add support for the BrokerView MBean to get the up-time in milliseconds > --- > > Key: AMQ-5505 > URL: https://issues.apache.org/jira/browse/AMQ-5505 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker, JMX >Affects Versions: 5.10.0 >Reporter: Paul Gale >Assignee: Hadrian Zbarcea > Labels: patch > Fix For: 5.11.0 > > > Currently one can only get the broker's up-time as a formatted string via > JMX. > I need to be able to get the up-time in milliseconds as we're using DataDog > as our monitoring tool (which doesn't understand the current up-time > formatted string). > The up-time formatted string will remain as-is. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5505) Add support for the BrokerView MBean to get the up-time in milliseconds
[ https://issues.apache.org/jira/browse/AMQ-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264825#comment-14264825 ] Hadrian Zbarcea commented on AMQ-5505: -- GitHub user PaulGale opened a pull request: https://github.com/apache/activemq/pull/56 Add getUptimeMillis() to the BrokerView MBean I need to be able to get the up-time of the broker in milliseconds, rather than as a formatted string. You can merge this pull request into a Git repository by running: $ git pull https://github.com/PaulGale/activemq trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq/pull/56.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 #56 commit cd98766cab8c701caae0c4f1cbb9988f77ac660c Author: PaulGale Date: 2015-01-05T17:34:00Z Add getUptimeMillis to the BrokerView MBean > Add support for the BrokerView MBean to get the up-time in milliseconds > --- > > Key: AMQ-5505 > URL: https://issues.apache.org/jira/browse/AMQ-5505 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker, JMX >Affects Versions: 5.10.0 >Reporter: Paul Gale >Assignee: Hadrian Zbarcea > Labels: patch > Fix For: 5.11.0 > > > Currently one can only get the broker's up-time as a formatted string via > JMX. > I need to be able to get the up-time in milliseconds as we're using DataDog > as our monitoring tool (which doesn't understand the current up-time > formatted string). > The up-time formatted string will remain as-is. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (AMQ-5505) Add support for the BrokerView MBean to get the up-time in milliseconds
[ https://issues.apache.org/jira/browse/AMQ-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea reassigned AMQ-5505: Assignee: Hadrian Zbarcea > Add support for the BrokerView MBean to get the up-time in milliseconds > --- > > Key: AMQ-5505 > URL: https://issues.apache.org/jira/browse/AMQ-5505 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker, JMX >Affects Versions: 5.10.0 >Reporter: Paul Gale >Assignee: Hadrian Zbarcea > Labels: patch > Fix For: 5.11.0 > > > Currently one can only get the broker's up-time as a formatted string via > JMX. > I need to be able to get the up-time in milliseconds as we're using DataDog > as our monitoring tool (which doesn't understand the current up-time > formatted string). > The up-time formatted string will remain as-is. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (AMQ-5505) Add support for the BrokerView MBean to get the up-time in milliseconds
[ https://issues.apache.org/jira/browse/AMQ-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQ-5505 started by Hadrian Zbarcea. > Add support for the BrokerView MBean to get the up-time in milliseconds > --- > > Key: AMQ-5505 > URL: https://issues.apache.org/jira/browse/AMQ-5505 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker, JMX >Affects Versions: 5.10.0 >Reporter: Paul Gale >Assignee: Hadrian Zbarcea > Labels: patch > Fix For: 5.11.0 > > > Currently one can only get the broker's up-time as a formatted string via > JMX. > I need to be able to get the up-time in milliseconds as we're using DataDog > as our monitoring tool (which doesn't understand the current up-time > formatted string). > The up-time formatted string will remain as-is. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5345) Improve LDAP communication
[ https://issues.apache.org/jira/browse/AMQ-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5345: - Fix Version/s: 5.10.1 > Improve LDAP communication > -- > > Key: AMQ-5345 > URL: https://issues.apache.org/jira/browse/AMQ-5345 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.10.0 >Reporter: Dejan Bosanac >Assignee: Dejan Bosanac > Fix For: 5.10.1, 5.11.0 > > > Various improvement in how we communicate with LDAP -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-3758) Recover scheduler database option
[
https://issues.apache.org/jira/browse/AMQ-3758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-3758:
-
Fix Version/s: (was: 5.10.1)
> Recover scheduler database option
> -
>
> Key: AMQ-3758
> URL: https://issues.apache.org/jira/browse/AMQ-3758
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Message Store
>Affects Versions: 5.5.0
>Reporter: Sergei Sokolov
>Assignee: Timothy Bish
> Labels: scheduler
> Fix For: 5.11.0
>
>
> I am not sure why, but Scheduler database got corrupted, and some messages
> couldn't be delivered to a broker. I got many exceptions similar to:
> {code}
> 2012-03-02 03:26:08,234 | ERROR | JMS Failed to schedule job |
> org.apache.activemq.broker.scheduler.JobSchedulerImpl | JobScheduler:JMS
> java.io.IOException: Could not locate data file \db-2.log
> at org.apache.kahadb.journal.Journal.getDataFile(Journal.java:350)
> at org.apache.kahadb.journal.Journal.read(Journal.java:597)
> at
> org.apache.activemq.broker.scheduler.JobSchedulerStore.getPayload(JobSchedulerStore.java:315)
>
> at
> org.apache.activemq.broker.scheduler.JobSchedulerImpl.fireJob(JobSchedulerImpl.java:421)
>
> at
> org.apache.activemq.broker.scheduler.JobSchedulerImpl.mainLoop(JobSchedulerImpl.java:473)
>
> at
> org.apache.activemq.broker.scheduler.JobSchedulerImpl.run(JobSchedulerImpl.java:429)
>
> at java.lang.Thread.run(Unknown Source)
> {code}
> The problem is that there is no way to restore the database like you can if
> you are working with the main ActiveMQ database. You can fix the main
> database by specifying the following configuration:
> {code}
>
> ignoreMissingJournalfiles="true"
> checkForCorruptJournalFiles="true"
> checksumJournalFiles="true" />
>
> {code}
> It would be nice to have the same feature for the scheduler database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-2870) Messages that don't match a message selector for a durable subscription are stored causing the persistent store to eventually fill up
[ https://issues.apache.org/jira/browse/AMQ-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-2870: - Fix Version/s: (was: 5.10.1) 5.11.0 > Messages that don't match a message selector for a durable subscription are > stored causing the persistent store to eventually fill up > - > > Key: AMQ-2870 > URL: https://issues.apache.org/jira/browse/AMQ-2870 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.3.2 >Reporter: Gary Tully >Assignee: Gary Tully > Fix For: 5.4.1, 5.11.0 > > > With a durable sub, ack entries are created on a message send for each > durable sub, but if the durable sub does not match the message due to a > selector, the message remains unacked, pending, such that is can fill up the > store. Any unmatched message should be acked immediately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-2040) Improve message browsing
[ https://issues.apache.org/jira/browse/AMQ-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-2040: - Fix Version/s: (was: 5.10.1) 5.11.0 > Improve message browsing > > > Key: AMQ-2040 > URL: https://issues.apache.org/jira/browse/AMQ-2040 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.2.0 >Reporter: Dejan Bosanac >Assignee: Dejan Bosanac > Fix For: 5.11.0 > > > Currently the browse() method returns 400 messages (or all if there are less > than that). Allow configuring the number of messages returned and fetching > messages beyond first page with the method such as browse(int page). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-4232) Kahadb does not allow to obtain count of used/free bytes in the storage
[ https://issues.apache.org/jira/browse/AMQ-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4232: - Fix Version/s: (was: 5.10.1) 5.11.0 > Kahadb does not allow to obtain count of used/free bytes in the storage > --- > > Key: AMQ-4232 > URL: https://issues.apache.org/jira/browse/AMQ-4232 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.4.2, 5.7.0 > Environment: fedora15, ubuntu12.10; debian; probably independent >Reporter: Tomáš Martinec > Labels: hangs, kahadb, usage > Fix For: 5.11.0 > > Attachments: extending.kahadb.diff > > > The full story is user forum under title: > Activemq 5.4.2 hangs when the temp disk usage is used > TempUsage.retrieveUsage() always returns the size of the allocated storage > instead of the actual usage. I could not see what methods of kahadb returns > the needed information, so I extended the kahadb interface. > Note that this issue may cause other problems such as AMQ-4136. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5381) ActiveMQBytesMessage mishandles restoration of old message contents
[
https://issues.apache.org/jira/browse/AMQ-5381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5381:
-
Fix Version/s: 5.10.1
> ActiveMQBytesMessage mishandles restoration of old message contents
> ---
>
> Key: AMQ-5381
> URL: https://issues.apache.org/jira/browse/AMQ-5381
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
>Affects Versions: 5.9.1, 5.10.0
>Reporter: Brian D. Johnson
>Assignee: Timothy Bish
> Labels: easyfix
> Fix For: 5.10.1, 5.11.0
>
>
> Changes made in ActiveMQ 5.9.1, AMQ-4887,
> [[cb5c29d02d02dc7f7fa4f5c1a97bd2a59078bccd|https://github.com/apache/activemq/commit/cb5c29d02d02dc7f7fa4f5c1a97bd2a59078bccd#diff-c0b18b235652457c810fe322bce65e31]]
> introduced a bug in {{ActiveMQBytesMessage}} which results in a
> {{java.util.zip.ZipException: incorrect header check}} being thrown at
> {{org.apache.activemq.command.ActiveMQBytesMessage.restoreOldContent(ActiveMQBytesMessage.java:883)}}
> when a consumer attempts to reuse a received {{ActiveMQBytesMessage}}.
> This bug is triggered under a unique set of circumstances:
> # A message is published by a JMS client with compression *_disabled_* on its
> {{ActiveMQConnection}}
> # The message is consumed by a JMS client with compression *_enabled_* on its
> {{ActiveMQConnection}}
> # The JMS consumer makes the received message writable in order to modify and
> reuse it:
> {code}
> message.setReadOnlyProperties(false);
> message.setReadOnlyBody(false);
> {code}
> # The JMS consumer modifies the message, triggering a call to
> {{ActiveMQBytesMessage.initializeWriting()}}
> The problem within {{ActiveMQBytesMessage.initializeWriting()}} is that the
> method determines whether the message should be compressed _when it is
> published_ (based on its current connection) BEFORE it has restored the
> message's original content. In the example above, the message's original
> {{compressed}} flag is changed from {{false}} to {{true}}, resulting in
> {{restoreOldContent()}} trying to decompress message contents which were
> never compressed.
> {code}
> private void initializeWriting() throws JMSException {
> checkReadOnlyBody();
> if (this.dataOut == null) {
> this.bytesOut = new ByteArrayOutputStream();
> OutputStream os = bytesOut;
> this.dataOut = new DataOutputStream(os);
> }
> // should compression be used when publishing this message??
> ActiveMQConnection connection = getConnection();
> if (connection != null && connection.isUseCompression()) {
> compressed = true;
> }
> // restore the message's old content
> restoreOldContent();
> }
> {code}
> -A simple solution would be to move the {{restoreOldContent()}} method call
> before the {{connection.isUseCompression()}} conditional in
> {{ActiveMQBytesMessage.initializeWriting()}}.-
> +Had a chance to look into this problem further. The best fix would be to
> only set the 'compressed' flag when the message's 'contents' are stored,
> instead of whenever the message is initialized for writing.+
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5337) Bug in ConcurrentLinkedQueue leads to excessive CPU-consumption by ActiveMQ process
[ https://issues.apache.org/jira/browse/AMQ-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5337: - Fix Version/s: 5.10.1 > Bug in ConcurrentLinkedQueue leads to excessive CPU-consumption by ActiveMQ > process > --- > > Key: AMQ-5337 > URL: https://issues.apache.org/jira/browse/AMQ-5337 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0, 5.9.1, 5.10.0 > Environment: Linux Ubuntu >Reporter: Wawan > Fix For: 5.10.1, 5.11.0 > > > The AdvisoryBroker use a ConcurrentLinkedQueue to store consumers. > This standard JDK class has a bug which can lead to an OutOfMemory : > https://bugs.openjdk.java.net/browse/JDK-8054446 > In our environment we observe that ActiveMQ process cpu usage is continually > climbing and that the ConcurrentLinkedQueue in the AdvisoryBroker grows > indefinitely. > The ConcurrentLinkedQueue is a non-blocking concurrent FIFO datastructure > provided by the core Java Development Kit API starting from Java 5. > AdvisoryBroker use offer() method to add a new consumer in the > ConcurrentLinkedQueue, and remove() method to remove it. > When the consumer removed is the last element of the queue, the Consumer > object is nulled but a node remain in the queue. The null node is then never > garbage collected. This is true only for the last element of the queue. Any > other element is removed safely. > Related bug : https://issues.apache.org/jira/browse/AMQ-4853 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5323) ActiveMQ Message getProperty and setProperty inconsistent behaviour
[
https://issues.apache.org/jira/browse/AMQ-5323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5323:
-
Fix Version/s: 5.10.1
> ActiveMQ Message getProperty and setProperty inconsistent behaviour
> ---
>
> Key: AMQ-5323
> URL: https://issues.apache.org/jira/browse/AMQ-5323
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
>Affects Versions: 5.10.0
>Reporter: Joao Silva de Melo
>Priority: Trivial
> Fix For: 5.10.1, 5.11.0
>
>
> When you retrieve the JMSDeliveryMode property from an ActiveMQ message, it
> returns either "PERSITENT" or "NON_PERSISTENT".
> However, when using the set property, it only supports either Integer values
> or Boolean values.
> That is why is sensible to support the mapping from the above string
> representation ("PERSITENT" or "NON_PERSISTENT") to integer (1 or 2).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5295) HTTPS Network Connector doesn't work with Mutual authentication- HTTPSClientTransport uses wrong SSLSocketFactory
[
https://issues.apache.org/jira/browse/AMQ-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5295:
-
Fix Version/s: 5.10.1
> HTTPS Network Connector doesn't work with Mutual authentication-
> HTTPSClientTransport uses wrong SSLSocketFactory
> -
>
> Key: AMQ-5295
> URL: https://issues.apache.org/jira/browse/AMQ-5295
> Project: ActiveMQ
> Issue Type: Bug
> Components: Connector
>Affects Versions: 5.9.0
> Environment: JBoss Fuse 6.1
>Reporter: Piotr Klimczak
> Labels: SSL, TLS, mutualSSL
> Fix For: 5.10.1, 5.11.0
>
> Original Estimate: 16h
> Remaining Estimate: 16h
>
> HttpsClientTransport is getting wrong SSLSocketFactory.
> The problem is here:
> {code}
> private SchemeRegistry createSchemeRegistry() {
> SchemeRegistry schemeRegistry = new SchemeRegistry();
> try {
> // register the default socket factory so that it looks at the
> javax.net.ssl.keyStore,
> // javax.net.ssl.trustStore, etc, properties by default
> SSLSocketFactory sslSocketFactory =
> new SSLSocketFactory((javax.net.ssl.SSLSocketFactory)
> javax.net.ssl.SSLSocketFactory.getDefault(),
> SSLSocketFactory.BROWSER_COMPATIBLE_HOSTNAME_VERIFIER);
> schemeRegistry.register(new Scheme("https",
> getRemoteUrl().getPort(), sslSocketFactory));
> return schemeRegistry;
> } catch (Exception e) {
> throw new IllegalStateException("Failure trying to create scheme
> registry", e);
> }
> }
> {code}
> The problem with that code is, that it never take SSLSocketFactory from
> spring context. So the one defined in XML is ignored.
> So it's code have to be replaced with:
> {code}
> private SchemeRegistry createSchemeRegistry() {
> SchemeRegistry schemeRegistry = new SchemeRegistry();
> try {
> // register the default socket factory so that it looks at the
> javax.net.ssl.keyStore,
> // javax.net.ssl.trustStore, etc, properties by default
> SSLSocketFactory sslSocketFactory = createSocketFactory();
> schemeRegistry.register(new Scheme("https",
> getRemoteUrl().getPort(), sslSocketFactory));
> return schemeRegistry;
> } catch (Exception e) {
> throw new IllegalStateException("Failure trying to create scheme
> registry", e);
> }
> }
> {code}
> And then new method should be added:
> {code}
> /**
> * Creates a new SSL SocketFactory. The given factory will use
> user-provided
> * key and trust managers (if the user provided them).
> *
> * @return Newly created (Ssl)SocketFactory.
> * @throws IOException
> */
> protected SocketFactory createSocketFactory() throws IOException {
> if (SslContext.getCurrentSslContext() != null) {
> SslContext ctx = SslContext.getCurrentSslContext();
> try {
> return ctx.getSSLContext().getSocketFactory();
> } catch (Exception e) {
> throw IOExceptionSupport.create(e);
> }
> } else {
> return SSLSocketFactory.getDefault();
> }
> }
> {code}
> This is consistent solution with other transports.
> I will prepare patches and tests for this scenerio.
> Greetings
> Piotr Klimczak
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5315) NullPointerException in DemandForwardingBridgeSupport.collectBrokerInfos
[
https://issues.apache.org/jira/browse/AMQ-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5315:
-
Fix Version/s: 5.10.1
> NullPointerException in DemandForwardingBridgeSupport.collectBrokerInfos
>
>
> Key: AMQ-5315
> URL: https://issues.apache.org/jira/browse/AMQ-5315
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.10.0
>Reporter: Lee Butts
>Priority: Critical
> Fix For: 5.10.1, 5.11.0
>
> Attachments: BridgeNPETest.java
>
>
> We have seen the following NPE setting up a demand forwarding bridge
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.activemq.network.DemandForwardingBridgeSupport.collectBrokerInfos(DemandForwardingBridgeSupport.java:365)
> [activemq-broker-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.network.DemandForwardingBridgeSupport.access$400(DemandForwardingBridgeSupport.java:105)
> [activemq-broker-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.network.DemandForwardingBridgeSupport$5.run(DemandForwardingBridgeSupport.java:331)
> [activemq-broker-5.10.0.jar:5.10.0]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60]
> {code}
> This occurred in one of our tests but only under load so seems to be a race
> condition of some sort.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5220) Advisory messages are still empty when received with a Stomp subscription
[
https://issues.apache.org/jira/browse/AMQ-5220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5220:
-
Fix Version/s: 5.10.1
> Advisory messages are still empty when received with a Stomp subscription
> -
>
> Key: AMQ-5220
> URL: https://issues.apache.org/jira/browse/AMQ-5220
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
>Affects Versions: 5.x
> Environment: ActiveMQ 5.9.1, Sun Java 1.7.0_51, Ubuntu Linux
>Reporter: Vladislav Krakhalev
> Fix For: 5.10.1, 5.11.0
>
>
> The subject of this task similiar as AMQ-2098. Bug still exists, and it can
> be reproduced according to steps below.
> This simple script written in PHP uses standard Stomp client
> {code}
> $stomp = new \Stomp('tcp://localhost:61613', 'admin', 'admin');
> $stomp->subscribe('/topic/stats');
> $stomp->begin($transaction = microtime(true));
> $status = $stomp->send('/queue/ActiveMQ.Statistics.Destination.testqueue',
> '', Array('reply-to' => '/topic/stats', 'persistent' => 'true'));
> $message = $stomp->readFrame();
> $stomp->ack($message->headers['message-id']);
> $stomp->commit($transaction);
> {code}
> And in $message we'll have empty body paramter. It's because ActiveMQ
> returned message without body that's show in a captured packets between
> ActiveMQ and PHP communication below
> {code}
> T 127.0.0.1:53988 -> 127.0.0.1:61613 [AP]
> CONNECT
> login:admin
> passcode:admin
> T 127.0.0.1:53988 -> 127.0.0.1:61613 [AP]
> .
> T 127.0.0.1:61613 -> 127.0.0.1:53988 [AP]
> CONNECTED
> heart-beat:0,0
> session:ID:amneziac-59996-1402320672417-5:8
> server:ActiveMQ/5.9.1
> version:1.0
> .
> T 127.0.0.1:53988 -> 127.0.0.1:61613 [AP]
> SUBSCRIBE
> ack:client
> destination:/topic/stats
> activemq.prefetchSize:1
> T 127.0.0.1:53988 -> 127.0.0.1:61613 [AP]
> .
> T 127.0.0.1:53988 -> 127.0.0.1:61613 [AP]
> BEGIN
> transaction:1402321825.9952
> T 127.0.0.1:53988 -> 127.0.0.1:61613 [AP]
> .
> T 127.0.0.1:53988 -> 127.0.0.1:61613 [AP]
> SEND
> reply-to:/topic/stats
> persistent:true
> destination:/queue/ActiveMQ.Statistics.Destination.testqueue
> T 127.0.0.1:53988 -> 127.0.0.1:61613 [AP]
> .
> T 127.0.0.1:61613 -> 127.0.0.1:53988 [AP]
> MESSAGE
> message-id:ID:amneziac-59996-1402320672417-2:1:0:0:8
> type:Advisory
> destination:/topic/stats
> timestamp:1402321826311
> expires:0
> priority:4
> .
> T 127.0.0.1:53988 -> 127.0.0.1:61613 [AP]
> ACK
> message-id:ID:amneziac-59996-1402320672417-2:1:0:0:8
> T 127.0.0.1:53988 -> 127.0.0.1:61613 [AP]
> .
> T 127.0.0.1:53988 -> 127.0.0.1:61613 [AP]
> COMMIT
> transaction:1402321825.9952
> T 127.0.0.1:53988 -> 127.0.0.1:61613 [AFP]
> .
> DISCONNECT
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5304) groupClass not applied to TempDestinationAuthorizationEntry
[
https://issues.apache.org/jira/browse/AMQ-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5304:
-
Fix Version/s: 5.10.1
> groupClass not applied to TempDestinationAuthorizationEntry
> ---
>
> Key: AMQ-5304
> URL: https://issues.apache.org/jira/browse/AMQ-5304
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.10.0
>Reporter: Torsten Mielke
>Assignee: Torsten Mielke
> Labels: authorization, security
> Fix For: 5.10.1, 5.11.0
>
> Attachments: AMQ-5304.patch
>
>
> When configuring the authorization plugin with a
> that also set a groupClass, this
> groupClass is not properly applied to the TempDestinationAuthorizationEntry
> instance.
> E.g. consider this example config
> {code:xml}
>
>
>groupClass="org.apache.karaf.jaas.boot.principal.RolePrincipal">
>
>admin="client,admin" />
>admin="admin"/>
>read="admin,client" write="admin,client" admin="admin"/>
>
>
> write="client,admin" admin="client,admin"
> groupClass="org.apache.karaf.jaas.boot.principal.RolePrincipal"/>
>
>
>
>
> {code}
> The groupClass attribute is set on the TempDestinationAuthorizationEntry
> instance but we don't apply the groupClass to the AuthorizationEntry by
> calling afterPropertiesSet();
> As a result, authorization fails when trying to create a temp destination.
> This can happen when deploying the broker inside a Karaf container and have
> Karaf do the authentication (such as in JBoss A-MQ).
> The groupClass is properly set on the authorizationEntries within the
> list and only fails to be applied properly on the
> tempDestinationAuthorizationEntry.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5289) Track forwards across a network in destination statistics
[ https://issues.apache.org/jira/browse/AMQ-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5289: - Fix Version/s: 5.10.1 > Track forwards across a network in destination statistics > - > > Key: AMQ-5289 > URL: https://issues.apache.org/jira/browse/AMQ-5289 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.10.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: accounting, destinations, mbean, statistics > Fix For: 5.10.1, 5.11.0 > > > When using message stats for accountability in a broker mesh the forwarding > of messages results in duplicate accounting because the same message is > dequeued multiple times, when forwarded and when consumed. > tracking forwards in the destination statistic means that local consumption > can be captured with dequeueCount - forwardCount -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5198) MessageConsumer and Producer are not thread safe
[
https://issues.apache.org/jira/browse/AMQ-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5198:
-
Fix Version/s: 5.10.1
> MessageConsumer and Producer are not thread safe
>
>
> Key: AMQ-5198
> URL: https://issues.apache.org/jira/browse/AMQ-5198
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.9.0
>Reporter: Enrico Musuruana
> Fix For: 5.10.1, 5.11.0
>
> Attachments: ActiveMq.zip
>
>
> We currently have an object that acts both as a consumer and as a producer
> over the same queue.
> Lazy initialization of the scheduler is not 100% thread safe when a consumer
> and a producer are created sharing the same connection.
> We encountered the following sporadic NPE when a rollback() is invoked:
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.thread.Scheduler.executeAfterDelay(Scheduler.java:64)
> at
> org.apache.activemq.ActiveMQMessageConsumer.rollback(ActiveMQMessageConsumer.java:1278)
> at
> org.apache.activemq.ActiveMQMessageConsumer$5.afterRollback(ActiveMQMessageConsumer.java:1054)
> at
> org.apache.activemq.TransactionContext.afterRollback(TransactionContext.java:157)
> ... 11 more
> We believe that the lazy initialized getScheduler() is open for a race
> condition when a publish and rollback are happening concurrently.
> try {
> result = scheduler = new
> Scheduler("ActiveMQConnection["+info.getConnectionId().getValue()+"]
> Scheduler");
> scheduler.start();
> } catch(Exception e) {
> throw JMSExceptionSupport.create(e);
> }
> The suggested fix is to simply invoke the start within the constructor of the
> Scheduler class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5279) failover redelivery to alternative consumers with pending transaction causes rollback *and* dlq processing
[ https://issues.apache.org/jira/browse/AMQ-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5279: - Fix Version/s: 5.10.1 > failover redelivery to alternative consumers with pending transaction causes > rollback *and* dlq processing > --- > > Key: AMQ-5279 > URL: https://issues.apache.org/jira/browse/AMQ-5279 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.10.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: dlq, failover, redelivery, transaction > Fix For: 5.10.1, 5.11.0 > > > failover isolates the application client from transport failures. For a > single consumer, if there is a pending transaction and an ack is lost the > transaction can still commit after failover if the messages is redispatched. > If it is not redispatched, then the transaction will rollback. > With multiple consumers it is possible that an alternative consumer will get > redelivery. If the alternative consumer is on a different connection the > duplicate dispatch (tracked by a connection) is not identified, redelivery > ensues and the pending transaction rolls back. > If the consumer is on the same connection, the redelivery is treated as a > duplicate, the message gets a poison ack and the pending transaction rolls > back. This is a double whammy and results in a delivery to the DLQ in error. > The redelivery should be routed to the alternative consumer as if it were on > a different connection so that the message can be consumed. > We should DLQ only when the redispatch is not pending on any consumer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5491) Standalone Web console Session timeout with user/password input
[
https://issues.apache.org/jira/browse/AMQ-5491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5491:
-
Fix Version/s: 5.11.0
> Standalone Web console Session timeout with user/password input
> ---
>
> Key: AMQ-5491
> URL: https://issues.apache.org/jira/browse/AMQ-5491
> Project: ActiveMQ
> Issue Type: New Feature
> Components: webconsole
>Affects Versions: 5.11.0
> Environment: Ubuntu 13.10 64Bits
>Reporter: Dumitru HUSLEAG
>Assignee: Hadrian Zbarcea
> Fix For: 5.11.0
>
> Attachments:
> 0001-AMQ-5491-Standalone-Web-console-Session-timeout-with.patch
>
>
> We use the web console as a standalone application deployed on a Jetty
> instance.
> And we need to secure web access to it with ssl and user/password
> authentication.
> We need to have a session timeout and to force re-input of the credentials on
> each session expiry.
> As BASIC authentication does not allow easily to force login again on each
> HTTP session expiration I have to add a login form and a default session
> expiration of 30 minutes.
> I am attaching to this request the git patch proposal containing:
> - a new file login.html (modified copy of 403.html)
> - the modified site.css
> - and the modified web.xml (with extra )
> The Git patch is made on the current 5.11 SNAPSHOT.
> The top commit at the moment I cloned the project from Git on the master
> branch is:
> {quote}
> commit d25c52ccb2c9c23535f9d4488fe8be8600148852
> Author: gtully
> Date: Thu Dec 11 14:40:56 2014 +
> https://issues.apache.org/jira/browse/AMQ-5483 - fix and test - assigned
> group counts are updated when lru map evicts a group assignment
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (AMQ-5491) Standalone Web console Session timeout with user/password input
[
https://issues.apache.org/jira/browse/AMQ-5491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea reassigned AMQ-5491:
Assignee: Hadrian Zbarcea
> Standalone Web console Session timeout with user/password input
> ---
>
> Key: AMQ-5491
> URL: https://issues.apache.org/jira/browse/AMQ-5491
> Project: ActiveMQ
> Issue Type: New Feature
> Components: webconsole
>Affects Versions: 5.11.0
> Environment: Ubuntu 13.10 64Bits
>Reporter: Dumitru HUSLEAG
>Assignee: Hadrian Zbarcea
> Fix For: 5.11.0
>
> Attachments:
> 0001-AMQ-5491-Standalone-Web-console-Session-timeout-with.patch
>
>
> We use the web console as a standalone application deployed on a Jetty
> instance.
> And we need to secure web access to it with ssl and user/password
> authentication.
> We need to have a session timeout and to force re-input of the credentials on
> each session expiry.
> As BASIC authentication does not allow easily to force login again on each
> HTTP session expiration I have to add a login form and a default session
> expiration of 30 minutes.
> I am attaching to this request the git patch proposal containing:
> - a new file login.html (modified copy of 403.html)
> - the modified site.css
> - and the modified web.xml (with extra )
> The Git patch is made on the current 5.11 SNAPSHOT.
> The top commit at the moment I cloned the project from Git on the master
> branch is:
> {quote}
> commit d25c52ccb2c9c23535f9d4488fe8be8600148852
> Author: gtully
> Date: Thu Dec 11 14:40:56 2014 +
> https://issues.apache.org/jira/browse/AMQ-5483 - fix and test - assigned
> group counts are updated when lru map evicts a group assignment
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5277) JDBC ack does not use messageId.entryLocator
[ https://issues.apache.org/jira/browse/AMQ-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5277: - Fix Version/s: 5.10.1 > JDBC ack does not use messageId.entryLocator > > > Key: AMQ-5277 > URL: https://issues.apache.org/jira/browse/AMQ-5277 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, Message Store >Affects Versions: 5.10.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: jdbc, performance > Fix For: 5.10.1, 5.11.0 > > > The jdbc message store was doing a jdbc roundtrip to find the sequence id of > a message before a remove. this information was being retained in the > messageId entryLocator on insert. > However it was not being recreated on a recover and it was lost on a message > ack unless vm transport was in play. > By reusing the entryLocator information there is a ~30% improvement in simple > produce/consume roundrtip tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-3758) Recover scheduler database option
[
https://issues.apache.org/jira/browse/AMQ-3758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-3758:
-
Fix Version/s: 5.10.1
> Recover scheduler database option
> -
>
> Key: AMQ-3758
> URL: https://issues.apache.org/jira/browse/AMQ-3758
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Message Store
>Affects Versions: 5.5.0
>Reporter: Sergei Sokolov
>Assignee: Timothy Bish
> Labels: scheduler
> Fix For: 5.10.1, 5.11.0
>
>
> I am not sure why, but Scheduler database got corrupted, and some messages
> couldn't be delivered to a broker. I got many exceptions similar to:
> {code}
> 2012-03-02 03:26:08,234 | ERROR | JMS Failed to schedule job |
> org.apache.activemq.broker.scheduler.JobSchedulerImpl | JobScheduler:JMS
> java.io.IOException: Could not locate data file \db-2.log
> at org.apache.kahadb.journal.Journal.getDataFile(Journal.java:350)
> at org.apache.kahadb.journal.Journal.read(Journal.java:597)
> at
> org.apache.activemq.broker.scheduler.JobSchedulerStore.getPayload(JobSchedulerStore.java:315)
>
> at
> org.apache.activemq.broker.scheduler.JobSchedulerImpl.fireJob(JobSchedulerImpl.java:421)
>
> at
> org.apache.activemq.broker.scheduler.JobSchedulerImpl.mainLoop(JobSchedulerImpl.java:473)
>
> at
> org.apache.activemq.broker.scheduler.JobSchedulerImpl.run(JobSchedulerImpl.java:429)
>
> at java.lang.Thread.run(Unknown Source)
> {code}
> The problem is that there is no way to restore the database like you can if
> you are working with the main ActiveMQ database. You can fix the main
> database by specifying the following configuration:
> {code}
>
> ignoreMissingJournalfiles="true"
> checkForCorruptJournalFiles="true"
> checksumJournalFiles="true" />
>
> {code}
> It would be nice to have the same feature for the scheduler database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5268) PooledConnectionFactory gets in endless loop when storing into JNDI
[
https://issues.apache.org/jira/browse/AMQ-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5268:
-
Fix Version/s: 5.10.1
> PooledConnectionFactory gets in endless loop when storing into JNDI
> ---
>
> Key: AMQ-5268
> URL: https://issues.apache.org/jira/browse/AMQ-5268
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-pool
>Affects Versions: 5.9.0, 5.9.1, 5.10.0
> Environment: JDK-1.6.0_38, tomcat-naming (JNDI)
>Reporter: Michal Kubricht
>Assignee: Timothy Bish
> Labels: jndi, pool
> Fix For: 5.10.1, 5.11.0
>
> Attachments: AmqJndiReference.java
>
>
> We got into troubles when upgrading from 5.7.0 to new version 5.10.0. One of
> our tests which uses binding of *PooledConnectionFactory* into JNDI
> (tomcat-naming) got *stuck* and computes *in endless loop*.
> Problem is implementation of interface
> {{org.apache.activemq.jndi.JNDIStorableInterface}} in class
> {{org.apache.activemq.pool.PooledConnectionFactory}}:
> - method {{populateProperties(Properties props)}} implementation uses
> {{IntrospectionSupport.getProperties(...)}} in order to set properties for
> all getters,
> - setting properties works for basic types, but causes stack overflow for
> getters - {{getReference()}} and {{getProperties()}} which creates recursion
> loops
> - loop #1: PooledConnectionFactory.getProperties ->
> PooledConnectionFactory.populateProperties ->
> IntrospectionSupport.getProperties -> PooledConnectionFactory.getProperties
> - loop #2: PooledConnectionFactory.getProperties ->
> PooledConnectionFactory.populateProperties ->
> IntrospectionSupport.getProperties -> PooledConnectionFactory.getReference ->
> JNDIReferenceFactory.createReference -> PooledConnectionFactory.getProperties
> - additional info: recursion loop doesn't end with StackOverflowError, but
> InvocationTargetException is propagated to IntrospectionSupport.getProperties
> method where it is being ignored and causes "almost endless" computation
> (exponential complexity)
> Example test without using JNDI, but using key methods showing the problem
> and its possible solution/workaround for AMQ 5.10.0 is attached.
> We found that error exists for AMQ 5.9.0 and newer after resolving following
> issue AMQ-4757.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5265) JMX destination entires fail due to race condition in MBeanBridgeDestination
[ https://issues.apache.org/jira/browse/AMQ-5265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5265: - Fix Version/s: 5.10.1 > JMX destination entires fail due to race condition in MBeanBridgeDestination > > > Key: AMQ-5265 > URL: https://issues.apache.org/jira/browse/AMQ-5265 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.1, 5.10.0 >Reporter: Jeff Genender >Assignee: Dejan Bosanac > Fix For: 5.10.1, 5.11.0 > > Attachments: AMQ-5265.patch > > > JMX statistics on destinations creates a race condition in the > MBeanBridgeDestination's onInboundMessage, onOutboundMessage, and the > purgeInactiveDestinationView task. If the task fires and removes the > objectName while the onInboundMessage or onOutboundMessage fires, it will > spit out warnings of it already being created if multiple threads are > running. The fix is to properly synchronize in the > purgeInactiveDestinationView and also be sure it cleans up itself in the > destinationObjectNameMap. > Patch is attached as is a git pull request (for whatever is easier) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5262) ActiveMQ hangs on shutdown when JMS Bridge is created
[
https://issues.apache.org/jira/browse/AMQ-5262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5262:
-
Fix Version/s: 5.10.1
> ActiveMQ hangs on shutdown when JMS Bridge is created
> -
>
> Key: AMQ-5262
> URL: https://issues.apache.org/jira/browse/AMQ-5262
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.9.0, 5.9.1, 5.10.0
>Reporter: Peter Minearo
>Priority: Minor
> Fix For: 5.10.1, 5.11.0
>
>
> We are having a problem with ActiveMQ hanging on shutdown. Here is the
> scenario, we have a stand alone application that runs an embedded ActiveMQ
> which creates a JMS Queue Bridge via Spring configs. When we call shutdown,
> the TCPTransport that connects the JMS Queue Bridge does not shutdown, it
> hangs on java.net.SocketInputStream.socketRead0().
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:129)
> at
> org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:50)
> at
> org.apache.activemq.transport.tcp.TcpTransport$2.fill(TcpTransport.java:604)
> at
> org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:58)
> at
> org.apache.activemq.transport.tcp.TcpTransport$2.read(TcpTransport.java:589)
> at java.io.DataInputStream.readInt(DataInputStream.java:370)
> at
> org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275)
> at
> org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
> at
> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
> at
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
> Digging around on the forums and the issue tracker, the work around seems to
> add a parameter to the URI (Ex - tcp://localhost:60606?daemon=true).
> According to this StackOverflow posting
> (http://stackoverflow.com/questions/2213340/what-is-daemon-thread-in-java)
> which quotes from Java Concurrency in Practice
> * When a new thread is created it inherits the daemon status of its parent.
> * Normal thread and daemon threads differ in what happens when they exit.
> When the JVM halts any remaining daemon threads are abandoned: **finally
> blocks are not executed**, stacks are not unwound - JVM just exits. Due to
> this reason daemon threads should be used sparingly and it is dangerous to
> use them for tasks that might perform any sort of I/O.
> So, making the Socket that connects the JMS Queue Bridge a Daemon thread,
> seems to be the wrong solution.
> I was trying to debug the initialization of ActiveMQ, and noticed the
> org.apache.activemq.network.jms.JmsConnector class has a stop() method on it.
> I believe this class creates the connection for the JMS Bridge, right? If
> so, the stop method does not seem to shutdown the connection properly.
> {code}
> public void stop() throws Exception {
> if (started.compareAndSet(true, false)) {
> ThreadPoolUtils.shutdown(connectionSerivce);
> connectionSerivce = null;
> for (DestinationBridge bridge : inboundBridges) {
> bridge.stop();
> }
> for (DestinationBridge bridge : outboundBridges) {
> bridge.stop();
> }
> LOG.info("JMS Connector {} stopped", getName());
> }
>
> }
> {code}
> The question I have is why is the stop() method relying on the
> ThreadPoolUtils.shutdown(connectionSerivce) and NOT calling close() on the
> Connections first? For example:
> {code}
> public void stop() throws Exception {
> if (started.compareAndSet(true, false)) {
> foreignConnection.get().close();
> localConnection.get().close();
>
> ThreadPoolUtils.shutdown(connectionSerivce);
> connectionSerivce = null;
> for (DestinationBridge bridge : inboundBridges) {
> bridge.stop();
> }
> for (DestinationBridge bridge : outboundBridges) {
> bridge.stop();
> }
> LOG.info("JMS Connector {} stopped", getName());
> }
>
> }
> {code}
> It was a little difficult to follow the code, so I may be missing something.
> BUT shouldn't the connections close first? Or am I looking in the wrong
> place.
> I have created a small project that creates this scenario.
> https://github.com/pminearo/activemq-shutdown-bug.git
> This was done with ActiveMQ 5.9. Th
[jira] [Updated] (AMQ-5125) Broker and clients hang
[ https://issues.apache.org/jira/browse/AMQ-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5125: - Fix Version/s: 5.10.1 > Broker and clients hang > --- > > Key: AMQ-5125 > URL: https://issues.apache.org/jira/browse/AMQ-5125 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.9.0, 5.10.0 > Environment: Windows 7, Linux > JAVA_HOME=C:\Program Files\Java\jdk1.7.0_07 > ActiveMQ 5.9.0 with LevelDB storage adapter enabled >Reporter: Albert Barmettler >Priority: Blocker > Fix For: 5.10.1, 5.11.0 > > Attachments: > AMQ-5125_made_synchronization_in_LevelDBStore_use_private_lock.5.9.2.patch, > Broker-threaddump-1396544622970.tdump, > Clients-threaddump-1396544622970.tdump, VM.PNG, activemq.xml, > broker-threads-blocked.tdump, src.zip > > > JMS clients start to hang after a while in calls such as > session.createObjectMessage(). Both the broker and the hanging clients can't > be easily shut down when this happens - only forcefully applied kill's do the > job. > I'm using queues and transactional sessions. All clients (producers and > consumers) are in the same Java VM. There is only one JMS connection between > the application and the broker. Each client has its own session, but they all > share the same connection. > Normally, the data directory of the LevelDb contains only a few log files. > But in my case, the number of log files is steadily increasing. > Furthermore, I was able to track down the issue to following circumstance: > The problem only occurs, when consumers do a rollback instead of a commit > when they receive the message. The rollback / redelivery works as expected - > the same message is received again after a previous rollback. > As far as I can tell, the problem does not occur with KahaDb. > I'll attach a test program that provokes the error. It sets up a few hundred > queues, consumers and producers. The consumers just receive the message and > commit the session, but they also do "random" rollbacks. It can be observed > immediately that the number of files starts increasing in the data directory. > After a few minutes, the clients hang - sometimes sooner, sometimes later. > I'll also attach the config file for the broker. > I am aware, that heavy rollbacking should not happen in normal operation. But > from a long term stability perspective, this is a blocker for us. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5258) Connection reference leak in PooledConnectionFactory leading to expired connections stuck in the pool
[
https://issues.apache.org/jira/browse/AMQ-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5258:
-
Fix Version/s: 5.10.1
> Connection reference leak in PooledConnectionFactory leading to expired
> connections stuck in the pool
> -
>
> Key: AMQ-5258
> URL: https://issues.apache.org/jira/browse/AMQ-5258
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-pool
>Affects Versions: 5.9.1, 5.10.0
>Reporter: Sergiy Barlabanov
>Assignee: Timothy Bish
> Fix For: 5.10.1, 5.11.0
>
>
> org.apache.activemq.jms.pool.PooledConnectionFactory creates a connection on
> startup without giving it back to the pool:
> {code:java}
> public void start() {
> LOG.debug("Staring the PooledConnectionFactory: create on start =
> {}", isCreateConnectionOnStartup());
> stopped.set(false);
> if (isCreateConnectionOnStartup()) {
> try {
> // warm the pool by creating a connection during startup
> createConnection();
> } catch (JMSException e) {
> LOG.warn("Create pooled connection during start failed. This
> exception will be ignored.", e);
> }
> }
> }
> {code}
> So no close() method of PooledConnection is called and so no
> decrementReferenceCount is called on ConnectionPool. So referenceCount never
> becomes 0.
> Later on if an exception occurs and hasExpired of ConnectionPool is set to
> true, the connection will not be closed since expiredCheck() method of
> ConnectionPool always compares referenceCount with 0 and does close() only if
> it is 0.
> So we have a dead ConnectionPool instance and all usages result in "XXX
> closed" errors.
> The fix would be to add call to close() just after doing createConnection()
> in PooledConnectionFactory#start() to make referenceCount go to 0. Something
> like this:
> {code:java}
> public void start() {
> LOG.debug("Staring the PooledConnectionFactory: create on start =
> {}", isCreateConnectionOnStartup());
> stopped.set(false);
> if (isCreateConnectionOnStartup()) {
> try {
> // warm the pool by creating a connection during startup
> createConnection().close(); // <--- makes sure referenceCount
> goes to 0
> } catch (JMSException e) {
> LOG.warn("Create pooled connection during start failed. This
> exception will be ignored.", e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5086) vm transport create=false&waitForStart race condition
[
https://issues.apache.org/jira/browse/AMQ-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5086:
-
Fix Version/s: 5.10.1
> vm transport create=false&waitForStart race condition
> -
>
> Key: AMQ-5086
> URL: https://issues.apache.org/jira/browse/AMQ-5086
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.7.0, 5.8.0, 5.9.0
>Reporter: Christian Mamen
> Fix For: 5.10.1, 5.11.0
>
> Attachments: AMQ5086.patch
>
>
> Experience this bug on 5.7.0, I think this is the same on the trunk
> using vm transport for a client to connect to an embedded broker, in a
> multithreaded application, I'm experiencing a an error (sometimes) which
> appears to be a race condition at startup.
> Im using create=false and waitForStart to create a connectionFactory for a
> client connection
> vm://ApplicationName?create=false&waitForStart=12
> The broker service is started in a seperate thread
> the client connection is started first. but surprisingly it tries start the
> brokers transport connector. An apparent glitch follows when the broker
> service stops and re-start the transport.
> {noformat}
> 2014-03-05 11:07:57,626 [ClientConnection_thread] INFO
> org.apache.activemq.broker.TransportConnector - Connector
> vm://ApplicationName Started
> [...]
> 2014-03-05 11:08:07,009 [Main_thread] INFO
> org.apache.activemq.broker.TransportConnector - Connector
> vm://ApplicationName Stopped
> 2014-03-05 11:08:07,011 [Main_thread] INFO
> org.apache.activemq.broker.TransportConnector - Connector
> vm://ApplicationName Started
> {noformat}
> I look into the activemq source and saw this:
> BrokerService.class
> {code}
> public void start() throws Exception {
> [...]
> // in jvm master slave, lets not publish over existing broker till we get
> the lock
> final BrokerRegistry brokerRegistry = BrokerRegistry.getInstance();
> if (brokerRegistry.lookup(getBrokerName()) == null) {
> brokerRegistry.bind(getBrokerName(), BrokerService.this);
> }
> startPersistenceAdapter(startAsync);
> startBroker(startAsync);
> brokerRegistry.bind(getBrokerName(), BrokerService.this);
> {code}
> VMTransportFactory.class
> {code}
> private BrokerService lookupBroker(final BrokerRegistry registry, final
> String brokerName, int waitForStart) {
> BrokerService broker = null;
> synchronized(registry.getRegistryMutext()) {
> broker = registry.lookup(brokerName);
> if (broker == null && waitForStart > 0) {
> final long expiry = System.currentTimeMillis() + waitForStart;
> while (broker == null && expiry >
> System.currentTimeMillis()) {
> long timeout = Math.max(0, expiry -
> System.currentTimeMillis());
> try {
> LOG.debug("waiting for broker named: " + brokerName +
> " to start");
> registry.getRegistryMutext().wait(timeout);
> } catch (InterruptedException ignored) {
> }
> broker = registry.lookup(brokerName);
> }
> }
> }
> return broker;
> }
> {code}
> It appears that create=false and waitForStart only waits for the broker to be
> added to the BrokerRegistry. However when the brokerService is starts, it
> seems that the broker is added to the registry before it is started.
> I believe some synchronization is missing make the VMTransportFactory wait
> for the broker not only to be added to the registry, but also fully started.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5256) AMQP WARN Transport Connection failed: java.io.IOException
[
https://issues.apache.org/jira/browse/AMQ-5256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5256:
-
Fix Version/s: 5.10.1
> AMQP WARN Transport Connection failed: java.io.IOException
> ---
>
> Key: AMQ-5256
> URL: https://issues.apache.org/jira/browse/AMQ-5256
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 5.10.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Labels: IOException, amqp, hang
> Fix For: 5.10.1, 5.11.0
>
>
> concurrent AMQP connection, client hung on half closed connection, waiting
> for response to open.{code} java.lang.Thread.State: WAITING (on object
> monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <7df15ba78> (a
> org.apache.qpid.amqp_1_0.transport.ConnectionEndpoint)
> at java.lang.Object.wait(Object.java:485)
> at
> org.apache.qpid.amqp_1_0.transport.ConnectionEndpoint.open(ConnectionEndpoint.java:154)
> - locked <7df15ba78> (a
> org.apache.qpid.amqp_1_0.transport.ConnectionEndpoint)
> - locked <7df15ba78> (a
> org.apache.qpid.amqp_1_0.transport.ConnectionEndpoint)
> at
> org.apache.qpid.amqp_1_0.client.Connection.(Connection.java:284)
> at
> org.apache.qpid.amqp_1_0.client.Connection.(Connection.java:143)
> at
> org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.connect(ConnectionImpl.java:115)
> - locked <7df8bd048> (a java.lang.Object)
> at
> org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.start(ConnectionImpl.java:284){code}
> Broker log contains:{code}
> [ActiveMQ Transport: tcp:///127.0.0.1:64496@64488] - WARN
> Transport - Transport Connection to: tcp://127.0.0.1:64496 failed:
> java.io.IOException{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5251) Scheduler missing some synchronization
[ https://issues.apache.org/jira/browse/AMQ-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5251: - Fix Version/s: 5.10.1 > Scheduler missing some synchronization > -- > > Key: AMQ-5251 > URL: https://issues.apache.org/jira/browse/AMQ-5251 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.10.0 >Reporter: james >Assignee: Timothy Bish >Priority: Minor > Fix For: 5.10.1, 5.11.0 > > > the org.apache.activemq.thread.Scheduler.executePeriodically() method should > be synchronized since it modifies the timerTasks map. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5239) Enable access to BrokerService instances
[ https://issues.apache.org/jira/browse/AMQ-5239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5239: - Fix Version/s: 5.10.1 > Enable access to BrokerService instances > > > Key: AMQ-5239 > URL: https://issues.apache.org/jira/browse/AMQ-5239 > Project: ActiveMQ > Issue Type: Improvement > Components: OSGi/Karaf >Affects Versions: 5.10.0 >Reporter: Martin Lichtin > Fix For: 5.10.1, 5.11.0 > > > When creating broker instances using activemq-osgi, ActiveMQServiceFactory > manages the named BrokerService instances. > Currently it is not possible to access these instances, e.g. for querying > purposes to retrieve statistics, etc. It would be great if one could do so. > ActiveMQServiceFactory can be accessed via the ManagedServiceFactory > (service.pid=org.apache.activemq.server). What is missing is for example an > accessor method to the "brokers" field. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5241) Spurious WARN FailoverTransport - Transport .. failed, reason: , attempting to automatically reconnect java.io.EOFException
[
https://issues.apache.org/jira/browse/AMQ-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5241:
-
Fix Version/s: 5.10.1
> Spurious WARN FailoverTransport - Transport .. failed, reason: , attempting
> to automatically reconnect java.io.EOFException
>
>
> Key: AMQ-5241
> URL: https://issues.apache.org/jira/browse/AMQ-5241
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Minor
> Labels: Failover, WARN
> Fix For: 5.10.1, 5.11.0
>
>
> Occasional spurious reconnect from Failover during normal close processing.
> Incorrectly reporting a problem{code}2014-06-23 12:01:47,095
> [0.1:61616@63805] - WARN FailoverTransport - Transport
> (tcp://localhost/127.0.0.1:61616@63805) failed, reason: , attempting to
> automatically reconnect
> java.io.EOFException
> at java.io.DataInputStream.readInt(DataInputStream.java:375)
> at
> org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:258)
> at
> org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
> at
> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
> at
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
> at java.lang.Thread.run(Thread.java:695){code}
> Issue is broker response to shutdown info is closing broker end of the socket
> before client has chance to stop the local transport. So client gets eof
> before it closes and reports and tries to reconnect in error. Because we
> treat abortive disconnect as a warn event this can lead to confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5231) Failover Transport timeout option causes connection failures in some cases where it shouldn't
[ https://issues.apache.org/jira/browse/AMQ-5231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5231: - Fix Version/s: 5.10.1 > Failover Transport timeout option causes connection failures in some cases > where it shouldn't > - > > Key: AMQ-5231 > URL: https://issues.apache.org/jira/browse/AMQ-5231 > Project: ActiveMQ > Issue Type: Improvement > Components: Transport >Affects Versions: 5.8.0, 5.9.0, 5.9.1, 5.10.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 5.10.1, 5.11.0 > > > Originally added in AMQ-2061 the timeout option is used to cause a send of > Message that's gone out async to fail if the connection doesn't come back in > some amount of time. > The problem is that the option is currently applied to everything that goes > through FailoverTransport oneway() and this can cause a Connection start > where the broker is not up to fail regardless of the maxReconnectAttempts or > startupMaxReconnectAttempts value configured for the transport. > We need to refine the timeout logic to only apply to Message instances and > not to other commands like ConnectionInfo so that a Connection start honors > the normal failover transport reconnect configuration logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5223) activemq-jms-pool is missing OSGi metadata
[ https://issues.apache.org/jira/browse/AMQ-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5223: - Fix Version/s: 5.10.1 > activemq-jms-pool is missing OSGi metadata > -- > > Key: AMQ-5223 > URL: https://issues.apache.org/jira/browse/AMQ-5223 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.9.1, 5.10.0 >Reporter: Guillaume Nodet > Fix For: 5.10.1, 5.11.0 > > > Adding bunde fixes the issue -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5226) When create on start is set to true, the JMS Pool can return the same connection twice in a row
[ https://issues.apache.org/jira/browse/AMQ-5226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5226: - Fix Version/s: 5.10.1 > When create on start is set to true, the JMS Pool can return the same > connection twice in a row > --- > > Key: AMQ-5226 > URL: https://issues.apache.org/jira/browse/AMQ-5226 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-pool >Affects Versions: 5.9.0, 5.9.1, 5.10.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 5.10.1, 5.11.0 > > > When the PooledConnectionFactory is configured to create connection on start, > it can return the same connection twice in a row before moving on to > returning other new connections which violates the round robin policy when > there is more than one connection configured for pooling. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5015) Temp Queue gets deleted on close of wrong connection
[ https://issues.apache.org/jira/browse/AMQ-5015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5015: - Fix Version/s: 5.10.1 > Temp Queue gets deleted on close of wrong connection > > > Key: AMQ-5015 > URL: https://issues.apache.org/jira/browse/AMQ-5015 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 5.9.0 >Reporter: Christian Schneider >Assignee: Timothy Bish > Fix For: 5.10.1, 5.11.0 > > Attachments: PooledConnectionTempQueueTest.java > > > My scenario is this: > connection1: > create temp queue tq1 > send msg to qeue1 with replyTo tq1 > wait for reply on tq1 > connection2: > receive message on queue1 > send to replyTo address which is tq1 > In some cases the temp queue gets deleted in the close method of connection2. > The scenario is kind of an edge case as it only happens if I use a > PooledConnectionFactory and only if I before my scenario above open a > connection and session and close the connection before the session. > So strictly speaking my code has an error. > I think the problem is in the PooledConnection factory. It seems to reuse a > connection or session in the wrong way. I will attach a test case -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5212) Deadlock with duplicate detection and dlq processing in kahadb
[
https://issues.apache.org/jira/browse/AMQ-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5212:
-
Fix Version/s: 5.10.1
> Deadlock with duplicate detection and dlq processing in kahadb
> --
>
> Key: AMQ-5212
> URL: https://issues.apache.org/jira/browse/AMQ-5212
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Message Store
>Affects Versions: 5.9.0, 5.9.1
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.10.1, 5.11.0
>
>
> Contention between access to the destination map from store duplicate
> processing and dlq destination creation from the cursor. But could be between
> any destination creation/deletion.
> From the test case: {code}Found one Java-level deadlock:
> =
> "ActiveMQ Transport: tcp://27.0.0.1:60895@60852":
> waiting for ownable synchronizer 7df695ea8, (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync),
> which is held by "ActiveMQ Transport: tcp://27.0.0.1:60894@60852"
> "ActiveMQ Transport: tcp://27.0.0.1:60894@60852":
> waiting for ownable synchronizer 7df605fd8, (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync),
> which is held by "ConcurrentQueueStoreAndDispatch"
> "ConcurrentQueueStoreAndDispatch":
> waiting for ownable synchronizer 7df695ea8, (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync),
> which is held by "ActiveMQ Transport: tcp://27.0.0.1:60894@60852"
> Java stack information for the threads listed above:
> ===
> "ActiveMQ Transport: tcp://27.0.0.1:60895@60852":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <7df695ea8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:842)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1178)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:890)
> at
> org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:129)
> at
> org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:334)
> at
> org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:172)
> at
> org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:184)
> at
> org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:172)
> at
> org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:172)
> at
> org.apache.activemq.broker.MutableBrokerFilter.addDestination(MutableBrokerFilter.java:177)
> at
> org.apache.activemq.broker.region.RegionBroker.addProducer(RegionBroker.java:384)
> at
> org.apache.activemq.broker.BrokerFilter.addProducer(BrokerFilter.java:107)
> at
> org.apache.activemq.advisory.AdvisoryBroker.addProducer(AdvisoryBroker.java:172)
> at
> org.apache.activemq.broker.CompositeDestinationBroker.addProducer(CompositeDestinationBroker.java:56)
> at
> org.apache.activemq.broker.BrokerFilter.addProducer(BrokerFilter.java:107)
> at
> org.apache.activemq.broker.MutableBrokerFilter.addProducer(MutableBrokerFilter.java:112)
> at
> org.apache.activemq.broker.TransportConnection.processAddProducer(TransportConnection.java:565)
> at org.apache.activemq.command.ProducerInfo.visit(ProducerInfo.java:108)
> at
> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:294)
> at
> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:148)
> at
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> at
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270)
> at
> org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
> at
> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214)
> at
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
> at java.lang.Thread.run(Thread.java:695)
> "ActiveMQ Transport: tcp://27.0.0.1:60894@60852":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <7df605fd8> (a
> jav
[jira] [Updated] (AMQ-5211) ActiveMQDestination.createDestination() should prevent empty destination name
[
https://issues.apache.org/jira/browse/AMQ-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5211:
-
Fix Version/s: 5.10.1
> ActiveMQDestination.createDestination() should prevent empty destination name
> -
>
> Key: AMQ-5211
> URL: https://issues.apache.org/jira/browse/AMQ-5211
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.9.0
>Reporter: Ben O'Day
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.10.1, 5.11.0
>
> Attachments: AMQ-5211.patch
>
>
> currently you can call ActiveMQDestination
> createDestination("",ActiveMQDestination.QUEUE_TYPE) to create a queue with
> no name.
> while this doesn't seem to be an issue at first...if you are using mKahadb,
> ActiveMQ will fail to restart after this queue/store directory are created.
> see this post:
> http://activemq.2283324.n4.nabble.com/mkahadb-Failed-to-start-per-destination-persistence-adapter-for-destination-td4678754.html#a4679848
> the web console already prevents this, we should prevent this from other
> entry points to this API (QueueView.moveMessagesTo() from JMX in my case)...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5214) Security errors for sync commands are only logged at debug levels
[ https://issues.apache.org/jira/browse/AMQ-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5214: - Fix Version/s: 5.10.1 > Security errors for sync commands are only logged at debug levels > - > > Key: AMQ-5214 > URL: https://issues.apache.org/jira/browse/AMQ-5214 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker, Transport >Affects Versions: 5.9.0, 5.9.1, 5.10.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: 5.10.1, 5.11.0 > > > For any operation that sends a sync commands (response required) there is no > warning logs indicating a security exception was triggered. In the async > case we log in detail. We should add a log at warn level for security errors > sent back as responses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5471) Configuration server for Network of Brokers
[ https://issues.apache.org/jira/browse/AMQ-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14232272#comment-14232272 ] Hadrian Zbarcea commented on AMQ-5471: -- Actually my immediate goal was slightly different, related to configuring nobs in various topologies (in separate directories). Dynamically generating configuration is probably a more interesting goal. I'll give it a bit of thought and update the description accordingly. Thanks for the feedback. > Configuration server for Network of Brokers > --- > > Key: AMQ-5471 > URL: https://issues.apache.org/jira/browse/AMQ-5471 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: Hadrian Zbarcea >Assignee: Hadrian Zbarcea > Fix For: 5.11.0 > > > Brokers use the xbean configuration to start which is usually found in ./conf > other other places on the local disk. In a NOB topology however it is hard to > distribute the configuration files and maintain them across brokers > especially with a growing or elasticly changing number of brokers. > ActiveMQ already supports reading the xbean configuration from an http;// > URL, so it would be very helpful to have a rest service that manages the > configuration for all the brokers. > I started such a service on [github|https://github.com/hzbarcea/activemq-nob] > but plan to contribute it to ASF once it's in a decent shape, in a couple of > weeks or so. > The service uses the local file system and appropriate conventions to store > all the relevant broker configuration resources (e.g. could be generated with > ./bin/activemq create minus certificates probably). I plan to > enhance it later to support a git repository for the configuration, so that > it's versioned, so that an operator could roll out a new NOB topology, or > roll back to the previous configuration. > Feedback appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5471) Configuration server for Network of Brokers
[ https://issues.apache.org/jira/browse/AMQ-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14232206#comment-14232206 ] Hadrian Zbarcea commented on AMQ-5471: -- If you just want to server static content, httpd, nginx are fine. If the content is more dynamic it starts to get more complicated. Sure you can map the http resource to a directory that is a git repository and then have hooks or some other external mechanism that deals with the fs content. I thought about maven repos, but I think they'd be overkill for this. If you want to use this service to provide not just configuration but also status of the brokers in the nob, in which case no cots product would help you. I don't see this as innovation in the wheel industry. Is there a simpler solution I miss? > Configuration server for Network of Brokers > --- > > Key: AMQ-5471 > URL: https://issues.apache.org/jira/browse/AMQ-5471 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: Hadrian Zbarcea >Assignee: Hadrian Zbarcea > Fix For: 5.11.0 > > > Brokers use the xbean configuration to start which is usually found in ./conf > other other places on the local disk. In a NOB topology however it is hard to > distribute the configuration files and maintain them across brokers > especially with a growing or elasticly changing number of brokers. > ActiveMQ already supports reading the xbean configuration from an http;// > URL, so it would be very helpful to have a rest service that manages the > configuration for all the brokers. > I started such a service on [github|https://github.com/hzbarcea/activemq-nob] > but plan to contribute it to ASF once it's in a decent shape, in a couple of > weeks or so. > The service uses the local file system and appropriate conventions to store > all the relevant broker configuration resources (e.g. could be generated with > ./bin/activemq create minus certificates probably). I plan to > enhance it later to support a git repository for the configuration, so that > it's versioned, so that an operator could roll out a new NOB topology, or > roll back to the previous configuration. > Feedback appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5471) Configuration server for Network of Brokers
Hadrian Zbarcea created AMQ-5471: Summary: Configuration server for Network of Brokers Key: AMQ-5471 URL: https://issues.apache.org/jira/browse/AMQ-5471 Project: ActiveMQ Issue Type: New Feature Components: Broker Reporter: Hadrian Zbarcea Assignee: Hadrian Zbarcea Fix For: 5.11.0 Brokers use the xbean configuration to start which is usually found in ./conf other other places on the local disk. In a NOB topology however it is hard to distribute the configuration files and maintain them across brokers especially with a growing or elasticly changing number of brokers. ActiveMQ already supports reading the xbean configuration from an http;// URL, so it would be very helpful to have a rest service that manages the configuration for all the brokers. I started such a service on [github|https://github.com/hzbarcea/activemq-nob] but plan to contribute it to ASF once it's in a decent shape, in a couple of weeks or so. The service uses the local file system and appropriate conventions to store all the relevant broker configuration resources (e.g. could be generated with ./bin/activemq create minus certificates probably). I plan to enhance it later to support a git repository for the configuration, so that it's versioned, so that an operator could roll out a new NOB topology, or roll back to the previous configuration. Feedback appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQ-5455) Build Failure due to missing paho dependency
[ https://issues.apache.org/jira/browse/AMQ-5455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea resolved AMQ-5455. -- Resolution: Fixed Fix Version/s: 5.11.0 Assignee: Hadrian Zbarcea > Build Failure due to missing paho dependency > > > Key: AMQ-5455 > URL: https://issues.apache.org/jira/browse/AMQ-5455 > Project: ActiveMQ > Issue Type: Bug >Reporter: Hadrian Zbarcea >Assignee: Hadrian Zbarcea > Fix For: 5.11.0 > > > Per report on the dev@ mailing list: > http://activemq.2283324.n4.nabble.com/activemq-5-10-0-doesn-t-build-from-source-td4687924.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5455) Build Failure due to missing paho dependency
[ https://issues.apache.org/jira/browse/AMQ-5455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223722#comment-14223722 ] Hadrian Zbarcea commented on AMQ-5455: -- Fix applied. Thanks Ciprian for the patch. The [original repo|https://repo.eclipse.org/content/groups/releases/org/eclipse/paho/mqtt-client/0.4.0/] is empty. I don't know if mqtt-client will ever pop back, maybe we should remove it and stick with the spring.io one. > Build Failure due to missing paho dependency > > > Key: AMQ-5455 > URL: https://issues.apache.org/jira/browse/AMQ-5455 > Project: ActiveMQ > Issue Type: Bug >Reporter: Hadrian Zbarcea > > Per report on the dev@ mailing list: > http://activemq.2283324.n4.nabble.com/activemq-5-10-0-doesn-t-build-from-source-td4687924.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5455) Build Failure due to missing paho dependency
[
https://issues.apache.org/jira/browse/AMQ-5455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223677#comment-14223677
]
Hadrian Zbarcea commented on AMQ-5455:
--
Error is below:
{code}
[ERROR] Failed to execute goal on project activemq-mqtt: Could not resolve
dependencies for project org.apache.activemq:activemq-mqtt:jar:5.11-SNAPSHOT:
Failure to find org.eclipse.paho:mqtt-client:jar:0.4.0 in
https://repo.eclipse.org/content/groups/releases/ was cached in the local
repository, resolution will not be reattempted until the update interval of
eclipse.m2 has elapsed or updates are forced -> [Help 1]
{code}
The reason is paho no longer being available in maven central. Weird...
> Build Failure due to missing paho dependency
>
>
> Key: AMQ-5455
> URL: https://issues.apache.org/jira/browse/AMQ-5455
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Hadrian Zbarcea
>
> Per report on the dev@ mailing list:
> http://activemq.2283324.n4.nabble.com/activemq-5-10-0-doesn-t-build-from-source-td4687924.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-5455) Build Failure due to missing paho dependency
Hadrian Zbarcea created AMQ-5455: Summary: Build Failure due to missing paho dependency Key: AMQ-5455 URL: https://issues.apache.org/jira/browse/AMQ-5455 Project: ActiveMQ Issue Type: Bug Reporter: Hadrian Zbarcea Per report on the dev@ mailing list: http://activemq.2283324.n4.nabble.com/activemq-5-10-0-doesn-t-build-from-source-td4687924.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-4850) NoClassDefFoundError: javax/net/ssl/SSLServerSocket (in Karaf)
[ https://issues.apache.org/jira/browse/AMQ-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4850: - Fix Version/s: 5.10.0 > NoClassDefFoundError: javax/net/ssl/SSLServerSocket (in Karaf) > -- > > Key: AMQ-4850 > URL: https://issues.apache.org/jira/browse/AMQ-4850 > Project: ActiveMQ > Issue Type: Bug > Components: OSGi/Karaf >Affects Versions: 5.9.0 > Environment: Oracle JDK 7u45, Karaf 2.3.3 with activemq-broker > installed from 5.9.0 feature >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré > Fix For: 5.10.0 > > > I couldn't find a way to recreate this consistently, but after repeating > several times the following steps reproduce it: > 1. Install custom Karaf 2.3.3 from scratch. Customizations include installing > the activemq-broker feature using the featuresBoot configuration (along with > a couple other unrelated features), and a dozen or so of my application's > bundles in the deploy folder. > 2. Start Karaf - everything works fine. > 3. Shut down Karaf. > 4. Touch my application's 'common' bundle (in deploy folder). The other > application bundles depend on this one. This is *not* the bundle that uses > ActiveMQ. > 5. Start Karaf - it first starts all the app bundles (the old version I > think), then it picks up the modified bundle timestamp and restarts the app > bundles in what appears to be arbitrary order. This usually works, but once > in a while the app's 'bus' bundle (which connects to ActiveMQ) fails to start > with this exception showing up in the logs. > 6. Interestingly, restarting the app or activemq bundles, or even restarting > Karaf itself, doesn't fix things - once it enters this invalid state, it > seems to stay stuck in it and continues with the same exception and with the > app unable to connect to ActiveMQ. However, if I shut down Karaf and once > again touch my app's 'common' bundle in the deploy folder and then start up > Karaf again, it restarts the app bundles and this time everything goes back > to normal, with a successful connection to ActiveMQ. So it looks like while > the first occurrence is not recreated consistently, this state is not just a > runtime thing but remains persisted somehow for as long as the app bundle > files aren't modified. > Here is the stack trace: > java.lang.NoClassDefFoundError: javax/net/ssl/SSLServerSocket > at > org.apache.activemq.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:163) > at > org.apache.activemq.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:151) > at > org.apache.activemq.transport.failover.FailoverTransportFactory.createTransport(FailoverTransportFactory.java:74) > at > org.apache.activemq.transport.failover.FailoverTransportFactory.createTransport(FailoverTransportFactory.java:63) > at > org.apache.activemq.transport.failover.FailoverTransportFactory.doConnect(FailoverTransportFactory.java:38) > at > org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:64) > at > org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:258) > at > org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:273) > at > org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:246) > at > org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:186) > ... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AMQ-4492) ActiveMQ does not work on Karaf 3
[ https://issues.apache.org/jira/browse/AMQ-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea resolved AMQ-4492. -- Resolution: Fixed Fix Version/s: 5.9.1 This looks good now in karaf 3.0, even with 5.9.1 > ActiveMQ does not work on Karaf 3 > - > > Key: AMQ-4492 > URL: https://issues.apache.org/jira/browse/AMQ-4492 > Project: ActiveMQ > Issue Type: Task > Components: Broker >Affects Versions: 5.8.0 > Environment: Karaf 3.0.0.RC1 >Reporter: Christian Schneider >Assignee: Jean-Baptiste Onofré > Fix For: 5.10.0, 5.9.1 > > > when I try to install activemq 5.7.0 into karaf 3.0.0.RC1 I get the following > error: > karaf@root()> feature:install activemq-blueprint > Error executing command: Could not start bundle > mvn:org.apache.activemq/activemq-karaf/5.7.0 in feature(s) activemq-5.7.0: > Unresolved constraint in bundle activemq-karaf [297]: Unable to resolve > 297.0: missing requirement [297.0] osgi.wiring.package; > (&(osgi.wiring.package=org.apache.felix.gogo.commands.basic)(version>=0.10.0)(!(version>=1.0.0))) > The exported packages in karaf look like this: > exports | grep gogo > org.apache.felix.gogo.api | 0.10.0 | 48 | > org.apache.karaf.shell.console > org.apache.felix.gogo.commands | 0.10.0 | 48 | > org.apache.karaf.shell.console > org.apache.felix.gogo.runtime.activator | 0.10.0 | 48 | > org.apache.karaf.shell.console > org.apache.felix.gogo.runtime.threadio | 0.10.0 | 48 | > org.apache.karaf.shell.console > org.apache.felix.gogo.runtime | 0.10.0 | 48 | > org.apache.karaf.shell.console > For ActiveMQ 5.8.0 the error is similar. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4232) Kahadb does not allow to obtain count of used/free bytes in the storage
[ https://issues.apache.org/jira/browse/AMQ-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4232: - Fix Version/s: (was: 5.10.0) 5.10.1 > Kahadb does not allow to obtain count of used/free bytes in the storage > --- > > Key: AMQ-4232 > URL: https://issues.apache.org/jira/browse/AMQ-4232 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.4.2, 5.7.0 > Environment: fedora15, ubuntu12.10; debian; probably independent >Reporter: Tomáš Martinec > Labels: hangs, kahadb, usage > Fix For: 5.10.1 > > Attachments: extending.kahadb.diff > > > The full story is user forum under title: > Activemq 5.4.2 hangs when the temp disk usage is used > TempUsage.retrieveUsage() always returns the size of the allocated storage > instead of the actual usage. I could not see what methods of kahadb returns > the needed information, so I extended the kahadb interface. > Note that this issue may cause other problems such as AMQ-4136. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-4232) Kahadb does not allow to obtain count of used/free bytes in the storage
[ https://issues.apache.org/jira/browse/AMQ-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13985509#comment-13985509 ] Hadrian Zbarcea commented on AMQ-4232: -- As this is unassigned and not clear what the solution is. Moving it to 5.10.1 for now. > Kahadb does not allow to obtain count of used/free bytes in the storage > --- > > Key: AMQ-4232 > URL: https://issues.apache.org/jira/browse/AMQ-4232 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.4.2, 5.7.0 > Environment: fedora15, ubuntu12.10; debian; probably independent >Reporter: Tomáš Martinec > Labels: hangs, kahadb, usage > Fix For: 5.10.1 > > Attachments: extending.kahadb.diff > > > The full story is user forum under title: > Activemq 5.4.2 hangs when the temp disk usage is used > TempUsage.retrieveUsage() always returns the size of the allocated storage > instead of the actual usage. I could not see what methods of kahadb returns > the needed information, so I extended the kahadb interface. > Note that this issue may cause other problems such as AMQ-4136. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AMQ-2299) Integration Fails in jboss-5.0.0.GA
[
https://issues.apache.org/jira/browse/AMQ-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea resolved AMQ-2299.
--
Resolution: Cannot Reproduce
Seems to not be a problem anymore.
> Integration Fails in jboss-5.0.0.GA
> ---
>
> Key: AMQ-2299
> URL: https://issues.apache.org/jira/browse/AMQ-2299
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.2.0
> Environment: java version "1.5.0_19", Windows XP,
>Reporter: vedavathi
> Fix For: AGING_TO_DIE
>
> Original Estimate: 20h
> Remaining Estimate: 20h
>
> Hi,
> I have downloaded activemq-ra.rar and activemq-jms-ds from
> http://activemq.apache.org/integrating-apache-activemq-with-jboss.html and
> placed in C:\work\jboss-5.0.0.GA\server\default\deploy. After that i have
> restarted the JBOSS server and i got the following messages in log file.
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual
> State}
> activemq.queue:name=outboundQueue
> -> jboss.jca:name='activemq-ra.rar',service=RARDeployment{Create:** NOT
> FOUND Depends on 'jboss.jca:name='activemq-ra.rar',service=RARDeployment' **}
> activemq.topic:name=inboundTopic
> -> jboss.jca:name='activemq-ra.rar',service=RARDeployment{Create:** NOT
> FOUND Depends on 'jboss.jca:name='activemq-ra.rar',service=RARDeployment' **}
> jboss.jca:name=activemq/QueueConnectionFactory,service=ConnectionFactoryBinding
> ->
> jboss.jca:name=activemq/QueueConnectionFactory,service=TxCM{Create:Configured}
> jboss.jca:name=activemq/QueueConnectionFactory,service=ManagedConnectionFactory
> -> jboss.jca:name='activemq-ra.rar',service=RARDeployment{Create:** NOT
> FOUND Depends on 'jboss.jca:name='activemq-ra.rar',service=RARDeployment' **}
> jboss.jca:name=activemq/QueueConnectionFactory,service=ManagedConnectionPool
> ->
> jboss.jca:name=activemq/QueueConnectionFactory,service=ManagedConnectionFactory{Create:Configured}
> jboss.jca:name=activemq/QueueConnectionFactory,service=TxCM
> ->
> jboss.jca:name=activemq/QueueConnectionFactory,service=ManagedConnectionPool{Create:Configured}
> jboss.jca:name=activemq/TopicConnectionFactory,service=ConnectionFactoryBinding
> ->
> jboss.jca:name=activemq/TopicConnectionFactory,service=TxCM{Create:Configured}
> jboss.jca:name=activemq/TopicConnectionFactory,service=ManagedConnectionFactory
> -> jboss.jca:name='activemq-ra.rar',service=RARDeployment{Create:** NOT
> FOUND Depends on 'jboss.jca:name='activemq-ra.rar',service=RARDeployment' **}
> jboss.jca:name=activemq/TopicConnectionFactory,service=ManagedConnectionPool
> ->
> jboss.jca:name=activemq/TopicConnectionFactory,service=ManagedConnectionFactory{Create:Configured}
> jboss.jca:name=activemq/TopicConnectionFactory,service=TxCM
> ->
> jboss.jca:name=activemq/TopicConnectionFactory,service=ManagedConnectionPool{Create:Configured}
> *** CONTEXTS IN ERROR: Name -> Error
> jboss.jca:name='activemq-ra.rar',service=RARDeployment -> ** NOT FOUND
> Depends on 'jboss.jca:name='activemq-ra.rar',service=RARDeployment' **
> vfsfile:/C:/work/jboss-5.0.0.GA/server/default/deploy/activemq-ra.rar/ ->
> java.io.IOException: The filename, directory name, or volume label syntax is
> incorrect
> However activemq is up and running in JBOSS 4.0.4.
> Please provide the solution.
> Thanks
> Veda
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (AMQ-453) Clustering subscriptions
[ https://issues.apache.org/jira/browse/AMQ-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea resolved AMQ-453. - Resolution: Won't Fix N/A > Clustering subscriptions > > > Key: AMQ-453 > URL: https://issues.apache.org/jira/browse/AMQ-453 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: james strachan > Fix For: AGING_TO_DIE > > > To be able to use ServiceMix WS-Notification in a cluster, we need to be able > to: > * attach some data to the subscription > * provide a way to retrieve subscription informations from the > NotificationBroker (using consumer advisory ?) > * cluster subscriptions (sticky durable subscriber ?) > See irc log from 21/12/2005 from 21:14 > http://servlet.uwyn.com/drone/log/hausbot/servicemix/20051221 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-2040) Improve message browsing
[ https://issues.apache.org/jira/browse/AMQ-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-2040: - Fix Version/s: (was: 5.10.0) 5.10.1 > Improve message browsing > > > Key: AMQ-2040 > URL: https://issues.apache.org/jira/browse/AMQ-2040 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.2.0 >Reporter: Dejan Bosanac >Assignee: Dejan Bosanac > Fix For: 5.10.1 > > > Currently the browse() method returns 400 messages (or all if there are less > than that). Allow configuring the number of messages returned and fetching > messages beyond first page with the method such as browse(int page). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AMQ-5021) org.apache.activemq.bugs.MemoryUsageBlockResumeTest sometimes hangs
[ https://issues.apache.org/jira/browse/AMQ-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea resolved AMQ-5021. -- Resolution: Fixed > org.apache.activemq.bugs.MemoryUsageBlockResumeTest sometimes hangs > --- > > Key: AMQ-5021 > URL: https://issues.apache.org/jira/browse/AMQ-5021 > Project: ActiveMQ > Issue Type: Bug > Components: Test Cases >Reporter: Kevin Earls >Assignee: Kevin Earls >Priority: Minor > Fix For: 5.9.1, 5.10.0 > > Attachments: MemoryUsageBlockResumeTest.stack > > > org.apache.activemq.bugs.MemoryUsageBlockResumeTest sometimes hangs, which > can block CI builds. I will update it to JUnit4 and add a timeout so it at > least does not cause the build to hang. > I am also attaching a stack trace. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AMQ-4892) MQTT clients disconnecting due to socket error do not publish the configured last will and testament message.
[ https://issues.apache.org/jira/browse/AMQ-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea resolved AMQ-4892. -- Resolution: Fixed > MQTT clients disconnecting due to socket error do not publish the configured > last will and testament message. > - > > Key: AMQ-4892 > URL: https://issues.apache.org/jira/browse/AMQ-4892 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.9.1, 5.10.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AMQ-3725) Kahadb error during SAN failover delayed write - Allow kahaDB to recover in a similar manner as the JDBC store using the IOExceptionHandler
[
https://issues.apache.org/jira/browse/AMQ-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea resolved AMQ-3725.
--
Resolution: Fixed
> Kahadb error during SAN failover delayed write - Allow kahaDB to recover in a
> similar manner as the JDBC store using the IOExceptionHandler
> ---
>
> Key: AMQ-3725
> URL: https://issues.apache.org/jira/browse/AMQ-3725
> Project: ActiveMQ
> Issue Type: Bug
> Components: Message Store
>Affects Versions: 5.5.1
>Reporter: Jason Sherman
>Assignee: Dejan Bosanac
> Fix For: 5.9.1, 5.10.0
>
> Attachments: AMQ-3725-10112013.txt
>
>
> An issue can arise that causes the broker to terminate when using kahaDB with
> a SAN, when the SAN fails over. In this case the failover process is
> seamless however, on fail back there is a 2-3 sec delay where writes are
> blocked and the broker terminates. With the JDBC datastore a similar
> situation can be handled by using the IOExceptionHandler. However with
> kahaDB, when this same IOExceptionHandler is added it prevents the broker
> from terminating but kahaDB retains an invalid index.
> {code}
> INFO | ActiveMQ JMS Message Broker (Broker1,
> ID:macbookpro-251a.home-56915-1328715089252-0:1) started
> INFO | jetty-7.1.6.v20100715
> INFO | ActiveMQ WebConsole initialized.
> INFO | Initializing Spring FrameworkServlet 'dispatcher'
> INFO | ActiveMQ Console at http://0.0.0.0:8161/admin
> INFO | ActiveMQ Web Demos at http://0.0.0.0:8161/demo
> INFO | RESTful file access application at http://0.0.0.0:8161/fileserver
> INFO | FUSE Web Console at http://0.0.0.0:8161/console
> INFO | Started SelectChannelConnector@0.0.0.0:8161
> ERROR | KahaDB failed to store to Journal
> java.io.SyncFailedException: sync failed
> at java.io.FileDescriptor.sync(Native Method)
> at
> org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
> at
> org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
> INFO | Ignoring IO exception, java.io.SyncFailedException: sync failed
> java.io.SyncFailedException: sync failed
> at java.io.FileDescriptor.sync(Native Method)
> at
> org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
> at
> org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
> ERROR | Checkpoint failed
> java.io.SyncFailedException: sync failed
> at java.io.FileDescriptor.sync(Native Method)
> at
> org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
> at
> org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
> INFO | Ignoring IO exception, java.io.SyncFailedException: sync failed
> java.io.SyncFailedException: sync failed
> at java.io.FileDescriptor.sync(Native Method)
> at
> org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
> at
> org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
> ERROR | KahaDB failed to store to Journal
> java.io.FileNotFoundException: /Volumes/NAS-01/data/kahadb/db-1.log (No such
> file or directory)
> at java.io.RandomAccessFile.open(Native Method)
> at java.io.RandomAccessFile.(RandomAccessFile.java:216)
> at
> org.apache.kahadb.journal.DataFile.openRandomAccessFile(DataFile.java:70)
> at
> org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:324)
> at
> org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
> INFO | Ignoring IO exception, java.io.FileNotFoundException:
> /Volumes/NAS-01/data/kahadb/db-1.log (No such file or directory)
> java.io.FileNotFoundException: /Volumes/NAS-01/data/kahadb/db-1.log (No such
> file or directory)
> at java.io.RandomAccessFile.open(Native Method)
> at java.io.RandomAccessFile.(RandomAccessFile.java:216)
> at
> org.apache.kahadb.journal.DataFile.openRandomAccessFile(DataFile.java:70)
> at
> org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:324)
> at
> org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
> ERROR | KahaDB failed to store to Journal
> java.io.FileNotFoundException: /Volumes/NAS-01/data/kahadb/db-1.log (No such
> file or directory)
> at java.io.RandomAccessFile.open(Native Method)
> at java.io.RandomAccessFile.(RandomAccessFile.java:216)
> at
> org.apache.kahadb.journal.DataFile.openRandomAccessFile(DataFile.java:70)
> at
> org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:324)
> at
> org.apache.kahadb.journal.DataFileAppender$2.run(
[jira] [Updated] (AMQ-4471) Inconsistent messages with the WebSocket/Stomp Demo
[ https://issues.apache.org/jira/browse/AMQ-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4471: - Fix Version/s: 5.10.0 > Inconsistent messages with the WebSocket/Stomp Demo > --- > > Key: AMQ-4471 > URL: https://issues.apache.org/jira/browse/AMQ-4471 > Project: ActiveMQ > Issue Type: Bug > Components: stomp, Transport >Affects Versions: 5.8.0 >Reporter: Matthias Weßendorf >Priority: Minor > Fix For: 5.10.0 > > > Playing with the "demo/websocket/index.html" demo (5.8.0), I see an > inconsistent messaging behavioir > Having two browsers (FF and chrome) and not always the message receives the > other browser > * TEST in FF => displayed in Chrome (and FF) > * TEST (1) in Chrome => displayed in both > * TEST (2) in Chrome => this time, only visible in Chrome; no message arrived > at the Firefox browser -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4433) Socket parameters are not validated
[
https://issues.apache.org/jira/browse/AMQ-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-4433:
-
Fix Version/s: 5.9.1
> Socket parameters are not validated
> ---
>
> Key: AMQ-4433
> URL: https://issues.apache.org/jira/browse/AMQ-4433
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Transport
>Reporter: Christoffer Sawicki
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 5.9.1, 5.10.0
>
> Attachments: 0001-Validate-socket-parameters.patch,
> 0002-Validate-connector-parameters.patch,
> 0003-Validate-transport-parameters.patch
>
>
> Connect parameters are validated in every transport factory with a statement
> like this:
> {noformat}
> if (!options.isEmpty()) {
> throw new IllegalArgumentException("Invalid connect parameters: " +
> options);
> }
> {noformat}
> Socket parameters (i.e. connect parameters prefixed with {{socket.}}) are
> however never validated.
> They are put away at
> {noformat}
> TcpTransportFactory.compositeConfigure(Transport, WireFormat, Map) line: 85
> {noformat}
> and then set at
> {noformat}
> TcpTransport.initialiseSocket(Socket) line: 428
> {noformat}
> where there is no check that {{socketOptions}} is empty after the call.
> I've attached a patch (#1) that rectifies this.
> Bonus: I found similar issues in the transport classes. See patch #2 and #3.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-4841) lease-database-locker does not use the configured tablePrefix in UPDATE statement
[
https://issues.apache.org/jira/browse/AMQ-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-4841:
-
Fix Version/s: 5.9.1
> lease-database-locker does not use the configured tablePrefix in UPDATE
> statement
> --
>
> Key: AMQ-4841
> URL: https://issues.apache.org/jira/browse/AMQ-4841
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.9.0
> Environment: - tested on latest trunk
>Reporter: Pat Fox
>Assignee: Claus Ibsen
> Fix For: 5.9.1, 5.10.0
>
> Attachments: JDBCLockTablePrefixTest.java
>
>
> Using the configuration
> {code}
>
>dataSource="#mysql-ds" lockKeepAlivePeriod="5000">
>
>
>
>
>durableSubAcksTableName="AMQ_ACKS" lockTableName="AMQ_LOCK"/>
>
>
>
>
>
>
> {code}
> The logging show the Lock table was created WITH the configured prefix but
> the lease locker UPDATE statement does not use that prefix
> {code}
> 2013-10-30 14:33:03,245 | DEBUG | Executing SQL: CREATE TABLE TTT_AMQ_LOCK(
> ID BIGINT NOT NULL, TIME BIGINT, BROKER_NAME VARCHAR(250), PRIMARY KEY (ID) )
> ENGINE=INNODB | org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter |
> main
> ...
> 2013-10-30 14:33:10,889 | DEBUG | jdbcBroker, lease keepAlive Query is UPDATE
> ACTIVEMQ_LOCK SET BROKER_NAME=?, TIME=? WHERE BROKER_NAME=? AND ID = 1 |
> org.apache.activemq.store.jdbc.LeaseDatabaseLocker | ActiveMQ JDBC PA
> Scheduled Task
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-4685) LDAPLoginModule throws InvalidNameException when resolving LDAP aliases
[
https://issues.apache.org/jira/browse/AMQ-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-4685:
-
Fix Version/s: 5.9.1
> LDAPLoginModule throws InvalidNameException when resolving LDAP aliases
> ---
>
> Key: AMQ-4685
> URL: https://issues.apache.org/jira/browse/AMQ-4685
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.x
> Environment: OS Independent
> OpenLDAP 2.4
>Reporter: Igor Podolskiy
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 5.9.1, 5.10.0
>
> Attachments: handle-ldap-aliases-v1.patch
>
>
> Some LDAP servers allow you to define aliases for objects. For example,
> consider the following LDAP directory layout:
> {code}
> dc=example,dc=com
>ou=ActiveMQ
> ou=Users
> ou=Roles
> ou=Destinations
>ou=People
> {code}
> In this layout, accounts specific to ActiveMQ go under ou=Users,ou=ActiveMQ.
> However, some accounts in ou=People should also be able to have access to the
> ActiveMQ server. To avoid duplicating accounts, you can have the regular
> account (objectClass=inetOrgPerson) in ou=People and create an LDAP alias
> (objectClass=alias) for it in ou=People. The LDAP server then takes care
> about the alias resolution.
> The JNDI LDAP client supports LDAP alias dereferencing as well. However, the
> search results for resolved aliases are different. For regular entries,
> SearchResult.getName() returns a relative DN and SearchResult.isRelative()
> returns true; for dereferenced aliases, SearchResult.getName() returns a full
> LDAP URI with the DN of the alias target (for example,
> 'ldap://localhost:389/uid=bob,ou=People,dc=example,dc=com') and
> SearchResult.isRelative() returns false (as documented, for example, in [1]).
> The code in o.a.a.jaas.LDAPLoginModule does not make this distinction. It
> assumes that all returned names are RDNs and passes them to
> NameParser.parse() which in turn raises a NamingException because an LDAP URI
> is obviously not an LDAP (R)DN.
> The attached patch resolved the problem at least for my configuration. If
> isRelative() returns false, the name is parsed as an URI. Per definition of
> LDAP URIs, the path component is the distinguished name, which is then taken.
> Of course, this does not take care of multiple layers of aliases, aliases for
> containers and so on - I just found it over the course of setting up LDAP
> authentication in my system, which happens only to alias user accounts. It
> works for me with the patch and seems not to make things worse :) If needed,
> maybe I can do some further tests and/or correct the patch.
> [1] http://docs.oracle.com/javase/jndi/tutorial/ldap/misc/aliases.html
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-4746) Applet ClassLoader Problems
[
https://issues.apache.org/jira/browse/AMQ-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-4746:
-
Fix Version/s: 5.9.1
> Applet ClassLoader Problems
> ---
>
> Key: AMQ-4746
> URL: https://issues.apache.org/jira/browse/AMQ-4746
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
>Affects Versions: 5.7.0, 5.8.0
> Environment: Windows 7, Java 1.7 or 1.6, Applet
>Reporter: Calvin Moody
>Assignee: Claus Ibsen
>Priority: Minor
> Labels: ClassLoader
> Fix For: 5.9.1, 5.10.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Applets fail to deserailize messages in a timely manner after a network
> failure triggers a reconnect using the FailoverTransport
> In ClassLoadingAwareObjectInputStream.java the load() method makes a call to
> Class.forName().
> For the primitive types (int, boolean, etc.) this would result in a call
> similar to:
> Class.forName("int", false, loader); //Where loader is the
> Applet2ClassLoader
> Since Applet2ClassLoader is a URLClassLoader and "int.class" is not in the
> jar cache it pulled down from the server at the start of application, it is
> going to try and go to the server to resolve this class.
> In the event of a network failure, this will result in the ClassLoader having
> to wait for the socket timeout. (see stacktrace at link) Once this socket
> timeout occurs, the load() method then attempts to lookup the class in the
> primitive HashMap that is statically initialized. This returns the class for
> the int and the deserialization continues on.
> At first it seemed like the messages were failing to be received but it
> turned out they were just taking a very long time to be deserialized. This
> problem can be avoided by changing the order in which
> ClassLoadingAwareObjectInputStream tries to resolve the class.
> Here is the change I made to the load() method:
> http://activemq.2283324.n4.nabble.com/Applet-Class-Loader-Problems-td4671835.html
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-3350) amq.js initHandler() method swallows first message received
[
https://issues.apache.org/jira/browse/AMQ-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-3350:
-
Fix Version/s: 5.9.1
> amq.js initHandler() method swallows first message received
> ---
>
> Key: AMQ-3350
> URL: https://issues.apache.org/jira/browse/AMQ-3350
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.5.0
> Environment: MAC OS X (10.6)
>Reporter: Ken Seiss
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 5.9.1, 5.10.0
>
>
> The very first message received by a javascript client (when using
> {{amq.js}}) is swallowed with no action. This is because the {{sendPoll()}}
> method calls {{initHandler()}} from the {{successCallback}} handler when the
> message arrives and the boolean {{sessionInitialized}} is false. This sends
> the code into the {{initHandler()}} method which in the end just calls
> {{sendPoll()}} again. It never bothers calling {{pollHandler()}} to deal
> with the message it received.
> {code:title=amq.js|borderStyle=solid}
> // *** This method does not process the data passed in. It just calls
> sendPoll() again!
> var initHandler = function(data) {
> sessionInitialized = true;
> if(sessionInitializedCallback) {
> sessionInitializedCallback();
> }
> sendPoll();
> }
> var sendPoll = function() {
> // Workaround IE6 bug where it caches the response
> // Generate a unique query string with date and random
> var now = new Date();
> var timeoutArg = sessionInitialized ? timeout : 0.001;
> var data = 'timeout=' + timeoutArg * 1000
>+ '&d=' + now.getTime()
>+ '&r=' + Math.random();
> var successCallback = sessionInitialized ? pollHandler :
> initHandler;
>
> var options = { method: 'get',
> data: addClientId( data ),
> success: successCallback,
> error: pollErrorHandler};
> adapter.ajax(uri, options);
> };
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-4826) Avoid unnecessary remainder operator for floating-point
[ https://issues.apache.org/jira/browse/AMQ-4826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4826: - Fix Version/s: 5.9.1 > Avoid unnecessary remainder operator for floating-point > --- > > Key: AMQ-4826 > URL: https://issues.apache.org/jira/browse/AMQ-4826 > Project: ActiveMQ > Issue Type: Improvement > Components: Transport >Affects Versions: 5.9.0 > Environment: OS: OpenSUSE 12.2 > JDK: Linux ARM Softfloat(jdk-7u45-linux-arm-vfp-sflt.tar.gz) > Hardware: pandaboard >Reporter: Ryuken SEKI >Assignee: Claus Ibsen >Priority: Minor > Fix For: 5.9.1, 5.10.0 > > > I installed jdk-7u45-linux-arm-vfp-sflt.tar.gz on my pandaboard, and found > that this jdk has a problem of remainder operator for floating point. So, if > you starts ActiveMQ in above environment, you might encounter > IndexOutOfBoundsException at > > org.apache.activemq.transport.failover.FailoverTransport.getConnectList(FailoverTransport.java:779) > This is because > int p = (int) (Math.random() * 100 % l.size()); > above p gets larger number than "l.size" contrary to your expectation. This > problem doesn't occur in case of x86 Architecture or ARM Hardfloat JDK. > This is a problem of ARM Softfloat JDK, but I think it's better to avoid > unnecessary remainder operator for floating-point for safety. So, > int p = ((int) Math.random() * 100) % l.size(); > would be better than current one. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4325) camel doen't honor credentials set on activemqcomponent bean via spring
[ https://issues.apache.org/jira/browse/AMQ-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4325: - Fix Version/s: 5.9.1 > camel doen't honor credentials set on activemqcomponent bean via spring > --- > > Key: AMQ-4325 > URL: https://issues.apache.org/jira/browse/AMQ-4325 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-camel >Affects Versions: 5.8.0 > Environment: activemq 5.8.0 >Reporter: Kot Kot >Assignee: Claus Ibsen > Fix For: 5.9.1, 5.10.0 > > > I use this configuration to create activemq component. >class="org.apache.activemq.camel.component.ActiveMQComponent" > factory-method="activeMQComponent"> > > > > > > Endpoint url doesn't have username and password set which results jms client > not being able to connect to broker which responds with "username is null". > Setting username and password in endpoint url works -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-2536) XPath selectors return false if xalan is not on the classpath
[
https://issues.apache.org/jira/browse/AMQ-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-2536:
-
Fix Version/s: 5.9.1
> XPath selectors return false if xalan is not on the classpath
> -
>
> Key: AMQ-2536
> URL: https://issues.apache.org/jira/browse/AMQ-2536
> Project: ActiveMQ
> Issue Type: Bug
> Components: Selector
>Affects Versions: 5.3.0
>Reporter: Roman Kalukiewicz
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 5.9.1, 5.10.0
>
>
> When xalan.jar is not on the classpath, then
> {{org.apache.activemq.filter.XalanXPathEvaluator}} in {{evaluate()}} method
> tries to load {{org.apache.xpath.CachedXPathAPI}}, throws
> {{NoClassDefFoundError}}, that is catched as {{Throwable}} and {{false}} is
> returned instead of an error.
> No clue is given to the client, that it lacks a jar on the classpath and the
> impression is, that XPath selectors doesn't work and return false whatever
> the message is.
> I believe if we catch {{Exception}} instead of {{Throwable}}, then the
> problem would be fixed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-2960) PooledConnectionFactoryBean returns null in OSGi env sometimes
[
https://issues.apache.org/jira/browse/AMQ-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-2960:
-
Fix Version/s: 5.9.1
> PooledConnectionFactoryBean returns null in OSGi env sometimes
> --
>
> Key: AMQ-2960
> URL: https://issues.apache.org/jira/browse/AMQ-2960
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Environment: ServiceMix-4.2.0-fuse-02-00, spring-osgi 1.2.1, spring
> 2.5.6.SEC02
>Reporter: Volodymyr Buell
>Assignee: Claus Ibsen
> Fix For: 5.9.1, 5.10.0
>
> Attachments:
> PooledConnectionFactoryBean-lazy-initialization-workaround-for-null.patch
>
>
> From time to time PooledConnectionFactoryBean failed to initialize itself
> correctly in ServiceMix 4 (FUSE actually). From activemq-broker.xml:
> Exception in thread "SpringOsgiExtenderThread-20"
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'pooledConnectionFactory' defined in URL
> [bundleentry://110.fwk173823/META-INF/spring/activemq-broker.xml]:
> factory-bean 'pooledConnectionFactoryFactory' returned null
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:289)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:903)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:817)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:440)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
> at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:728)
> at
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:69)
> at
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:355)
> at
> org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
> at
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320)
> at
> org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:132)
> at java.lang.Thread.run(Thread.java:619)
> The problem is that Spring sometimes invokes @PreConstruct *AFTER* the
> getObject() has been used for dependent beans constructing. Therefore
> PooledConnectionFactoryBean.getObject() returns null.
> Lazy initialization is fixing this issue:
> public Object getObject() throws Exception {
> if (pooledConnectionFactory == null)
> {
> afterPropertiesSet();
> }
> return pooledConnectionFactory;
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-4849) runtime config - support modifications to simpleAuthenticationPlugin plugin
[ https://issues.apache.org/jira/browse/AMQ-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4849: - Fix Version/s: 5.9.1 > runtime config - support modifications to simpleAuthenticationPlugin plugin > --- > > Key: AMQ-4849 > URL: https://issues.apache.org/jira/browse/AMQ-4849 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.9.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: authentication, runtimeConfiguration > Fix For: 5.9.1, 5.10.0 > > > it makes sense to support mods to the simpleAuthenticationPlugin users > considering we support mods to the simpleAuthorization plugin. If the broker > user permissions are locked down it is a reasonable approach. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4852) Show clientId view of duplex network connection Mbeans
[ https://issues.apache.org/jira/browse/AMQ-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4852: - Fix Version/s: 5.9.1 > Show clientId view of duplex network connection Mbeans > -- > > Key: AMQ-4852 > URL: https://issues.apache.org/jira/browse/AMQ-4852 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 5.9.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: clientId, connection, jmx, mbean, networkConnector > Fix For: 5.9.1, 5.10.0 > > Attachments: AMQ-4852.patch > > > from > http://mail-archives.apache.org/mod_mbox/activemq-users/201311.mbox/%3c35ec11a1-a490-4942-86d8-1238ea085...@schubergphilis.com%3E > with duplex=true we only have the clientip view, the connectionInfo bypasses > the initiating connection b/c that is now bridging to the local broker. > I think we can fix this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4855) Typos in SubscriptionInfo
[ https://issues.apache.org/jira/browse/AMQ-4855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4855: - Fix Version/s: 5.9.1 > Typos in SubscriptionInfo > - > > Key: AMQ-4855 > URL: https://issues.apache.org/jira/browse/AMQ-4855 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 > Environment: All supported environments. >Reporter: Fernando Ribeiro >Assignee: Timothy Bish >Priority: Minor > Fix For: 5.9.1, 5.10.0 > > Attachments: activemq.patch > > > The typos in properties "subcriptionId" and "subcriptionName" require changes > in multiple classes, but should be fixed, even if only in a major release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4855) Typos in SubscriptionInfo
[ https://issues.apache.org/jira/browse/AMQ-4855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4855: - Assignee: Timothy Bish > Typos in SubscriptionInfo > - > > Key: AMQ-4855 > URL: https://issues.apache.org/jira/browse/AMQ-4855 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 > Environment: All supported environments. >Reporter: Fernando Ribeiro >Assignee: Timothy Bish >Priority: Minor > Fix For: 5.9.1, 5.10.0 > > Attachments: activemq.patch > > > The typos in properties "subcriptionId" and "subcriptionName" require changes > in multiple classes, but should be fixed, even if only in a major release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4854) JmsRollbackRedeliveryTest.testRedeliveryWithPrefetch1 fails intermittently
[ https://issues.apache.org/jira/browse/AMQ-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4854: - Fix Version/s: 5.10.0 5.9.1 > JmsRollbackRedeliveryTest.testRedeliveryWithPrefetch1 fails intermittently > -- > > Key: AMQ-4854 > URL: https://issues.apache.org/jira/browse/AMQ-4854 > Project: ActiveMQ > Issue Type: Bug > Components: Test Cases >Reporter: Kevin Earls >Assignee: Kevin Earls >Priority: Minor > Fix For: 5.9.1, 5.10.0 > > > This tests fails on some CI boxes and slow machines > javax.jms.JMSException: peer (vm://localhost#5) stopped. > at > org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54) > at > org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1405) > at > org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1510) > at > org.apache.activemq.ActiveMQConnection.start(ActiveMQConnection.java:524) > at > org.apache.activemq.JmsRollbackRedeliveryTest.doTestRedelivery(JmsRollbackRedeliveryTest.java:84) > at > org.apache.activemq.JmsRollbackRedeliveryTest.testRedeliveryWithPrefetch1(JmsRollbackRedeliveryTest.java:76) > 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 junit.framework.TestCase.runTest(TestCase.java:176) > at junit.framework.TestCase.runBare(TestCase.java:141) > at junit.framework.TestResult$1.protect(TestResult.java:122) > at junit.framework.TestResult.runProtected(TestResult.java:142) > at junit.framework.TestResult.run(TestResult.java:125) > at junit.framework.TestCase.run(TestCase.java:129) > at junit.framework.TestSuite.runTest(TestSuite.java:255) > at junit.framework.TestSuite.run(TestSuite.java:250) > at > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > 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.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:81) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > Caused by: org.apache.activemq.transport.TransportDisposedIOException: peer > (vm://localhost#5) stopped. > at > org.apache.activemq.transport.vm.VMTransport.stop(VMTransport.java:205) > at > org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:65) > at > org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:65) > at > org.apache.activemq.transport.ResponseCorrelator.stop(ResponseCorrelator.java:132) > at > org.apache.activemq.broker.TransportConnection.doStop(TransportConnection.java:1071) > at > org.apache.activemq.broker.TransportConnection$4.run(TransportConnection.java:1037) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4869) Wrong JMX object name created in RemoteJMXBrokerFacade
[ https://issues.apache.org/jira/browse/AMQ-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4869: - Assignee: Timothy Bish > Wrong JMX object name created in RemoteJMXBrokerFacade > -- > > Key: AMQ-4869 > URL: https://issues.apache.org/jira/browse/AMQ-4869 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.9.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 5.9.1, 5.10.0 > > > When a broker name is given the console code create the wrong broker object > name -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4853) Advisory support leads to excessive CPU usage
[ https://issues.apache.org/jira/browse/AMQ-4853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4853: - Fix Version/s: 5.9.1 > Advisory support leads to excessive CPU usage > - > > Key: AMQ-4853 > URL: https://issues.apache.org/jira/browse/AMQ-4853 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 >Reporter: Joshua Watkins >Assignee: Timothy Bish > Fix For: 5.9.1, 5.10.0 > > Attachments: amqAdvirsoryCPUIssue.jpg > > > After upgrading from AMQ 5.8 to 5.9 we have seen cpu usage continually climb > until AMQ threads are taking nearly all of the CPU Resources while remaining > fairly idle. This is just a single broker with advisory support on. (Advisory > support is on in this case as we run the same config for a network of > brokers.) Turning off advisory support reduced the CPU load to single digits. > top -H output: > Cpu(s): 97.8%us, 2.1%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st > Mem: 7872040k total, 6574324k used, 1297716k free, 301028k buffers > Swap:0k total,0k used,0k free, 1635392k cached > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > > 25476 root 16 0 2173m 891m 11m R 14.4 11.6 86:12.10 java > > > 25472 root 15 0 2173m 891m 11m R 13.6 11.6 86:09.77 java > > > 25155 root 16 0 2173m 891m 11m R 9.8 11.6 86:26.13 java > > > 25471 root 16 0 2173m 891m 11m R 9.2 11.6 86:12.93 java > > > 25514 root 16 0 2173m 891m 11m R 9.2 11.6 86:15.12 java > > > 25202 root 16 0 2173m 891m 11m R 8.7 11.6 86:33.20 java > > > 25189 root 16 0 2173m 891m 11m S 8.4 11.6 86:24.65 java > > > 25274 root 16 0 2173m 891m 11m R 8.1 11.6 86:18.45 java > > > 19272 root 15 0 2173m 891m 11m S 8.1 11.6 8:40.19 java > > > 20039 root 15 0 2173m 891m 11m S 8.1 11.6 8:15.53 java > > > 19270 root 15 0 2173m 891m 11m R 7.8 11.6 8:35.85 java > > > 25134 root 16 0 2173m 891m 11m R 7.5 11.6 90:42.29 java > > > 25259 root 15 0 2173m 891m 11m R 7.5 11.6 90:30.02 java > > > 25474 root 16 0 2173m 891m 11m R 7.5 11.6 86:13.24 java > > > 25475 root 16 0 2173m 891m 11m R 7.5 11.6 86:11.74 java > > > 25483 root 16 0 2173m 891m 11m R 7.5 11.6 86:12.30 java > >
[jira] [Updated] (AMQ-4857) WSServlet.doWebSocketConnect throws NPE if called with null protocol
[ https://issues.apache.org/jira/browse/AMQ-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4857: - Assignee: Kevin Earls > WSServlet.doWebSocketConnect throws NPE if called with null protocol > > > Key: AMQ-4857 > URL: https://issues.apache.org/jira/browse/AMQ-4857 > Project: ActiveMQ > Issue Type: Bug >Reporter: Kevin Earls >Assignee: Kevin Earls > Fix For: 5.9.1, 5.10.0 > > > I got the NPE shown below while working on a websocket demo. > WebSocketFactory.acceptWebSocket calls WSServlet.doWebSocketConnect with the > protocol hard coded to null. > java.lang.NullPointerException > at > org.apache.activemq.transport.ws.WSServlet.doWebSocketConnect(WSServlet.java:54) > at > org.eclipse.jetty.websocket.WebSocketFactory.acceptWebSocket(WebSocketFactory.java:372) > at > org.eclipse.jetty.websocket.WebSocketServlet.service(WebSocketServlet.java:104) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:445) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) > at org.eclipse.jetty.server.Server.handle(Server.java:367) > at > org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:486) > at > org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:926) > at > org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:988) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) > at > org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4857) WSServlet.doWebSocketConnect throws NPE if called with null protocol
[ https://issues.apache.org/jira/browse/AMQ-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4857: - Fix Version/s: 5.10.0 5.9.1 > WSServlet.doWebSocketConnect throws NPE if called with null protocol > > > Key: AMQ-4857 > URL: https://issues.apache.org/jira/browse/AMQ-4857 > Project: ActiveMQ > Issue Type: Bug >Reporter: Kevin Earls >Assignee: Kevin Earls > Fix For: 5.9.1, 5.10.0 > > > I got the NPE shown below while working on a websocket demo. > WebSocketFactory.acceptWebSocket calls WSServlet.doWebSocketConnect with the > protocol hard coded to null. > java.lang.NullPointerException > at > org.apache.activemq.transport.ws.WSServlet.doWebSocketConnect(WSServlet.java:54) > at > org.eclipse.jetty.websocket.WebSocketFactory.acceptWebSocket(WebSocketFactory.java:372) > at > org.eclipse.jetty.websocket.WebSocketServlet.service(WebSocketServlet.java:104) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:445) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) > at org.eclipse.jetty.server.Server.handle(Server.java:367) > at > org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:486) > at > org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:926) > at > org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:988) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) > at > org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4869) Wrong JMX object name created in RemoteJMXBrokerFacade
[ https://issues.apache.org/jira/browse/AMQ-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4869: - Fix Version/s: 5.10.0 5.9.1 > Wrong JMX object name created in RemoteJMXBrokerFacade > -- > > Key: AMQ-4869 > URL: https://issues.apache.org/jira/browse/AMQ-4869 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.9.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 5.9.1, 5.10.0 > > > When a broker name is given the console code create the wrong broker object > name -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4881) Align xbean and upgrade to 3.15
[ https://issues.apache.org/jira/browse/AMQ-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4881: - Fix Version/s: 5.9.1 > Align xbean and upgrade to 3.15 > --- > > Key: AMQ-4881 > URL: https://issues.apache.org/jira/browse/AMQ-4881 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 5.9.1, 5.10.0 > > > We use xbean 3.14 and 3.12 for the maven plugin. We should align these > versions and use latest 3.15. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-3388) Http/https protocol uses Xstream for serializing commands in xml. Field additions to the commands bresks xtream serializacion between amq versions
[
https://issues.apache.org/jira/browse/AMQ-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-3388:
-
Fix Version/s: 5.9.1
> Http/https protocol uses Xstream for serializing commands in xml. Field
> additions to the commands bresks xtream serializacion between amq versions
> ---
>
> Key: AMQ-3388
> URL: https://issues.apache.org/jira/browse/AMQ-3388
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Transport
>Affects Versions: 5.4.1, 5.4.2, 5.5.0
>Reporter: Marcel Casado
>Assignee: Timothy Bish
> Fix For: 5.9.1, 5.10.0
>
> Attachments: AMQ-3388.patch
>
>
> Addition of fields in commands used between clients and brokers in newer amq
> versions breaks easily the http transport that uses xstream for xml
> serialization.
> To make xstream more tolerant to this changes between versions in
> org.apache.activemq.transport.xstream.XStreamWireFormat we could add the code
> below so xstream ignores unknown fields :
> // Implementation methods
> //
> -
> protected XStream createXStream() {
>// return new XStream();
>return new XStream() {
> protected MapperWrapper wrapMapper(MapperWrapper next) {
> return new MapperWrapper(next) {
> public boolean shouldSerializeMember(Class definedIn,
> String fieldName) {
> return definedIn != Object.class ?
> super.shouldSerializeMember(definedIn, fieldName) : false;
> }
> };
> }
> };
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-4719) Enable "Link Stealing" as an option on a Connector
[ https://issues.apache.org/jira/browse/AMQ-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4719: - Fix Version/s: 5.9.1 > Enable "Link Stealing" as an option on a Connector > -- > > Key: AMQ-4719 > URL: https://issues.apache.org/jira/browse/AMQ-4719 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Reporter: Rob Davies >Assignee: Rob Davies > Fix For: 5.9.1, 5.10.0 > > > The JMS Spec states that connecting with a duplicate ClientID should throw an > Exception. However, for MQTT and AMQP specs "Link Stealing" where the last > ClientID pushes out the older connection with the same ClientID should be > supported. ActiveMQ supports link stealing for connections with a duplicate > ConnectionID - though the ConnectionID is not something supported by MQTT or > AMQP. Make Link Stealing optional - so it can be set on by default for MQTT > and AMQP TransportConnectors -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-2505) Problem with servicing broker messages when client hostName contains "language specific" characters (org.apache.activemq.util.IdGenerator problem)
[ https://issues.apache.org/jira/browse/AMQ-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-2505: - Fix Version/s: 5.9.1 > Problem with servicing broker messages when client hostName contains > "language specific" characters (org.apache.activemq.util.IdGenerator problem) > -- > > Key: AMQ-2505 > URL: https://issues.apache.org/jira/browse/AMQ-2505 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.2.0 > Environment: Windows XP SP2 >Reporter: Pawel Sniezek >Assignee: Claus Ibsen >Priority: Minor > Fix For: 5.9.1, 5.10.0 > > > When name of the activeMQ client machine contains "language specific" letters > (e.g. "Gł_Ksiegowa") communication fails: > "Caused by: java.io.IOException: Failed to broker message: > ID:Gł_Ksiegowa-1407-1256558735734-0:2:3:1:1 in container: > java.io.UTFDataFormatException: bad string " > To resolve the problem in our system we've changed > org.apache.activemq.util.IdGenerator code - we replaced line: > "hostName = InetAddress.getLocalHost().getHostName();" > with: > "hostName = InetAddress.getLocalHost().getHostAddress();" > The whole exception below: > ERROR 2009-10-26 13:07:30,781 [AWT-EventQueue-0] - Local JMS transaction > failed to commit; nested exception is javax.jms.JMSException: POST COMMIT > FAILED > org.springframework.jms.connection.SynchedLocalTransactionFailedException: > Local JMS transaction failed to commit; nested exception is > javax.jms.JMSException: POST COMMIT FAILED > at > org.springframework.jms.connection.ConnectionFactoryUtils$JmsResourceSynchronization.processResourceAfterCommit(ConnectionFactoryUtils.java:408) > > at > org.springframework.transaction.support.ResourceHolderSynchronization.afterCommit(ResourceHolderSynchronization.java:74) > > at > org.springframework.transaction.support.TransactionSynchronizationUtils.invokeAfterCommit(TransactionSynchronizationUtils.java:114) > > at > org.springframework.transaction.support.TransactionSynchronizationUtils.triggerAfterCommit(TransactionSynchronizationUtils.java:100) > > at > org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerAfterCommit(AbstractPlatformTransactionManager.java:931) > > at > org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:774) > > at > org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:701) > > at > org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321) > > at > org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116) > > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) > > at > org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:635) > > at > info.fingo.asist.gui.controls.periodslist.status.ReportStatusHelper$$EnhancerByCGLIB$$2dab363.changeReportsStatus() > > at > info.fingo.asist.action.ChangeReportStatusAction.asistActionPerformed(ChangeReportStatusAction.java:30) > > at > info.fingo.asist.action.MultiReportAction.asistActionPerformed(MultiReportAction.java:80) > > at > info.fingo.asist.action.AsistAction.fireAsistActionPerformed(AsistAction.java:297) > > at info.fingo.asist.action.AsistAction.actionPerformed(AsistAction.java:322) > at javax.swing.AbstractButton.fireActionPerformed(Unknown Source) > at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source) > at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source) > at javax.swing.DefaultButtonModel.setPressed(Unknown Source) > at javax.swing.AbstractButton.doClick(Unknown Source) > at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source) > at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown > Source) > at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) > at java.awt
[jira] [Updated] (AMQ-4884) Wildcard matches do not match
[ https://issues.apache.org/jira/browse/AMQ-4884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4884: - Fix Version/s: 5.9.1 > Wildcard matches do not match > - > > Key: AMQ-4884 > URL: https://issues.apache.org/jira/browse/AMQ-4884 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.8.0, 5.9.0 >Reporter: Rob Davies >Assignee: Rob Davies > Fix For: 5.9.1, 5.10.0 > > > If you subscribe to a Wildcard Destination (e.g. a Topic) - with an name > A.*.> then a message sent to a Destination A.B should match that Wildcard and > be assigned to that Subscriber. This is not the case currently. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4706) Failover transport - Add option to configure WARN logging internval for failover attempts still failing
[
https://issues.apache.org/jira/browse/AMQ-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-4706:
-
Fix Version/s: 5.9.1
> Failover transport - Add option to configure WARN logging internval for
> failover attempts still failing
> ---
>
> Key: AMQ-4706
> URL: https://issues.apache.org/jira/browse/AMQ-4706
> Project: ActiveMQ
> Issue Type: Improvement
> Components: activemq-camel
>Affects Versions: 5.8.0
>Reporter: Claus Ibsen
>Assignee: Timothy Bish
> Fix For: 5.9.1, 5.10.0
>
>
> The failover transport
> http://activemq.apache.org/failover-transport-reference.html
> If a client is constantly trying to failover and re-connect but can't do this
> for a long time, then it would be nice if there was a WARN log once in a
> while to indicate that.
> So if there is a new option people can turn on to log that, or have a
> sensible default so its out of the box
> For example
> {code}
> reconnectWarnLogInterval=3
> {code}
> Which then logs every 30 sec if failover/reconnect is still failing. People
> can then turn that off with 0, -1 or set a higher value if 30 sec is too
> frequent.
> See also
> http://camel.465427.n5.nabble.com/bundle-stays-in-state-creating-tp5738312.html
> For people using ServiceMix it may cause their bundles to keep in grace mode,
> and they cant understand why. So if there is at least some WARN log activity
> then they would understand better.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-4886) AMQ2149LevelDBTest hangs or fails frequently
[ https://issues.apache.org/jira/browse/AMQ-4886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4886: - Fix Version/s: 5.10.0 > AMQ2149LevelDBTest hangs or fails frequently > > > Key: AMQ-4886 > URL: https://issues.apache.org/jira/browse/AMQ-4886 > Project: ActiveMQ > Issue Type: Bug >Reporter: Kevin Earls >Assignee: Kevin Earls > Fix For: 5.10.0 > > Attachments: AMQ2149LevelDBTest.stack > > > I'll update this as I get more information, but this test suite has multiple > cases that hang and timeout frequently > (testTopicTransactionalOrderWithRestart and testTopicOrderWithRestart seem to > do so most frequently.) > It can also hang in tearDown, which causes the whole suite to hang without > timing out, which can be a problem when run under Hudson or Jenkins. > I will attach a stack trace of the tearDown hang, and also update > AMQ2149Test to prevent this. I'm also going to update the test to use JUnit4 > and reduce the timeouts from 30 to 5 minutes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-3922) HSQLDB support is broken as wrong data type is used in HsqldbJDBCAdapter.java
[ https://issues.apache.org/jira/browse/AMQ-3922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-3922: - Fix Version/s: 5.9.1 > HSQLDB support is broken as wrong data type is used in HsqldbJDBCAdapter.java > - > > Key: AMQ-3922 > URL: https://issues.apache.org/jira/browse/AMQ-3922 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.6.0 >Reporter: Fred Toussi >Assignee: Claus Ibsen >Priority: Minor > Fix For: 5.9.1, 5.10.0 > > > The HsqldbJDBCAdaptor defines the SQL type used for storing a lob as "OTHER". > This is wrong in principle, as this type is intended for storing complex > serialized objects, not specifically lobs. With this type, the JDBC setObject > and getObject methods must be used to store and retrieve the object (which is > not the case with ActiveMQ). > The problem has been encountered and reported in TOMEE-233 and elsewhere. > With HSQLDB version 2.x, the type "BLOB" should be used for maximum storage > capacity and minimum memory use by the database engine. This type is > supported in all modes of operation, including in-memory and file databases. > It seems a simple switch from "OBJECT" to "BLOB" in the code should do the > job, as the JDBC setBytes and getBytes methods used by the superclass are > compatible with the BLOB type. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4897) Race condition in failover transport
[ https://issues.apache.org/jira/browse/AMQ-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4897: - Fix Version/s: 5.9.1 > Race condition in failover transport > > > Key: AMQ-4897 > URL: https://issues.apache.org/jira/browse/AMQ-4897 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.9.0 >Reporter: Dejan Bosanac >Assignee: Dejan Bosanac > Fix For: 5.9.1, 5.10.0 > > > There's a small chance of the race condition when using priority backup with > extremely small reconnect delay (0). In that case, the failover transport > will get into inconsistent state. The client will stay connected to the > "non-priority" broker, but the priority backup will not be created due to > this inconsistency. > The solution is to synchronise handling of connection failure with the > reconnect mutex. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4856) Change MIME type for XML in the REST API
[ https://issues.apache.org/jira/browse/AMQ-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4856: - Fix Version/s: 5.9.1 > Change MIME type for XML in the REST API > > > Key: AMQ-4856 > URL: https://issues.apache.org/jira/browse/AMQ-4856 > Project: ActiveMQ > Issue Type: Improvement > Components: Connector >Affects Versions: 5.9.0 > Environment: All supported environments. >Reporter: Fernando Ribeiro >Assignee: Claus Ibsen >Priority: Minor > Fix For: 5.9.1, 5.10.0 > > Attachments: activemq.patch > > > According to RFC 3023, "if an XML document is readable by casual users, > text/xml is preferable to application/xml. MIME user agents (and web user > agents) that do not have explicit support for text/xml will treat it as > text/plain, for example, by displaying the XML MIME entity as plain text. > Application/xml is preferable when the XML MIME entity is unreadable by > casual users". > Several other projects supported by Red Hat (Drools, Infinispan, OpenShift) > already comply with this RFC. -- This message was sent by Atlassian JIRA (v6.2#6252)
