You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2010/07/30 10:22:57 UTC
Re: RE : Usage of server managed thread of Websphere
Hi
Since you extend existing Camel code, then some logic of Camels is
still being in use.
Camel uses a naming pattern to apply thread names.
You can set a thread name which implies WebSphere for example
See the setThreadNamePattern method
On Fri, Jul 30, 2010 at 10:18 AM, chaillon <st...@solucom.fr> wrote:
>
> Yes, it should be the good manner to do it...
> I have tried this option with no success
> My source code is linked to this message
>
> I extends the DefaultExecutorStrategy and reference it via Spring XML.
> I have replaced all the calls to ExecutorServiceHelper from the DefaultExecutorStrategy by calls to my own helper (with the same implementation that is works in my first message - ie by replacing the original helper implementation)
>
> Traces in my code show me that the code that not success to lookup JNDI resources is executed in a thread named "Camel Thread...". So this thread is not comming from my implementation! Yet, logs prove that my implementation of the strategy is really used by Camel
>
> So I must have missed something in my implementation...
> But what?
>
> ________________________________
>
> De: Claus Ibsen-2 [via Camel] [mailto:ml-node+2258446-1848593534-114176@n5.nabble.com]
> Date: ven. 30/07/2010 02:58
> À: CHAILLON Stéphane
> Objet : Re: Usage of server managed thread of Websphere
>
>
> Hi
>
> See this wiki page
> http://camel.apache.org/threading-model.html
>
> You can implement a custom ExecutorServiceStrategy which hook into WebSphere.
>
>
>
> On Thu, Jul 29, 2010 at 5:01 PM, chaillon <http://camel.465427.n5.nabble.com/file/n2256731/src.zip <http://camel.465427.n5.nabble.com/file/n2256731/src.zip?by-user=t> src.zip
>> --
>> View this message in context: http://camel.465427.n5.nabble.com/Usage-of-server-managed-thread-of-Websphere-tp2256731p2256731.html <http://camel.465427.n5.nabble.com/Usage-of-server-managed-thread-of-Websphere-tp2256731p2256731.html?by-user=t>
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com <http://fusesource.com/?by-user=t>
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
>
> ________________________________
>
> View message @ http://camel.465427.n5.nabble.com/Usage-of-server-managed-thread-of-Websphere-tp2256731p2258446.html
> To unsubscribe from Usage of server managed thread of Websphere, click here < (link removed) > .
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Usage-of-server-managed-thread-of-Websphere-tp2256731p2259282.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: RE : Usage of server managed thread of Websphere
Posted by "Preben.Asmussen" <pr...@dr.dk>.
Hi David
I started som work on integrating Camel with jee workmanagers some time ago.
I never got to finish it because I ran into truble on Weblogic being able to
release the workers/workmanagers again. And now we are running just fine
without using any workmanagers on WLS :-)
If you can use it feel free to take a look at the source
https://github.com/pax95/camel-commonj
/preben
--
View this message in context: http://camel.465427.n5.nabble.com/Re-RE-Usage-of-server-managed-thread-of-Websphere-tp2259287p5505751.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: RE : Usage of server managed thread of Websphere
Posted by David Karlsen <da...@gmail.com>.
Does it use the taskexecutor abstraction?
If so you can use:
http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/scheduling/commonj/WorkManagerTaskExecutor.html
2012/2/21 achalam <aa...@gmail.com>:
> Hi,
> We are using websphere7.1 with Springframework3.0.4 and camel2.9.
> Since, the threading model changed, and it says that, we should just
> implement ThreadPoolFactory.
> I am not sure, how this WebSphereThreadPoolFactory (if implemented) would
> have to be injected to DefaultExecutorServiceManager.
> Any clarification on this is greatly appreciated.
>
> Thanks,
> Adi
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Re-RE-Usage-of-server-managed-thread-of-Websphere-tp2259287p5501345.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
Re: RE : Usage of server managed thread of Websphere
Posted by achalam <aa...@gmail.com>.
Hi,
We are using websphere7.1 with Springframework3.0.4 and camel2.9.
Since, the threading model changed, and it says that, we should just
implement ThreadPoolFactory.
I am not sure, how this WebSphereThreadPoolFactory (if implemented) would
have to be injected to DefaultExecutorServiceManager.
Any clarification on this is greatly appreciated.
Thanks,
Adi
--
View this message in context: http://camel.465427.n5.nabble.com/Re-RE-Usage-of-server-managed-thread-of-Websphere-tp2259287p5501345.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: RE : Usage of server managed thread of Websphere
Posted by David Karlsen <da...@gmail.com>.
Also note that the same scheme exists for spring OOTB where the TaskExecutor
is the abstraction on top of all of these.
2011/5/6 Claus Ibsen <cl...@gmail.com>
> On Fri, May 6, 2011 at 4:54 PM, Tarun Ramakrishna <ta...@elankath.com>
> wrote:
> > Actually this could have been simply solved if camel core and all
> > camel components delegated their threading needs to a
> > java.util.concurrent.ThreadFactory. Then one could have centralized
> > thread management. Unfortunately even if Camel is well behaved many of
> > its components are not and even associated units like ActiveMQ don't
> > seem to allow you to customize thread creation. But maybe there is a
> > way to do this that I am not aware of.
> >
>
> Came sure does that. There is a SPI for that
>
> http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/spi/ExecutorServiceStrategy.html
>
> It allows to plugin 3rd party providers. So we can provide a CommonJ
> bridge for that out of the box.
>
> But yes for 3rd party components they need to leverage that SPI as
> well. Some of the components do that already.
> But there may be some that uses their own abstraction. For example Jetty
> etc.
>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> CamelOne 2011: http://fusesource.com/camelone2011/
> Twitter: davsclaus
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
--
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
Re: RE : Usage of server managed thread of Websphere
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, May 6, 2011 at 4:54 PM, Tarun Ramakrishna <ta...@elankath.com> wrote:
> Actually this could have been simply solved if camel core and all
> camel components delegated their threading needs to a
> java.util.concurrent.ThreadFactory. Then one could have centralized
> thread management. Unfortunately even if Camel is well behaved many of
> its components are not and even associated units like ActiveMQ don't
> seem to allow you to customize thread creation. But maybe there is a
> way to do this that I am not aware of.
>
Came sure does that. There is a SPI for that
http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/spi/ExecutorServiceStrategy.html
It allows to plugin 3rd party providers. So we can provide a CommonJ
bridge for that out of the box.
But yes for 3rd party components they need to leverage that SPI as
well. Some of the components do that already.
But there may be some that uses their own abstraction. For example Jetty etc.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: RE : Usage of server managed thread of Websphere
Posted by Tarun Ramakrishna <ta...@elankath.com>.
Actually this could have been simply solved if camel core and all
camel components delegated their threading needs to a
java.util.concurrent.ThreadFactory. Then one could have centralized
thread management. Unfortunately even if Camel is well behaved many of
its components are not and even associated units like ActiveMQ don't
seem to allow you to customize thread creation. But maybe there is a
way to do this that I am not aware of.
Re: RE : Usage of server managed thread of Websphere
Posted by preben <pr...@dr.dk>.
This feature seems really useful when running Camel in jee container like
Weblogic or WAS and would be a nice candidate for a Camel component.
I have started generalizing it to be jee container agnostic using CommonJ
which is a shared standard between Weblogic and WAS.
What do you think ?
Should I create a ticket ?
/Preben
--
View this message in context: http://camel.465427.n5.nabble.com/Re-RE-Usage-of-server-managed-thread-of-Websphere-tp2259287p4375711.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: RE : Usage of server managed thread of Websphere
Posted by chaillon <st...@solucom.fr>.
There is our final implementation (see attached document).
Definition of the strategy into the Spring context:
<bean id="wasExecutorServiceStrategy"
class="threadmanager.WasExecutorServiceStrategy">
<property name="executor">
<bean class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:comp/env/wm/wasWorkManager" />
<property name="resourceRef" value="true" />
</bean>
</property>
</bean>
The local JNDI resource "wm/wasWorkManager" should be declared into the
web.xml file
The object from JNDI should be a commonj.work.WorkManager provided by
Websphere
Our executor service strategy extends the DefaultExecutorServiceStrategy and
replace each call to the Camel ExecutorServiceHelper by calls to our own
WasExecutorServiceHelper.
This helper generate Camel threads wrapped into a custom thread delegating
its work to the Websphere WorkManager.
In conclusion, all the Camel threads are delegated to the Websphere
WorkManager and so it is possible to acceed to the JNDI context from the
threads!
http://camel.465427.n5.nabble.com/file/n2261530/src.zip src.zip
--
View this message in context: http://camel.465427.n5.nabble.com/Re-RE-Usage-of-server-managed-thread-of-Websphere-tp2259287p2261530.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: RE : Usage of server managed thread of Websphere
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Aug 2, 2010 at 10:05 AM, chaillon <st...@solucom.fr> wrote:
>
> OK... so there was a mistake into my implementation of the strategy...
>
> Now, my executorStrategyService works great with websphere
>
That's fantastic. Thanks for reporting back and confirming you can
have Camel leverage threads managed by WebSphere.
> Thanks
> --
> View this message in context: http://camel.465427.n5.nabble.com/Re-RE-Usage-of-server-managed-thread-of-Websphere-tp2259287p2261485.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: RE : Usage of server managed thread of Websphere
Posted by chaillon <st...@solucom.fr>.
OK... so there was a mistake into my implementation of the strategy...
Now, my executorStrategyService works great with websphere
Thanks
--
View this message in context: http://camel.465427.n5.nabble.com/Re-RE-Usage-of-server-managed-thread-of-Websphere-tp2259287p2261485.html
Sent from the Camel - Users mailing list archive at Nabble.com.