Spring Integration, WebSphere Application Server and the TopicConnectionFactory in a Cluster (Active-Active)

Spring Integration, WebSphere Application Server and the TopicConnectionFactory in a Cluster (Active-Active)

so, something i recently came across with when setting up a TopicConnectionFactory on WebSphere is the difference between Cluster level and Node level.  when setting up a QueueConnectionFactory, you can set once at the Cluster level, and all the Nodes replicate the setup and it all works fine.  This is not the case with the TopicConnectionFactory.  

The ClientID concept in a TopicConnectionFactory (that is, the unique ID for the subscription side of things) doesn't play nice across the Cluster if set at the Cluster level.  Essentially only one of the Nodes in the Cluster becomes the subscriber and receives messages where the other Nodes throw warnings that the subscription is in use.  (which is true)

To get around this, set the TopicConnectionFactory at the Node level, giving each one a unique ClientID.  All the rest of the settings can stay the same (JMS name, topic string, etc.).  A suggested format for the ClientID is [application].node.[number] to help you easily track and clean up subscriptions.

Remember, this is for an Active-Active cluster where each Node in it is Active and semi-autonomous (can handle their own processing independently).

WebSphere MQ and DefaultMessageListenerContainer

WebSphere MQ and DefaultMessageListenerContainer

one of the joys of life is to work with the WebSphere environment.  one of the catches is working with the fantastic Spring Integration and the [insert your favorite expletive] WebSphere App Server.

here's a recent problem that i keep forgetting about; DefaultMessageListenerContainer doesn't play nice in the common WebSphere setup.  

so, the thing to remember is to set the following on your DefaultMessageListenerContainer;

- sessionTransacted = false

- cacheLevelName = CACHE_NONE

and you're good

WebSphere, WAR and Spring JNDI

WebSphere, WAR and Spring JNDI

one trick i've discovered with WebSphere and Spring JNDI; to access any of the resources via Spring JNDI (including via the namespace configuration) the resources must first be bound in the web.xml.

another WebSphere "feature"...

WebApplicationInitializer and WebSphere 8

WebApplicationInitializer and WebSphere 8

so, it would appear that WebSphere 8 supports Servlet 3.0 in it's web.xml-less form, but... it doesn't want to play nice with Spring's WebApplicationInitializer.

when using the new AbstractDispatcherServletInitializer (an abstract of WebApplicationInitializer) it doesn't get triggered and start-up.

bit of nuisance that, but lets see if i can fix it...

WebSphere - Oracle - URL Error when testing from the WAS Console

WebSphere - Oracle - URL Error when testing from the WAS Console

this is just a reminder, when playing around with DataSources on WebSphere console, restart the node agent.  For some reason it needs to be bumped to fully pick up the changes

Spring Integration, Content-Length and WebSphere

Spring Integration, Content-Length and WebSphere

one little annoying thing i discovered the other day was that WebSphere (either app server or the http server) truncates the outbound response to the content-length value.  so, if you're content-length value is less than your content, you'll get a truncated body content.  nice...

this becomes a little bit of a problem when using Spring Integration 2.1.x out of the box.  if you're using the http-inbound-gateway, and you don't set which request headers to map, it will map all of them, including content-length.  This header then stays on the message (unless manipulated later) and is passed out, with the value set by the original request.  

the fix for this is straight-forward, set the mapped-request-headers value.  that way, only the specific header names will be set.  otherwise, you can enrich the headers on the way out, but that becomes a little more tricky when specifying the content length.

Hibernate 4 and WebSphere / JTA

Hibernate 4 and WebSphere / JTA

when looking through to debug some code recently i came across this...

package org.hibernate.service.jta.platform.internal;

public class WebSphereExtendedJtaPlatform extends AbstractJtaPlatform {

 ...

@Override
@SuppressWarnings( {"UnnecessaryBoxing"})
public Object getTransactionIdentifier(Transaction transaction) {

// WebSphere, however, is not a sane JEE/JTA container...

return Integer.valueOf( transaction.hashCode() );

}


 ...
}

brilliant!

WebSphere Gotcha - Streaming in WAS 8

WebSphere Gotcha - Streaming in WAS 8

here's a little gotcha in WebSphere 8; if you're using Spring MVC and you decide to serve non-jsp content from behind the WEB-INF directory (e.g. a javascript file), the ViewResolver must return it as a jsp page, otherwise WAS will block it.

In tomcat or other servlet container it will work, but in WebSphere, I can't get it to.

My workaround

create a controller that will stream it back in the HttpServletResponse object

WebSphere Classloader

one of the more frustrating aspects of working with WebSphere is when something works on a simple servlet container - it doesn't necessarily on WebSphere.

although the app is the same, it's not exactly the same under the covers.  one common issue is loading classes and loading either old, conflicted or other problems.  a very simple solution to this is to make your applications classes take precedence by switching the WebSphere classloading order. this is done in the following way

- go to the WebSphere console

- find your application and go into it's management screen

- select "Class Loading and update detection" (as of WAS 8)

- change the order of loading by select "Classes loaded with local class loader (parent last)"

Spring Integration, WebSphere App Server and WebSphere MQ

Problem

a strange behavior can occur when using WebSphere AppServer, WebSphere MQ and Spring Integration.  additional headers you add via Spring Integration header enrichment can 'fail' to appear once it's gone over the JMS wire via MQ.  this doesn't occur when using WebSphere MQ directly, only from the WebSphere container.  

Solution

so, the solution appears to be in the queue configuration in WebSphere AppServer, the default setting means that RFH2 Headers are not appended to the message.  though i'm not 100% on why this works, but when setting it to true, Spring Integration headers now work.

to find this in WebSphere V8 - go to the following

Resources > JMS > Queues > [your queue] > Advanced Properties

and check the box next to 

"Append RFH version 2 headers to messages sent to this destination"

it works - not exactly sure how...