Spring Integration + WorkManager Thread Pools

[casand]

Hello all,

I'm very new to Spring Integration - and I like it a lot so far, but I have one minor issue that I haven't found a solution for.

I was wondering if it is possible at this time to have Spring Integration utilize a pre-existing thread pool (for channel endpoints) configured with WorkManager instead of creating it's own?

For example:


<integration:message-bus />

<integration:channel id="emailMsgChannel" datatype="java.util.Map" />

<integration:endpoint input-channel="emailMsgChannel"-->
handler-ref="emailMsgHandler" handler-method="sendEmail" />

<bean id="emailMsgHandler"
class="email.EmailMessageHandler"
scope="singleton">
<property name="mailSender" ref="mailSender" />
</bean>



I would want this EmailMessageHandler to use a thread from a WorkManager thread pool instead of one created by the Spring container.

If it's possible - how would I go about doing that?

Thanks for any advice.

[tony_k]

bump...?

i work at a large company and our infrastructure folks frown upon (read: disallow) non-container managed threads...

it would also be a non-trivial endeavor to pursue running integration processes out of container.

this is one of our current sticking points associated with running any of the integration products mule, camel, spring integration.

i'm guessing my company is not alone in this position, so it amazes me that the providers of these otherwise fine integration products have somehow missed this seemingly obvious point.

[Mark Fisher]

The Spring core's task execution support includes the ability to delegate to a WorkManager. We are working on a way to expose this functionality and to make it easily configurable for endpoints and other threads within Spring Integration. Ideally it would be configurable on a global level, since in most cases that someone wants to use WorkManager for managing threads, the behavior would be needed globally. One issue to resolve is how to integrate this with scheduling. In other words, dispatchers are currently driven by any implementation of the util.concurrent ScheduledExecutorService which supports initial delay and period.

Regards,
Mark

[patb23@gmail.com]

Hi,
I am using WorkManagerTaskExecutor in my Spring-Batch application and is configured as shown below.

<bean id="workmanager" class="org.springframework.scheduling.commonj.WorkManager TaskExecutor">
<property name="workManagerName" value="java:comp/env/wm/myWorkManager"/>
</bean>

Have configured the IBM WorkManager to have a min connection of 10 and max of 50 but when i run the Batch Job, it is only creating 5 connections. I checked the Websphere console and see only 5 threads. I do not know whether I should look at the Websphere 6.1 end or at the Spring API level.

Should I be changing any other properties for me to have more threads?

[Holger Hoffstätte]

i work at a large company and our infrastructure folks frown upon (read: disallow) non-container managed threads...


Your infrastructure folks need to come to accept the reality of the limitations of container-managed threads. The WorkManager spec is woefully inadequate by itself and not available for non-container apps.



this is one of our current sticking points associated with running any of the integration products mule, camel, spring integration.


Mule has allowed using externally managed container thread pools forever, but as I said above the limitations for actually managing the thread behaviour makes them useless for anything but the most trivial use cases. This includes precise timing, rejection, queueing just to name a few.



i'm guessing my company is not alone in this position, so it amazes me that the providers of these otherwise fine integration products have somehow missed this seemingly obvious point.


Nobody missed this point. The fact of the matter is that many libraries create their own threads and are completely ignorant of any container whatsoever. Which, of course, puts the whole idea of all-singing, all-dancing containers into a particular light.

Holger

[Nol]

Hi Patb23,

We are running into similar problems, increasing the number of available threads in the IBM Workmanager has no visible effect.

We´re using Spring, Camel and Websphere.
Within our applicationContext we have:

<bean id="taskExecutor" class="org.springframework.scheduling.commonj.WorkManager TaskExecutor">
<property name="workManagerName" value="java:comp/env/WorkManagerAVB" />
<property name="resourceRef" value="true" />
</bean>

Our threadPool named "Default" should contain between 5 and 40 threads. However when debugging the application only 10 threads of name "WorkManager.DefaultWorkManager..." show up.

When we start our application with a reduced number of routes everything works fine.
However when we increase the number of routes above a certain threshold the server refuses to start up.

Did you find a solution to your problem that you can share here?

Thanks,
Nol