Re: RE : Usage of server managed thread of Websphere

[Claus Ibsen-2]

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 <[hidden email]> 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:[hidden email]]
> 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

[chaillon]

OK... so there was a mistake into my implementation of the strategy...

Now, my executorStrategyService works great with websphere

Thanks

[Claus Ibsen-2]

On Mon, Aug 2, 2010 at 10:05 AM, chaillon <[hidden email]> 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

[chaillon]

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!


src.zip

[Preben.Asmussen]

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

 
 

[Tarun Ramakrishna-2]

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.

[Claus Ibsen-2]

On Fri, May 6, 2011 at 4:54 PM, Tarun Ramakrishna <[hidden email]> 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: [hidden email]
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]

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 <[hidden email]>

> On Fri, May 6, 2011 at 4:54 PM, Tarun Ramakrishna <[hidden email]>
> 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: [hidden email]
> 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

[achalam]

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

[David J. M. Karlsen]

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 <[hidden email]>:

> 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

[Preben.Asmussen]

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