We are using task:executor in our spring integration application. We need to monitor this threadpool via mbean browser. So far we have good control over all spring integration channels , message handlers etc and those are showing in our mbean browser but we like to see task executor threadpool also be visible so we can see how many threads are in pool, how many being used etc
Is it possible to export them as mbean? if so how it can be done?
<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
<property name="beans">
<map>
<entry key="exec:name=exec" value-ref="exec" />
</map>
</property>
</bean>
<task:executor id="exec" />
Related
In our application we are using SingleConnectionFactory with DefaultMessageListenerContainer consuming from IBM MQ server, performance wise the app is doing pretty good, however on MQ end our application is opening too many new connections randomly. Here is the current config we have.
Try with this instead of caching or single:
<bean id="connectionFactory" class="org.springframework.jms.connection.DelegatingConnectionFactory">
<property name="targetConnectionFactory" ref="primaryRawInputConnectionFactory" />
<property name="shouldStopConnections" value="true"/>
</bean>
I am migrating Spring Batch Partition Jobs with XML configuration to Spring batch 4.x. I am trying to take advantage to an improvement in the MessageChannelPartitionHandler where it looks for completion of remote steps with both a reply channel and a datasource polling.
When I use this configuration:
<int:channel id="partitioned.jms.requests">
<int:dispatcher task-executor="springbatch.partitioned.jms.taskExecutor"/>
</int:channel>
<int:channel id="partitioned.jms.reply" />
<bean id="partitioned.jms.handler" class="org.springframework.batch.integration.partition.MessageChannelPartitionHandler">
<property name="messagingOperations">
<bean class="org.springframework.integration.core.MessagingTemplate">
<property name="defaultChannel" ref="partitioned.jms.requests"/>
</bean>
</property>
<property name="stepName" value="process.partitioned.step"/>
<property name="gridSize" value="${process.step.partitioned.gridSize}"/>
<property name="dataSource" ref="springbatch.repositoryDataSource" />
<property name="pollInterval" value="${springbatch.partition.verification.interval}"/>
</bean>
The step completes but I see an error in the logs.
no output-channel or replyChannel header available
I looked at the class and see I can add a replyChannel property to the MessageChannelPartitionHandler class. If I add the following:
<property name="replyChannel" ref="claim.acp.process.partitioned.jms.reply"/>
I get error back that a pollable channel is needed.
How do I create a pollable channel (assuming from the same JMS queue)?
You need to show the rest of your configuration.
If you are using DB polling for the results, set the output-channel on the jms outbound gateway to "nullChannel" and the replies received over JMS will be discarded.
Or, use an outbound channel adapter (instead of a gateway) (and an inbound-channel-adapter on the slaves). That avoids the replies being returned altogether.
You have to set pollRepositoryForResults to true.
To answer your specific question
<int:channel id="replies>
<int:queue />
<int:channel>
I have configured queueconnection factory in the WebSphere admin console and using jndi lookup to use it. MQ Queue Connection Factories in WebSphere Application Server has settings. Connection pool Max size to 30 and session pool Max size to 20
These are than used in several jms:message-driven-channel-adapter or jms channels or jms:inbound-channel-adapter as part of various spring integration workflows that I have in my application.
Over a period we see that the connection count on MQ channel keeps increasing upto maximum allowed (about 1800).Once we bounce the server the count comes back to normal below 50.
Is there any setting missing ?
How can I be sure if the JMS session pools are being closed/released ?
Any help is appreciated
<jee:jndi-lookup id="queueConnectionFactory" jndi-name="$env{Queue.ConnectionFactory}" />
<si-jms:message-driven-channel-adapter
id="messageDrivenAdapter" channel="routingChannel"
container="messageListenerContainer" />
<bean id="messageListenerContainer"
class="org.springframework.jms.listener.DefaultMessageListenerContainer">
<property name="connectionFactory" ref="queueConnectionFactory" />
<property name="destination" ref="inQueue" />
<property name="transactionManager" ref="txManager" />
<property name="taskExecutor" ref="MQExecutor" />
</bean>
<si-jms:channel id="regChannel" queue="regQueue" connection-factory="queueConnectionFactory" transaction-manager="txManager" task-executor="regtaskExecutor" />
In my old days when we use Spring Integration on WebSphere we had a bean like this:
<bean id="connectionFactory" class="org.springframework.jms.connection.DelegatingConnectionFactory">
<property name="targetConnectionFactory">
<jee:jndi-lookup jndi-name="someConnectionFactory"/>
</property>
<property name="shouldStopConnections" value="true"/>
</bean>
Let's see if that can help you!
I am trying to find out how the apache camel handles the default thread pool with concurrent consumers. Checked the stackoverflow, camel documentation and apache camel in action book but not much information on what is the optimal values being used with the ThreadPool (uses Spring's ThreadPoolTaskExecutor with optimal values - cached threadpool-like)
Here is the configuration I used for my application
from("jms:queue:test??concurrentConsumers=1&maxConcurrentConsumers=10&maxMessagesPerTask=-1&defaultTaskExecutorType=ThreadPool &preserveMessageQos=true").inOnly("direct:deliver-normal-route-1");
If there any connectivity issues in MQ, I see the thread ID's like 500K+ numbers. Is the cached threadpool create a runaway threads if there is an exception?
To avoid this scenario, I implemented my custom thread pool like,
from("jms:queue:test??concurrentConsumers=1&maxConcurrentConsumers=10&maxMessagesPerTask=-1&taskExecutor=#myTaskExecutor&preserveMessageQos=true").inOnly("direct:deliver-normal-route-1");
<bean id="myTaskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
<property name="threadNamePrefix" value="myThread" />
<property name="corePoolSize" value="10" />
<property name="maxPoolSize" value="20" />
<property name="queueCapacity" value="100" />
<property name="keepAliveSeconds" value="60"></property>
<property name="awaitTerminationSeconds" value="5" />
<property name="waitForTasksToCompleteOnShutdown"
value="true" />
</bean>
With this custom threadpool configuration I don't see any runaway threads. I tested with stopping the MQ channel for few minutes, same threads been resumed and reused unlike the Default threadpool of Camel.
I am using spring integration to read message from TIBCO EMS queue using jms-int:message-driven-channel-adapter. I am facing issue : After certain interval of time say 5-10 hours(occurs at random interval), jms channel adapter stops picking the message even if there is message in the jms queue
Below is my spring integration context :
<bean id="jmsConnectionFactory" class="org.springframework.jms.connection.CachingConnectionFactory">
<property name="targetConnectionFactory" ref="connectionFactory"/>
<property name="sessionCacheSize" value="${sessionCacheSize}"/>
<property name="cacheProducers" value="${cacheProducers}"/>
<property name="cacheConsumers" value="${cacheConsumers}"/>
</bean>
<bean id="jmsQueue" class="${queueClassName}">
<constructor-arg value="${jmsQueue}" />
</bean>
<int-jms:message-driven-channel-adapter
id="jmsMessageDrivenAdapter" connection-factory="jmsConnectionFactory" channel="jmsListenerChannel" destination="jmsQueue"
error-channel="integrationErrorChannel" max-concurrent-consumers="${maxConcurrentConsumers}" auto-startup="${jms.autostart}"/>
I have feature to start/stop jmsMessageDrivenAdapter, and the adapter can be started/stopped anytime while it is picking messages but at this point, start/stop feature does not works too. Please suggest !
This seems to be a duplicate of Spring Integration jms message driven channel adapter fails (but a different contributor, so I'll answer again here)...
This is generally caused by some component in the downstream flow hanging the container thread uninterruptibly (e.g. reading from a socket with no timeout, where no data arrives).
To diagnose, take a thread dump (e.g. jstack ) when the hang occurs, to find out what the listener container threads are doing.