You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by softwbc <so...@163.com> on 2015/07/01 10:32:26 UTC
Re: Using Broker clusters,
javax.management.InstanceAlreadyExistsException:xx
sorry! I mean second parts.Here is my application structure.
<http://activemq.2283324.n4.nabble.com/file/n4698434/%E6%B6%88%E6%81%AF%E5%B9%B3%E5%8F%B0%E6%9C%80%E7%BB%88%E7%BB%93%E6%9E%84ENG.jpg>
And I confirmed that the configuration is in effect.
<http://activemq.2283324.n4.nabble.com/file/n4698434/1.png>
<http://activemq.2283324.n4.nabble.com/file/n4698434/2.png>
Any other ideas?
--
View this message in context: http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4698434.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Using Broker clusters,
javax.management.InstanceAlreadyExistsException:xx
Posted by softwbc <so...@163.com>.
The problem occurs in the production environment.i cant to make a minimal
test case.
Later I will simulate the production environment configuration, determine
the problem in the test environment.
Thank you!
--
View this message in context: http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4699317.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Using Broker clusters, javax.management.InstanceAlreadyExistsException:xx
Posted by Tim Bain <tb...@alumni.duke.edu>.
As the submitter and implementer of AMQ-6052, Pablo Lozano, pointed out in
the comments, a better workaround that doesn't involve turning off logging
or JMX is to set gcDestinationViews="false" on the networkConnector. If
you can live without destination GCing (and most people can, unless they're
Kevin Burton), this is better than either of the other two workarounds.
On Fri, Jan 15, 2016 at 12:44 PM, Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:
> FYI, I'm hoping to do a 5.13.1 release in a week or 2 (if everything goes
> well and no blockers pop up), at which point you can upgrade to hopefully
> solve this issue. 5.14.0 probably won't be out for a while yet.
>
> On Fri, Jan 15, 2016 at 9:13 AM, Tim Bain <tb...@alumni.duke.edu> wrote:
>
> > Another way you could eliminate this problem (without turning off JMX) is
> > to change your log4j configuration to set the logging level to ERROR for
> > org.apache.activemq.network.MBeanBridgeDestination. You run the risk of
> > not seeing errors in MBean creation due to other reasons, but in practice
> > the odds of that are unlikely so there's really not much of a cost, and I
> > think that's better than disabling JMX entirely. Just remember to set it
> > back once you upgrade to a version where the bug is fixed.
> >
> > Tim
> >
> > On Wed, Jan 13, 2016 at 9:22 PM, Tim Bain <tb...@alumni.duke.edu> wrote:
> >
> > > I'd definitely expect that turning off JMX would eliminate the problem,
> > > since the issue happens when creating the objects JMX uses. I'm
> > skeptical
> > > that scheduler support would cause this problem if JMX support is
> > disabled,
> > > and skeptical that turning it off would eliminate the problem if JMX is
> > > enabled, so basically I expect that useJmx is the only setting you need
> > to
> > > change, not both of them.
> > >
> > > However, running without JMX support makes it much harder to diagnose
> > > issues in your broker if you experience them, so I'm not sure I'd
> choose
> > to
> > > turn off JMX support rather that just live with a noisy log file; log
> > lines
> > > that you know aren't a problem are easy to filter our or ignore, and
> I'd
> > > rather have JMX available if something starts not working, but it's
> your
> > > choice.
> > >
> > > Either way, I'd plan to upgrade to 5.14.0 when it's released, at which
> > > point you should definitely re-enable JMX support.
> > >
> > > Tim
> > >
> > > On Wed, Jan 13, 2016 at 6:25 PM, softwbc <so...@163.com> wrote:
> > >
> > >> I try the default configuration for ActiveMQ.
> > >> Now,I fount that the following two parameters could cause this
> problem:
> > >> useJmx="true" schedulerSupport="true"
> > >> When this configuration is removed,no warn has occurred. So far.
> > >>
> > >> but, Previously I tried to change to false.
> > >>
> > >> Thanks for your help.
> > >>
> > >>
> > >>
> > >> --
> > >> View this message in context:
> > >>
> >
> http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4705974.html
> > >> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> > >>
> > >
> > >
> >
>
Re: Using Broker clusters, javax.management.InstanceAlreadyExistsException:xx
Posted by Christopher Shannon <ch...@gmail.com>.
FYI, I'm hoping to do a 5.13.1 release in a week or 2 (if everything goes
well and no blockers pop up), at which point you can upgrade to hopefully
solve this issue. 5.14.0 probably won't be out for a while yet.
On Fri, Jan 15, 2016 at 9:13 AM, Tim Bain <tb...@alumni.duke.edu> wrote:
> Another way you could eliminate this problem (without turning off JMX) is
> to change your log4j configuration to set the logging level to ERROR for
> org.apache.activemq.network.MBeanBridgeDestination. You run the risk of
> not seeing errors in MBean creation due to other reasons, but in practice
> the odds of that are unlikely so there's really not much of a cost, and I
> think that's better than disabling JMX entirely. Just remember to set it
> back once you upgrade to a version where the bug is fixed.
>
> Tim
>
> On Wed, Jan 13, 2016 at 9:22 PM, Tim Bain <tb...@alumni.duke.edu> wrote:
>
> > I'd definitely expect that turning off JMX would eliminate the problem,
> > since the issue happens when creating the objects JMX uses. I'm
> skeptical
> > that scheduler support would cause this problem if JMX support is
> disabled,
> > and skeptical that turning it off would eliminate the problem if JMX is
> > enabled, so basically I expect that useJmx is the only setting you need
> to
> > change, not both of them.
> >
> > However, running without JMX support makes it much harder to diagnose
> > issues in your broker if you experience them, so I'm not sure I'd choose
> to
> > turn off JMX support rather that just live with a noisy log file; log
> lines
> > that you know aren't a problem are easy to filter our or ignore, and I'd
> > rather have JMX available if something starts not working, but it's your
> > choice.
> >
> > Either way, I'd plan to upgrade to 5.14.0 when it's released, at which
> > point you should definitely re-enable JMX support.
> >
> > Tim
> >
> > On Wed, Jan 13, 2016 at 6:25 PM, softwbc <so...@163.com> wrote:
> >
> >> I try the default configuration for ActiveMQ.
> >> Now,I fount that the following two parameters could cause this problem:
> >> useJmx="true" schedulerSupport="true"
> >> When this configuration is removed,no warn has occurred. So far.
> >>
> >> but, Previously I tried to change to false.
> >>
> >> Thanks for your help.
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4705974.html
> >> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >>
> >
> >
>
Re: Using Broker clusters, javax.management.InstanceAlreadyExistsException:xx
Posted by Tim Bain <tb...@alumni.duke.edu>.
Another way you could eliminate this problem (without turning off JMX) is
to change your log4j configuration to set the logging level to ERROR for
org.apache.activemq.network.MBeanBridgeDestination. You run the risk of
not seeing errors in MBean creation due to other reasons, but in practice
the odds of that are unlikely so there's really not much of a cost, and I
think that's better than disabling JMX entirely. Just remember to set it
back once you upgrade to a version where the bug is fixed.
Tim
On Wed, Jan 13, 2016 at 9:22 PM, Tim Bain <tb...@alumni.duke.edu> wrote:
> I'd definitely expect that turning off JMX would eliminate the problem,
> since the issue happens when creating the objects JMX uses. I'm skeptical
> that scheduler support would cause this problem if JMX support is disabled,
> and skeptical that turning it off would eliminate the problem if JMX is
> enabled, so basically I expect that useJmx is the only setting you need to
> change, not both of them.
>
> However, running without JMX support makes it much harder to diagnose
> issues in your broker if you experience them, so I'm not sure I'd choose to
> turn off JMX support rather that just live with a noisy log file; log lines
> that you know aren't a problem are easy to filter our or ignore, and I'd
> rather have JMX available if something starts not working, but it's your
> choice.
>
> Either way, I'd plan to upgrade to 5.14.0 when it's released, at which
> point you should definitely re-enable JMX support.
>
> Tim
>
> On Wed, Jan 13, 2016 at 6:25 PM, softwbc <so...@163.com> wrote:
>
>> I try the default configuration for ActiveMQ.
>> Now,I fount that the following two parameters could cause this problem:
>> useJmx="true" schedulerSupport="true"
>> When this configuration is removed,no warn has occurred. So far.
>>
>> but, Previously I tried to change to false.
>>
>> Thanks for your help.
>>
>>
>>
>> --
>> View this message in context:
>> http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4705974.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>
>
Re: Using Broker clusters, javax.management.InstanceAlreadyExistsException:xx
Posted by Tim Bain <tb...@alumni.duke.edu>.
I'd definitely expect that turning off JMX would eliminate the problem,
since the issue happens when creating the objects JMX uses. I'm skeptical
that scheduler support would cause this problem if JMX support is disabled,
and skeptical that turning it off would eliminate the problem if JMX is
enabled, so basically I expect that useJmx is the only setting you need to
change, not both of them.
However, running without JMX support makes it much harder to diagnose
issues in your broker if you experience them, so I'm not sure I'd choose to
turn off JMX support rather that just live with a noisy log file; log lines
that you know aren't a problem are easy to filter our or ignore, and I'd
rather have JMX available if something starts not working, but it's your
choice.
Either way, I'd plan to upgrade to 5.14.0 when it's released, at which
point you should definitely re-enable JMX support.
Tim
On Wed, Jan 13, 2016 at 6:25 PM, softwbc <so...@163.com> wrote:
> I try the default configuration for ActiveMQ.
> Now,I fount that the following two parameters could cause this problem:
> useJmx="true" schedulerSupport="true"
> When this configuration is removed,no warn has occurred. So far.
>
> but, Previously I tried to change to false.
>
> Thanks for your help.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4705974.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Using Broker clusters,
javax.management.InstanceAlreadyExistsException:xx
Posted by softwbc <so...@163.com>.
I try the default configuration for ActiveMQ.
Now,I fount that the following two parameters could cause this problem:
useJmx="true" schedulerSupport="true"
When this configuration is removed,no warn has occurred. So far.
but, Previously I tried to change to false.
Thanks for your help.
--
View this message in context: http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4705974.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Using Broker clusters, javax.management.InstanceAlreadyExistsException:xx
Posted by Tim Bain <tb...@alumni.duke.edu>.
It does look like your problem, and a patch has been submitted so you could
try it and see if it solves your problem.
On Jan 11, 2016 10:11 AM, "softwbc" <so...@163.com> wrote:
> Hi, I built a new environment without F5
> and the problem still exist.
>
> Here is a issues unresolved
> https://issues.apache.org/jira/browse/AMQ-6052
> <https://issues.apache.org/jira/browse/AMQ-6052>
>
> Is this my question
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4705739.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Using Broker clusters,
javax.management.InstanceAlreadyExistsException:xx
Posted by softwbc <so...@163.com>.
Hi, I built a new environment without F5
and the problem still exist.
Here is a issues unresolved
https://issues.apache.org/jira/browse/AMQ-6052
<https://issues.apache.org/jira/browse/AMQ-6052>
Is this my question
--
View this message in context: http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4705739.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Using Broker clusters, javax.management.InstanceAlreadyExistsException:xx
Posted by Tim Bain <tb...@alumni.duke.edu>.
Are you able to make a minimal test case that illustrates the problem
consistently and quickly? (Ideally this would be a single consumer on a
single destination; the simpler the better.) If you can make something
that someone else can easily run to demonstrate the problem, one of us
would be able to attach a debugger and try to figure out what's going on...
Tim
On Wed, Jul 8, 2015 at 1:18 AM, softwbc <so...@163.com> wrote:
> I found the problem came back. It is not caused by JMX configuration.
>
> And probably, after the restart will be good for a while, i found.
>
> I have no solution.
>
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4698779.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Using Broker clusters,
javax.management.InstanceAlreadyExistsException:xx
Posted by softwbc <so...@163.com>.
I found the problem came back. It is not caused by JMX configuration.
And probably, after the restart will be good for a while, i found.
I have no solution.
--
View this message in context: http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4698779.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Using Broker clusters, javax.management.InstanceAlreadyExistsException:xx
Posted by Tim Bain <tb...@alumni.duke.edu>.
I'm guessing here because I don't really know the relevant code, but maybe
when you don't set useJmx="true", it's creating two different JMX contexts
for your broker? I can't explain why that would be, but maybe someone else
here can.
However, another user appeared to have the same problem two years ago, but
never found an explanation:
http://activemq.2283324.n4.nabble.com/useJmx-false-two-brokers-getting-exception-due-to-jmx-td4671456.html
Either way, it sounds like you've got the system running and don't need any
more help with this. Am I right?
Tim
On Fri, Jul 3, 2015 at 2:48 AM, softwbc <so...@163.com> wrote:
> Thank you for your prompt
>
> I set the useJMX=true, the warning message disappears.
>
> and i dont know why...
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4698547.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Using Broker clusters,
javax.management.InstanceAlreadyExistsException:xx
Posted by softwbc <so...@163.com>.
Thank you for your prompt
I set the useJMX=true, the warning message disappears.
and i dont know why...
--
View this message in context: http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4698547.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Using Broker clusters, javax.management.InstanceAlreadyExistsException:xx
Posted by Tim Bain <tb...@alumni.duke.edu>.
Clearly your master brokers have "master" in the name; do your slaves have
"slave" in the name when viewed in JMX? That was the question I was asking.
Have you confirmed (via ps -ef or something similar) that no other
processes are running ActiveMQ on the host in question? And are you
running any clients that might be creating embedded brokers?
Have you tested what happens if you only start one master/slave pair? Is
that enough to make them unhappy, or does it require both pairs before you
see a problem?
Tim
On Jul 1, 2015 9:02 AM, "softwbc" <so...@163.com> wrote:
> sorry! I mean second parts.Here is my application structure.
> <
> http://activemq.2283324.n4.nabble.com/file/n4698434/%E6%B6%88%E6%81%AF%E5%B9%B3%E5%8F%B0%E6%9C%80%E7%BB%88%E7%BB%93%E6%9E%84ENG.jpg
> >
>
> And I confirmed that the configuration is in effect.
> <http://activemq.2283324.n4.nabble.com/file/n4698434/1.png>
> <http://activemq.2283324.n4.nabble.com/file/n4698434/2.png>
>
> Any other ideas?
>
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Using-Broker-clusters-javax-management-InstanceAlreadyExistsException-xx-tp4698127p4698434.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>