You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2009/10/14 10:02:36 UTC
Startup mechanism for servicemix 4
FWIW, I've slightly changed the startup mechanism for smx4 so that all
the bundles are resolved as completely as possible (i.e. not having
optional imports that could be solved, but aren't due to bundles start
up order).
To avoid a bad interaction between fileinstall and the features
service around the deployment of the activemq-broker.xml, i've moved
the broker config into the etc/ folder and use a feature with the
spring url handler to deploy this one. This way, fileinstall does not
try to deploy the activemq-broker.xml, but it's taken in charge by the
boot features mechanism. The problem was that fileinstall was trying
to start the generated activemq-broker bundle, thus forcing the
resolution of bundles before it was actually necessary and was causing
problems with unresolved optional imports. The downside is that you
can't change the etc/activemq-broker.xml and expect it to be
redeployed automatically. Instead, you'll have to osgi:refresh the
bunde after any change, but I don't think it's a big drawback.
This change also seem to have had a good impact on startup time, but
I'll dig a bit more into that, as my cpu consumption is not very high,
so I think we can still improve things here.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Startup mechanism for servicemix 4
Posted by Eoghan Glynn <eo...@gmail.com>.
Well it was just a the NotCompliantMBeanException being wrapped in a
UndeclaredThrowableException, I was about to commit a fix but I just notice
ffang got in there first.
/Eoghan
2009/10/20 Guillaume Nodet <gn...@gmail.com>
> I think the problem comes from the fact that the spring jmx assembler
> not being set up.
>
> On Tue, Oct 20, 2009 at 16:00, Eoghan Glynn <eo...@gmail.com> wrote:
> >> On a side note, I'm seing a lot of those exceptions in the log:
> >> Caused by: javax.management. NotCompliantMBeanException:
> >> ...
> >> Not sure exactly where they come from, but we need to fix those.
> >
> > I'm on this NotCompliantMBeanException issue, should have a fix shortly
> > (tracked via SMX4NMR-165).
> >
> > Cheers,
> > Eoghan
> >
> >
> > 2009/10/14 Guillaume Nodet <gn...@gmail.com>
> >
> >> On a side note, I'm seing a lot of those exceptions in the log:
> >>
> >> Caused by: javax.management.NotCompliantMBeanException: MBean class
> >> org.apache.servicemix.nmr.management.ManagedEndpoint does not
> >> implement DynamicMBean, neither follows the Standard MBean conventions
> >> (javax.management.NotCompliantMBeanException: Class
> >> org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX
> >> compliant Standard MBean) nor the MXBean conventions
> >> (javax.management.NotCompliantMBeanException:
> >> org.apache.servicemix.nmr.management.ManagedEndpoint: Class
> >> org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX
> >> compliant MXBean)
> >>
> >> Not sure exactly where they come from, but we need to fix those.
> >>
> >> On Wed, Oct 14, 2009 at 10:02, Guillaume Nodet <gn...@gmail.com>
> wrote:
> >> > FWIW, I've slightly changed the startup mechanism for smx4 so that all
> >> > the bundles are resolved as completely as possible (i.e. not having
> >> > optional imports that could be solved, but aren't due to bundles start
> >> > up order).
> >> >
> >> > To avoid a bad interaction between fileinstall and the features
> >> > service around the deployment of the activemq-broker.xml, i've moved
> >> > the broker config into the etc/ folder and use a feature with the
> >> > spring url handler to deploy this one. This way, fileinstall does not
> >> > try to deploy the activemq-broker.xml, but it's taken in charge by the
> >> > boot features mechanism. The problem was that fileinstall was trying
> >> > to start the generated activemq-broker bundle, thus forcing the
> >> > resolution of bundles before it was actually necessary and was causing
> >> > problems with unresolved optional imports. The downside is that you
> >> > can't change the etc/activemq-broker.xml and expect it to be
> >> > redeployed automatically. Instead, you'll have to osgi:refresh the
> >> > bunde after any change, but I don't think it's a big drawback.
> >> > This change also seem to have had a good impact on startup time, but
> >> > I'll dig a bit more into that, as my cpu consumption is not very high,
> >> > so I think we can still improve things here.
> >> >
> >> > --
> >> > Cheers,
> >> > Guillaume Nodet
> >> > ------------------------
> >> > Blog: http://gnodet.blogspot.com/
> >> > ------------------------
> >> > Open Source SOA
> >> > http://fusesource.com
> >> >
> >>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >>
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Startup mechanism for servicemix 4
Posted by Eoghan Glynn <eo...@gmail.com>.
No worries Freeman, I'll just go ahead and commit the unit test part of my
fix.
Cheers,
Eoghan
2009/10/20 Freeman Fang <fr...@gmail.com>
> Hi Guillaume,
>
> I just created SMXNMR-166 and commited a fix.
> The fact is that for proxy reference(mbeanServer in this case), we should
> catch UndeclaredThrowableException and then use getCause() to determine if
> the actual exception is NotCompliantMBeanException or not. But still not
> clear why we didn't see this problem before.
>
>
> Eoghan, sorry, not realize you are working on it and already create a jira
> for it, please review my commit with SMXNMR-166, if I'm wrong, just correct
> me.
>
> Thanks
>
> Freeman
>
> On 2009-10-20, at 下午10:01, Guillaume Nodet wrote:
>
> I think the problem comes from the fact that the spring jmx assembler
>> not being set up.
>>
>> On Tue, Oct 20, 2009 at 16:00, Eoghan Glynn <eo...@gmail.com> wrote:
>>
>>> On a side note, I'm seing a lot of those exceptions in the log:
>>>> Caused by: javax.management. NotCompliantMBeanException:
>>>> ...
>>>> Not sure exactly where they come from, but we need to fix those.
>>>>
>>>
>>> I'm on this NotCompliantMBeanException issue, should have a fix shortly
>>> (tracked via SMX4NMR-165).
>>>
>>> Cheers,
>>> Eoghan
>>>
>>>
>>> 2009/10/14 Guillaume Nodet <gn...@gmail.com>
>>>
>>> On a side note, I'm seing a lot of those exceptions in the log:
>>>>
>>>> Caused by: javax.management.NotCompliantMBeanException: MBean class
>>>> org.apache.servicemix.nmr.management.ManagedEndpoint does not
>>>> implement DynamicMBean, neither follows the Standard MBean conventions
>>>> (javax.management.NotCompliantMBeanException: Class
>>>> org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX
>>>> compliant Standard MBean) nor the MXBean conventions
>>>> (javax.management.NotCompliantMBeanException:
>>>> org.apache.servicemix.nmr.management.ManagedEndpoint: Class
>>>> org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX
>>>> compliant MXBean)
>>>>
>>>> Not sure exactly where they come from, but we need to fix those.
>>>>
>>>> On Wed, Oct 14, 2009 at 10:02, Guillaume Nodet <gn...@gmail.com>
>>>> wrote:
>>>>
>>>>> FWIW, I've slightly changed the startup mechanism for smx4 so that all
>>>>> the bundles are resolved as completely as possible (i.e. not having
>>>>> optional imports that could be solved, but aren't due to bundles start
>>>>> up order).
>>>>>
>>>>> To avoid a bad interaction between fileinstall and the features
>>>>> service around the deployment of the activemq-broker.xml, i've moved
>>>>> the broker config into the etc/ folder and use a feature with the
>>>>> spring url handler to deploy this one. This way, fileinstall does not
>>>>> try to deploy the activemq-broker.xml, but it's taken in charge by the
>>>>> boot features mechanism. The problem was that fileinstall was trying
>>>>> to start the generated activemq-broker bundle, thus forcing the
>>>>> resolution of bundles before it was actually necessary and was causing
>>>>> problems with unresolved optional imports. The downside is that you
>>>>> can't change the etc/activemq-broker.xml and expect it to be
>>>>> redeployed automatically. Instead, you'll have to osgi:refresh the
>>>>> bunde after any change, but I don't think it's a big drawback.
>>>>> This change also seem to have had a good impact on startup time, but
>>>>> I'll dig a bit more into that, as my cpu consumption is not very high,
>>>>> so I think we can still improve things here.
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>>
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
> --
> Freeman Fang
>
> ------------------------
> Open Source SOA: http://fusesource.com
>
>
Re: Startup mechanism for servicemix 4
Posted by Freeman Fang <fr...@gmail.com>.
Hi Guillaume,
I just created SMXNMR-166 and commited a fix.
The fact is that for proxy reference(mbeanServer in this case), we
should catch UndeclaredThrowableException and then use getCause() to
determine if the actual exception is NotCompliantMBeanException or
not. But still not clear why we didn't see this problem before.
Eoghan, sorry, not realize you are working on it and already create a
jira for it, please review my commit with SMXNMR-166, if I'm wrong,
just correct me.
Thanks
Freeman
On 2009-10-20, at 下午10:01, Guillaume Nodet wrote:
> I think the problem comes from the fact that the spring jmx assembler
> not being set up.
>
> On Tue, Oct 20, 2009 at 16:00, Eoghan Glynn <eo...@gmail.com> wrote:
>>> On a side note, I'm seing a lot of those exceptions in the log:
>>> Caused by: javax.management. NotCompliantMBeanException:
>>> ...
>>> Not sure exactly where they come from, but we need to fix those.
>>
>> I'm on this NotCompliantMBeanException issue, should have a fix
>> shortly
>> (tracked via SMX4NMR-165).
>>
>> Cheers,
>> Eoghan
>>
>>
>> 2009/10/14 Guillaume Nodet <gn...@gmail.com>
>>
>>> On a side note, I'm seing a lot of those exceptions in the log:
>>>
>>> Caused by: javax.management.NotCompliantMBeanException: MBean class
>>> org.apache.servicemix.nmr.management.ManagedEndpoint does not
>>> implement DynamicMBean, neither follows the Standard MBean
>>> conventions
>>> (javax.management.NotCompliantMBeanException: Class
>>> org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX
>>> compliant Standard MBean) nor the MXBean conventions
>>> (javax.management.NotCompliantMBeanException:
>>> org.apache.servicemix.nmr.management.ManagedEndpoint: Class
>>> org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX
>>> compliant MXBean)
>>>
>>> Not sure exactly where they come from, but we need to fix those.
>>>
>>> On Wed, Oct 14, 2009 at 10:02, Guillaume Nodet <gn...@gmail.com>
>>> wrote:
>>>> FWIW, I've slightly changed the startup mechanism for smx4 so
>>>> that all
>>>> the bundles are resolved as completely as possible (i.e. not having
>>>> optional imports that could be solved, but aren't due to bundles
>>>> start
>>>> up order).
>>>>
>>>> To avoid a bad interaction between fileinstall and the features
>>>> service around the deployment of the activemq-broker.xml, i've
>>>> moved
>>>> the broker config into the etc/ folder and use a feature with the
>>>> spring url handler to deploy this one. This way, fileinstall
>>>> does not
>>>> try to deploy the activemq-broker.xml, but it's taken in charge
>>>> by the
>>>> boot features mechanism. The problem was that fileinstall was
>>>> trying
>>>> to start the generated activemq-broker bundle, thus forcing the
>>>> resolution of bundles before it was actually necessary and was
>>>> causing
>>>> problems with unresolved optional imports. The downside is that
>>>> you
>>>> can't change the etc/activemq-broker.xml and expect it to be
>>>> redeployed automatically. Instead, you'll have to osgi:refresh the
>>>> bunde after any change, but I don't think it's a big drawback.
>>>> This change also seem to have had a good impact on startup time,
>>>> but
>>>> I'll dig a bit more into that, as my cpu consumption is not very
>>>> high,
>>>> so I think we can still improve things here.
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
--
Freeman Fang
------------------------
Open Source SOA: http://fusesource.com
Re: Startup mechanism for servicemix 4
Posted by Guillaume Nodet <gn...@gmail.com>.
I think the problem comes from the fact that the spring jmx assembler
not being set up.
On Tue, Oct 20, 2009 at 16:00, Eoghan Glynn <eo...@gmail.com> wrote:
>> On a side note, I'm seing a lot of those exceptions in the log:
>> Caused by: javax.management. NotCompliantMBeanException:
>> ...
>> Not sure exactly where they come from, but we need to fix those.
>
> I'm on this NotCompliantMBeanException issue, should have a fix shortly
> (tracked via SMX4NMR-165).
>
> Cheers,
> Eoghan
>
>
> 2009/10/14 Guillaume Nodet <gn...@gmail.com>
>
>> On a side note, I'm seing a lot of those exceptions in the log:
>>
>> Caused by: javax.management.NotCompliantMBeanException: MBean class
>> org.apache.servicemix.nmr.management.ManagedEndpoint does not
>> implement DynamicMBean, neither follows the Standard MBean conventions
>> (javax.management.NotCompliantMBeanException: Class
>> org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX
>> compliant Standard MBean) nor the MXBean conventions
>> (javax.management.NotCompliantMBeanException:
>> org.apache.servicemix.nmr.management.ManagedEndpoint: Class
>> org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX
>> compliant MXBean)
>>
>> Not sure exactly where they come from, but we need to fix those.
>>
>> On Wed, Oct 14, 2009 at 10:02, Guillaume Nodet <gn...@gmail.com> wrote:
>> > FWIW, I've slightly changed the startup mechanism for smx4 so that all
>> > the bundles are resolved as completely as possible (i.e. not having
>> > optional imports that could be solved, but aren't due to bundles start
>> > up order).
>> >
>> > To avoid a bad interaction between fileinstall and the features
>> > service around the deployment of the activemq-broker.xml, i've moved
>> > the broker config into the etc/ folder and use a feature with the
>> > spring url handler to deploy this one. This way, fileinstall does not
>> > try to deploy the activemq-broker.xml, but it's taken in charge by the
>> > boot features mechanism. The problem was that fileinstall was trying
>> > to start the generated activemq-broker bundle, thus forcing the
>> > resolution of bundles before it was actually necessary and was causing
>> > problems with unresolved optional imports. The downside is that you
>> > can't change the etc/activemq-broker.xml and expect it to be
>> > redeployed automatically. Instead, you'll have to osgi:refresh the
>> > bunde after any change, but I don't think it's a big drawback.
>> > This change also seem to have had a good impact on startup time, but
>> > I'll dig a bit more into that, as my cpu consumption is not very high,
>> > so I think we can still improve things here.
>> >
>> > --
>> > Cheers,
>> > Guillaume Nodet
>> > ------------------------
>> > Blog: http://gnodet.blogspot.com/
>> > ------------------------
>> > Open Source SOA
>> > http://fusesource.com
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Startup mechanism for servicemix 4
Posted by Eoghan Glynn <eo...@gmail.com>.
> On a side note, I'm seing a lot of those exceptions in the log:
> Caused by: javax.management. NotCompliantMBeanException:
> ...
> Not sure exactly where they come from, but we need to fix those.
I'm on this NotCompliantMBeanException issue, should have a fix shortly
(tracked via SMX4NMR-165).
Cheers,
Eoghan
2009/10/14 Guillaume Nodet <gn...@gmail.com>
> On a side note, I'm seing a lot of those exceptions in the log:
>
> Caused by: javax.management.NotCompliantMBeanException: MBean class
> org.apache.servicemix.nmr.management.ManagedEndpoint does not
> implement DynamicMBean, neither follows the Standard MBean conventions
> (javax.management.NotCompliantMBeanException: Class
> org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX
> compliant Standard MBean) nor the MXBean conventions
> (javax.management.NotCompliantMBeanException:
> org.apache.servicemix.nmr.management.ManagedEndpoint: Class
> org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX
> compliant MXBean)
>
> Not sure exactly where they come from, but we need to fix those.
>
> On Wed, Oct 14, 2009 at 10:02, Guillaume Nodet <gn...@gmail.com> wrote:
> > FWIW, I've slightly changed the startup mechanism for smx4 so that all
> > the bundles are resolved as completely as possible (i.e. not having
> > optional imports that could be solved, but aren't due to bundles start
> > up order).
> >
> > To avoid a bad interaction between fileinstall and the features
> > service around the deployment of the activemq-broker.xml, i've moved
> > the broker config into the etc/ folder and use a feature with the
> > spring url handler to deploy this one. This way, fileinstall does not
> > try to deploy the activemq-broker.xml, but it's taken in charge by the
> > boot features mechanism. The problem was that fileinstall was trying
> > to start the generated activemq-broker bundle, thus forcing the
> > resolution of bundles before it was actually necessary and was causing
> > problems with unresolved optional imports. The downside is that you
> > can't change the etc/activemq-broker.xml and expect it to be
> > redeployed automatically. Instead, you'll have to osgi:refresh the
> > bunde after any change, but I don't think it's a big drawback.
> > This change also seem to have had a good impact on startup time, but
> > I'll dig a bit more into that, as my cpu consumption is not very high,
> > so I think we can still improve things here.
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Startup mechanism for servicemix 4
Posted by Guillaume Nodet <gn...@gmail.com>.
On a side note, I'm seing a lot of those exceptions in the log:
Caused by: javax.management.NotCompliantMBeanException: MBean class
org.apache.servicemix.nmr.management.ManagedEndpoint does not
implement DynamicMBean, neither follows the Standard MBean conventions
(javax.management.NotCompliantMBeanException: Class
org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX
compliant Standard MBean) nor the MXBean conventions
(javax.management.NotCompliantMBeanException:
org.apache.servicemix.nmr.management.ManagedEndpoint: Class
org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX
compliant MXBean)
Not sure exactly where they come from, but we need to fix those.
On Wed, Oct 14, 2009 at 10:02, Guillaume Nodet <gn...@gmail.com> wrote:
> FWIW, I've slightly changed the startup mechanism for smx4 so that all
> the bundles are resolved as completely as possible (i.e. not having
> optional imports that could be solved, but aren't due to bundles start
> up order).
>
> To avoid a bad interaction between fileinstall and the features
> service around the deployment of the activemq-broker.xml, i've moved
> the broker config into the etc/ folder and use a feature with the
> spring url handler to deploy this one. This way, fileinstall does not
> try to deploy the activemq-broker.xml, but it's taken in charge by the
> boot features mechanism. The problem was that fileinstall was trying
> to start the generated activemq-broker bundle, thus forcing the
> resolution of bundles before it was actually necessary and was causing
> problems with unresolved optional imports. The downside is that you
> can't change the etc/activemq-broker.xml and expect it to be
> redeployed automatically. Instead, you'll have to osgi:refresh the
> bunde after any change, but I don't think it's a big drawback.
> This change also seem to have had a good impact on startup time, but
> I'll dig a bit more into that, as my cpu consumption is not very high,
> so I think we can still improve things here.
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com