Announcement Announcement Module
Collapse
No announcement yet.
stopping the message bus Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • stopping the message bus

    we are using spring integration in our project were we connect the channels with Jms message queues on weblogic after lookup through jndi.
    we have a request and response simple channel configured which connects to one request and one response channel using jms-target and jms-source respectively.
    hereforth is something similar to the xml code that we use.
    Code:
    <message-bus/>
    <annotation-driven/>
    <beans:bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
    		<beans:property name="environment">
    			<beans:props>
    				<beans:prop key="java.naming.factory.initial">
    					weblogic.jndi.WLInitialContextFactory
    				</beans:prop>
    				<beans:prop key="java.naming.provider.url">
    					t3://localhost:7001
    				</beans:prop>
    			</beans:props>
    		</beans:property>
    </beans:bean>
    <beans:bean id="connectionFactory"	class="org.springframework.jndi.JndiObjectFactoryBean">
    		<beans:property name="jndiTemplate">
    			<beans:ref bean="jndiTemplate" />
    		</beans:property>
    		<beans:property name="jndiName">
    			<beans:value>jank.jms.QueueConnectionFactory</beans:value>
    		</beans:property>
    </beans:bean>
    <beans:bean id="internalJobRequestQueue" class="org.springframework.jndi.JndiObjectFactoryBean">
    		<beans:property name="jndiTemplate">
    			<beans:ref bean="jndiTemplate" />
    		</beans:property>
    		<beans:property name="jndiName">
    			<beans:value>jank.jms.queue.request<beans:value>
    		</beans:property>
    	</beans:bean>
    <beans:bean id="internalJobResponseQueue" class="org.springframework.jndi.JndiObjectFactoryBean">
    		<beans:property name="jndiTemplate">
    			<beans:ref bean="jndiTemplate" />
    		</beans:property>
    		<beans:property name="jndiName">
    			<beans:value>jank.jms.queue.response<beans:value>
    		</beans:property>
    	</beans:bean>
    	<jms-target id="request" connection-factory="connectionFactory" destination="internalJobRequestQueue" channel="externalJobRequestChannel"/>
    	<jms-source id="response" message-converter="internalMessageConverter" connection-factory="connectionFactory" destination="internalJobResponseQueue" channel="externalJobResponseChannel"/>
    but once the weblogic server or the jndi provider is unavailable the channels try to connect to the queues repeatedly and i have an out of memory error.
    is there any way i can tell the channel the no of retries and stop the message bus when it reaches the maximum no of unsuccessful attempts.
    I am using spring integration m2

  • #2
    The best way to handle this type of situation is probably with an interceptor (For example, Spring Integration provides a ChannelInterceptor). As-is however, that interceptor does not allow catching of exceptions. It does allow you to check the boolean result of a send call (or to see a null Message on receive), but it does not provide an interception method "around" the invocation (although that can easily be achieved with AOP).

    If possible, I would recommend upgrading (M6 should be available later today). You will at least get more (and easier) configuration options for the poller and the interceptors. By configuring a polling interval, max-messages-per-poll, etc. you should probably be able to avoid the OOM even without interceptors.

    In the short term, we will be refactoring the ChannelInterceptor into separate SourceInterceptor and TargetInterceptor interfaces. One of the primary features planned is to support a basic RetryInterceptor (with a retryInterval and rejectionLimit). Other interceptors, such as a threshold-based Exception-counting interceptor should be easy to implement there as well. If you need access to the MessageBus from within an interceptor, it can implement MessageBusAware.

    If you do upgrade, please post back any issues - whether the same or different - and we can then use your feedback to consider the interceptor-based approach.

    Regards,
    Mark

    Comment

    Working...
    X