What do we gain by using the session scope?

So you decided one of the instances of your bean has to live in the HttpSession. And it needs to be wired as a dependency to other services. One example is a simple cache that sits in the session and is injected into services.

<bean id="cache" class="FooCache" scope="session">
    <aop:scoped-proxy/>
</bean>

<bean id="myService" class="FooService">
    <property name="cache" ref="cache"/>
</bean>

So here we have a FooCache injected into the FooService. Note the aop:scoped-proxy. We gained a lot by that. Spring takes care of storing the FooCache instance as an attribute in the HttpSession without me having to write a single line of code. And everything works fine across sessions even if the FooService is a singleton.

Now what did we lose?

We lost the flexibility to use the FooCache in non-web environments. So your unit tests and your batch environment cannot use the FooCache the way your services use them. Now you can very well say that we should go for a FooCacheNonWeb implementation for these cases. But having one such extension for each session-enabled class can become laborious and doesn’t sound ‘easy’ enough for a lazy developer.

Now, what can we do about it?

That’s exactly the point of this post. Why not have a session scope that would fallback to a singleton-like scope if it is not running in a web environment? Folks, welcome the star of the show, the NeverFailWebScope. The NeverFailWebScope will act as a proxy to the actual scope you want to use in production web environment. But it will fallback to it’s own map store if the environment is alien to the wrapped/proxied scope. Here’s a simple implementation

public class NeverFailWebScope implements Scope, ApplicationContextAware {

	private AbstractRequestAttributesScope proxiedScope;
	private ConcurrentHashMap objectMap = new ConcurrentHashMap();
	private boolean fallbackDisabled = false;
	private boolean executingInWebContext = false;
	private static final org.slf4j.Logger logger = org.slf4j.LoggerFactory
			.getLogger(NeverFailWebScope.class);

	public NeverFailWebScope(AbstractRequestAttributesScope proxied) {
		this.proxiedScope = proxied;
	}

	public Object get(String name, ObjectFactory factory) {
		if (fallbackDisabled || executingInWebContext) {
			logger.debug("Via proxied scope");
			return proxiedScope.get(name, factory);
		}
		else {
			logger.debug("Via fallback");
			return objectMap.putIfAbsent(name, factory.getObject());
		}
	}

	public String getConversationId() {
		if (fallbackDisabled || executingInWebContext) {
			return proxiedScope.getConversationId();
		}
		else {
			return null;
		}
	}

	public void registerDestructionCallback(String name, Runnable callback) {
		if (fallbackDisabled || executingInWebContext) {
			proxiedScope.registerDestructionCallback(name, callback);
		}
	}

	public Object remove(String name) {
		if (fallbackDisabled || executingInWebContext) {
			return proxiedScope.remove(name);
		}
		else {
			return objectMap.remove(name);
		}
	}

	public boolean isFallbackDisabled() {
		return fallbackDisabled;
	}

	public void setFallbackDisabled(boolean fallbackEnabled) {
		this.fallbackDisabled = fallbackEnabled;
	}

	public void setApplicationContext(ApplicationContext context)
			throws BeansException {
		executingInWebContext = context instanceof WebApplicationContext;
	}
}

A couple things to note

• NeverFailWebScope favors composition over inheritance. Any scope (session/request) can be wrapped. The inheritance approach would have been to extend Spring’s SessionScope.
• It also allows the NeverFailWebScope to “not fallback” by setting fallbackDisabled to true. You might want to set that to false in the production/web environment using a PropertyPlaceHolderConfigurer.
• It detects a web environment by checking if the context is a WebApplicationContext. This is not totally fail-proof. And there are other ways to do the same check.
• Note that this was built for the Spring 2.0 API. You would have to implement an additional method if you want to use a later version of Spring.

It ain’t curtains time yet. The scope has to be registered with Spring before it can be used. And that can be done as shown below (again in XML configuration)

<bean class="org.springframework.beans.factory.config.CustomScopeConfigurer">
	<property name="scopes">
		<map>
		<entry key="neverFailSession">
			<bean class="com.sabscape.NeverFailWebScope">
				<constructor-arg>
					<bean class="org.springframework.web.context.request.SessionScope"/>
				</constructor-arg>
				<property name="fallbackDisabled" value="false"/>
			</bean>
		</entry>
		</map>
	</property>
</bean>

And the FooCache configuration can now use the neverFailSession scope.

<bean id="cache" class="FooCache" scope="neverFailSession">
    <aop:scoped-proxy/>
</bean>

On analyzing the performance, it became apparent that in-memory formula processing was consuming a lot of time, around 3 seconds approximately per request. I confirmed that this was the bottleneck by replacing some heavily used formulas with hard-coded java code.

With the cause identified, I tried looking into JEval source to see if something obvious can be done towards improving performance. I couldn’t find much. The one option was to pre-parse the expression so that parsing is avoided at run-time. The other option was to disable nested functions, but then my formulas wouldn’t work.

That set the tone for the subsequent hunt for a better expression evaluator. Ended up at stackoverflow.com, as is typically the case these days, and evaluated Expr.

Unbelievably good performance. The source code is much simpler. And just like JEval, it doesn’t have additional dependencies. It might need some extra tweaks to support variables the way I want, but overall, the experience was much better.

Here’s some numbers that compares Jeval with Expr for some hypothetical but close to real-world expressions

Please note that these timings include the overhead of an AOP layer (that weaves only application classes).

Of course, Expr doesn’t boast of all the features like JEval, string & custom functions for example, but performance-wise it beats JEval for simple to moderately complex mathematical expressions. It makes us think again if doing things the most right way often leads to solutions that are both telling in complexity and performance. May be JEval could have had a simpler engine for parsing simpler expressions and a costlier engine for parsing full blown formulas with the user given the option of executing either of the two depending on his requirements.

The best solution IMO would be to use both JEval and Expr and let configuration decide which evaluator to use for each expression. This is what I did. I added a layer that abstracts out the differences in how we use these two frameworks. That way we get the best of both the worlds. Their expression languages are easy to learn and there is no burden in managing both at the same time.

Exception in thread "main" org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'XXXXXX' defined in class path resource [hibernate-dao-config.xml]:
Instantiation of bean failed; nested exception is java.lang.VerifyError:
(class: XXXXXXDAO,method: findBy_aroundBody9$advice signature: (LXXXXX;JJJLjava/lang/Boolean;
Lorg/aspectj/lang/JoinPoint; Lprofiling/JamonPerformanceInt`i7#-(

Caused by: java.lang.VerifyError: (class: XXXXDAO, method: findBy_aroundBody9$advice
signature: (LcomXXXXXXDAO;JJJLjava/lang/Boolean;Lorg/aspectj/lang/JoinPoint;
Lprofiling/JamonPerformanceInt`i7#-(

The problem would only occur in certain scenarios (methods with 2 primitive arguments, methods that accepted other objects whose methods were advised).

Without further ado let me say what fixed it for me. -Xnoinline. It’s one of the options exposed by the aspectj weaver. -Xnoinline appeared promising because i was using ‘Around’ advice and the error messages showed a weird signature for my advised methods. Tried with that and voila, the rough weather was all gone. Here’s the aop.xml where the -Xnoinline is passed to the LTW mechanism.

<aspectj>
    <weaver
        options="-showWeaveInfo
        -XmessageHandlerClass:org.springframework.aop.aspectj.AspectJWeaverMessageHandler -Xnoinline">
        <!-- only weave classes in our application-specific packages -->
        <include within="my.package..*"/>
    </weaver>
    <aspects>
        <aspect name="profiling.JamonPerformanceInterceptor"/>
    </aspects>
</aspectj>

There is not much literature around this on the net. I tried the following, but to no avail.

1. Ensure the aspectjrt.jar and aspectjweaver.jar are of the same version. In my case, they already were.
2. Ensure that the VM is the latest for that release. In my case, it already was
3. Ensure that the jars are not duplicated on the classpath with conflicting versions

The result was the same when i tried with the IBM JVM as well, though it was sugarcoated differently (stack shape inconsistent blah blah).

I am thinking the -Xnoinline will affect performance. But I wouldn’t mind that for the job at hand.

1. Just as with any merge, make sure your working copy has been switched to the branch you want to update. So in our case, the local working copy should be feature_branch101. You can read more on this in my previous Subversion merge post.
2. Make sure there are no outgoing (i.e., not checked in) changes in your local working copy.
3. Right-click your project in eclipse and choose Team -> Merge…
4. In the wonderfully misnamed ‘Merge input’ section choose ‘Merge a range of revisions’. Uncheck ‘Perform pre-merge best practices checks’. Here’s a capture to illustrate better
   
5. Click Next. In this screen we have to choose the merge source ‘from’ which we want to grab the changes to merge into our local working copy. This is feature_branch101 in our case. Here’s another capture
   
6. Make sure ‘Select revisions on next page’ is selected to allow hand-picking of the revisions we want
7. Click Next. In the ‘Select the revisions’ dialog, you can select the revisions you want.
   
8. Click Next. This takes you to the merge options. Just leave things the way they are. Click ‘Finish’.
9. You can check the SVN console for the progress of the merge. Here you should find the merge command and the list of changes happening. Something like below

merge -c 5064 -c 5073 -r 5086:5088  W:/
    --- Merging r5063 through r5064 into W:/
	...
	...
	Merge complete.
    ===== File Statistics: =====
    Merged: 1
    Added: 6
    Updated: 17

10. Subclipse will popup the merge statistics once the merge is complete. You can now synchronize your changes with the feature_branch100 in the svn repository. Right click your project, Team -> Synchronize

<bean class="com.oh.my.DingDongRepeater">
	<property name="enabled" value="#{!${dingDongDisabled}}"/>
</bean>

The #{!} negates the ${dingDongDisabled}. You might be curious why one needs to do this rather than renaming the property the other way around. Well, let’s just say that i get stubborn/adamant/picky every once in a while.

1. Make sure the working copy reflects the target of the merge. If you want to merge your feature branch to trunk (so that the trunk gets up-to-date with the feature), then the working copy (the current project in eclipse) should be trunk. If you are not in trunk, then switch your project’s working copy using context menu Team -> Switch… Ideally changes should be checked in before switching.
2. Wait for switch to complete. The SVN console will display the list of files that get added, deleted or updated by subversion client to make the working copy reflect the new version it is switching to.
3. Now do Team -> Merge
4. In there choose ‘Merge two different trees’ as the merge input (what’s with these cryptic names). This allows a fully configurable merge.
5. Uncheck ‘Perform pre-merge best practice checks’. But make sure there are no unchecked changes in the working copy.
   
6. In the next window specify the ‘from’ and ‘to’ urls for the merge. This I have found to be quite confusing the first time. It helps to take an analogy. If one wants to go from Bangalore to Chicago then the  ‘from’ location is Bangalore and the ‘to’ location is Chicago. Now let’s translate that to repository versions. If we want the working copy to go ‘from’ trunk ‘to’ the feature branch state, then the ‘from’ has to be the trunk and the  ‘to’ has to be the feature branch URL. If instead we are merging a branch101 back to branch100, then the working copy should be branch100,  the  ‘from’ should be branch100 and the ‘to’ should be branch101. Phew! That’s a lot of words.
7. In the same window, specify the revisions. Typically one would choose HEAD revision for both the ‘from’ and the ‘to’.
   
8. Click Next. In the conflict handling options window, just leave it to the defaults. If it doesn’t work with defaults, then enable ‘Ignore ancestry’ and ‘Allow unversioned obstructions’.
9. Click Finish. That’s it. Easy peasy lemon squeezy. SVN console will log all that the SVN client does to update the working copy to the ‘to’ location and revision.
10. Once its all done, the working copy can now be synchronized with the repository to merge/check-in the changes to the trunk. Trunk of course, stays safe, till you do this.

For ex, you might have a list of PropertyStatus instances that you want to display in the grid’s cell

public var statuses:ArrayList =
	new ArrayList([
	{name: "sold", desc: "Sold out"},
	{name: "avail", desc: "Still available"}
]);

Though the ComboBox supports this case, the ComboBoxGridItemEditor does not. So the following wouldn’t work.

<s:DataGrid dataProvider="{props}" width="400" editable="true">
	<s:columns>
		<s:ArrayList>
			<s:GridColumn dataField="name" editable="false"/>
			<s:GridColumn dataField="status">
				<s:itemEditor>
					<fx:Component>
						<s:ComboBoxGridItemEditor dataProvider="{outerDocument.statuses}"/>
					</fx:Component>
				</s:itemEditor>
			</s:GridColumn>
		</s:ArrayList>
	</s:columns>
</s:DataGrid>

So we would see something like below

But it’s pretty easy to enable this by extending the ComboBoxGridItemEditor as shown below. All we need to do is add a labelFunction attribute and pass it onto the ComboBox.

<?xml version="1.0" encoding="utf-8"?>
<s:ComboBoxGridItemEditor xmlns:fx="http://ns.adobe.com/mxml/2009"
						  xmlns:s="library://ns.adobe.com/flex/spark"
						  xmlns:mx="library://ns.adobe.com/flex/mx" width="400" height="300">
	<fx:Declarations>
		<!-- Place non-visual elements (e.g., services, value objects) here -->
	</fx:Declarations>
	<fx:Script>
		<![CDATA[
			import spark.components.gridClasses.GridItemRenderer;
			private var _labelFunction:Function;

			public function get labelFunction():Function {
				return _labelFunction;
			}

			public function set labelFunction(func:Function):void {
				_labelFunction = func;
				comboBox.labelFunction = _labelFunction;
			}
		]]>
	</fx:Script>
</s:ComboBoxGridItemEditor>

So now the following would work

<local:CustomizableComboBoxGridItemEditor
        dataProvider="{outerDocument.statuses}" labelFunction="{outerDocument.statusLabel}"/>

So we would see something like

But wait, is that enough? Good catch. Note that the DataGrid uses two UI component instances for each cell. One for the display mode and one for the edit mode. We fixed the edit mode. But the display mode would still display gibberish.

The simplest way to fix this is to use GridColumn.labelFunction.

	public function columnStatusLabel(data:Object, col:GridColumn):String {
				return data[col.dataField].desc;
			}
		]]>
	</fx:Script>
	<s:DataGrid dataProvider="{props}" width="400" editable="true">
		....
			<s:GridColumn dataField="status" labelFunction="{columnStatusLabel}">

So the grid would now look like

All these labelFunctions floating around would do us no good when we want to reuse them across dialogs. The best way in this case would be to have a PropertyStatus class and define the label functions there. This makes the functions available wherever we want them and leaves them in a place logical enough to find. Something like

public class PropertyStatus {
	public var name:String;
	public var desc: String;

        public static function statusLabel(status:Object):String {
		return status.desc;
	}
	public static function columnStatusLabel(data:Object, col:GridColumn):String {
		return data[col.dataField].desc;
	}
}

What do we want?

Lets assume a requirement which dictates that we shouldn’t be processing more than 2 messages simultaneously on the server. That’s easy, we just need to set the concurrency attribute to 2. But to complicate things, lets assume we have another message listener container defined in the same context, wired to listen on a different queue. And we want to process a maximum of 2 messages simultaneously, across these 2 queues.

Also, if one of the queues is empty, we would naturally want 2 messages of the other queue be processed simultaneously so that the app doesn’t just sit twiddling its thumb.

How do we do it

The solution is quite simple. The MessageListenerContainer abstraction supports injection of a custom task executor. And if we inject the same task executor instance to the 2 MLC instances, we end up controlling both the MLCs from one common threadpool. Now whatever throttling we apply on the task executor will in turn dictate how the MLCs process messages.

So the configuration now looks like

<jms:listener-container connection-factory="connectionFactory"
	destination-resolver="serverDestinationResolver" message-converter="messageConverter"
	concurrency="3-3" task-executor="executor">
	<jms:listener id="someName" destination="trRequestQueue"
		ref="remoteExecutionEndPoint" method="receive" response-destination="trStatusQueue"/>
</jms:listener-container>

<task:executor id="executor" pool-size="2" queue-capacity="2"
	rejection-policy="ABORT"/>

All we did was define a task executor and inject it to the MLC(s). And voila, only 2 messages will be processed simultaneously from now. This works with the concurrency attribute, for ex, if the pool size is increased to 6, then both MLCs will start processing 3 messages a a time, because their concurrency attribute limits each of them to 3. And all we did was type one extra line of configuration XML !

Here’s the basic message listener container configuration to start with.

        <jms:listener-container connection-factory="connectionFactory"
		destination-resolver="serverDestinationResolver" message-converter="messageConverter">
		<jms:listener id="someName" destination="trRequestQueue"
			ref="remoteExecutionEndPoint" method="runAround"
                        response-destination="trStatusQueue"/>
	</jms:listener-container>

Check out the appendix at the end for the surrounding configuration like serverDestinationResolver, messageConverter etc. I wouldn’t have needed the messageConverter if i had a symmetric interface that accepted a String and returned a String for ex.
The server-side listener can be a simple POJO. The implementation sleeps for 3 seconds to simulate work being done.

public interface Park {
	public String runAround(TextMessage message);
}
public class ParkImpl implements Park {
...
	public String runAround(TextMessage message) {
		try {
			logger.info("Received message: " + message.getText());
			Thread.sleep(3000);
			return "processed: " + message.getText();
		}
		catch (Exception e) {
			return "processed: junk";
		}
	}
}

Our client will use the Spring JMSTemplate to send 3 Hello messages as shown below

public void interact() throws Exception {
		for (int i = 1; i <= 3; i++) {
			final int iVal = i;
			clientTemplate.send(sendDestination,
				new MessageCreator() {
					public Message createMessage(
						Session session) throws JMSException {
					return session.
						createTextMessage("Hello " + iVal);
				}
			});
			logger.info("Sent");
		}
		for (int i = 1; i <= 3; i++) {
			TextMessage message = (TextMessage)
				clientTemplate.receive(replyDestination);
		}
	}

In our simple application, we are embedding both the client and the server in the same vm.

Let’s see the default behavior in the console on running this

23:07:10.062 [main] INFO  c.s.rexec.RemoteExecutionClient - Sent
23:07:10.093 [main] INFO  c.s.rexec.RemoteExecutionClient - Sent
23:07:10.171 [main] INFO  c.s.rexec.RemoteExecutionClient - Sent
23:07:10.031 [someName-1] INFO  c.s.r.RemoteExecutionEndPointImpl
	- Received message: Hello 1
23:07:13.078 [someName-1] INFO  c.s.r.RemoteExecutionEndPointImpl
	- Received message: Hello 2
23:07:16.109 [someName-1] INFO  c.s.r.RemoteExecutionEndPointImpl
	- Received message: Hello 3

We see that one message is processed every 3 seconds. This is the default settings at work. A JMS Session processes only one message a time so that the consumer need not be multi-threaded.

Now how do we scale? Simple. The message listener container has a concurrency attribute. Lets set it to 3 so that all 3 of our messages get processed simultaneously.

        <jms:listener-container connection-factory="connectionFactory"
		destination-resolver="serverDestinationResolver" message-converter="messageConverter">
		<jms:listener id="someName" destination="trRequestQueue"
			ref="remoteExecutionEndPoint" method="runAround"
                        response-destination="trStatusQueue" concurrency="3"/>
	</jms:listener-container>

Now lets observe the behavior on running the program

07:42:23.246 [main] INFO  c.n.rexec.RemoteExecutionClient - Sent
07:42:23.277 [main] INFO  c.n.rexec.RemoteExecutionClient - Sent
07:42:23.308 [main] INFO  c.n.rexec.RemoteExecutionClient - Sent
07:42:23.199 [someName-1] INFO  c.n.r.RemoteExecutionEndPointImpl
	- Received message: Hello 1
07:42:23.277 [someName-2] INFO  c.n.r.RemoteExecutionEndPointImpl
	- Received message: Hello 3
07:42:26.386 [someName-1] INFO  c.n.r.RemoteExecutionEndPointImpl
	- Received message: Hello 2

What we are seeing instead is that 2 messages are processed simultaneously, not 3 as we had configured. The third message is picked up at 07:42:26 while the first 2 at 07:42:23. So what’s going on?

The MessageListenerContainer documentation does not mention anything specially about the concurrency attribute. But the DefaultMessageListenerContainer API tells us that there are 2 attributes related to concurrency, concurrentConsumers and maxConcurrentConsumers. So it could be that the default max is 2. So lets try upping the max. Here’s our new configuration.

        <jms:listener-container connection-factory="connectionFactory"
		destination-resolver="serverDestinationResolver" message-converter="messageConverter">
		<jms:listener id="someName" destination="trRequestQueue"
			ref="remoteExecutionEndPoint" method="runAround"
                        response-destination="trStatusQueue" concurrency="3-3"/>
	</jms:listener-container>

The only change (yet again) is the concurrency which is now set to 3-3. This is typically the way we set a range in Spring configuration. Lets observe the behavior again

07:51:19.933 [main] INFO  c.n.rexec.RemoteExecutionClient - Sent
07:51:19.980 [main] INFO  c.n.rexec.RemoteExecutionClient - Sent
07:51:19.996 [main] INFO  c.n.rexec.RemoteExecutionClient - Sent
07:51:19.886 [someName-1] INFO  c.n.r.RemoteExecutionEndPointImpl
	- Received message: Hello 1
07:51:19.949 [someName-3] INFO  c.n.r.RemoteExecutionEndPointImpl
	- Received message: Hello 2
07:51:19.980 [someName-2] INFO  c.n.r.RemoteExecutionEndPointImpl
	- Received message: Hello 3

Good, that works, all 3 messages have been handled simultaneously. And its working because the MessageListenerContainer is creating extra sessions as per the concurrency attribute. As mentioned in the documentation, these attributes are modifiable at runtime via JMX, thereby allowing us to scale even more dynamically, staying truly J2EE container independent all the while.

This is already quite a long post, so i will discuss the throttling part in the next post.

Appendix A: ActiveMQ configuration

Active MQ configuration to configure the broker, queues. One queue to submit requests to the server and another to get response from server.

        <amq:broker useJmx="false" id="amqServer">
		<amq:transportConnectors>
			<amq:transportConnector uri="${mqBrokerURL}"/>
		</amq:transportConnectors>
	</amq:broker>

	<!-- Predefined queues, we don't need dynamic queues -->
	<amq:queue id="trRequestQueue" name="sendDestination"
		physicalName="queue.trRequest"/>
	<amq:queue id="trStatusQueue" physicalName="queue.trResponse"/>

	<!-- J2EE ConnectionFactory -->
	<amq:connectionFactory id="targetConnectionFactory" brokerURL="vm://localhost"/>

	<!-- Cache the connection -->
	<bean id="connectionFactory" class="org.springframework.jms.connection.SingleConnectionFactory">
		<property name="targetConnectionFactory" ref="targetConnectionFactory"/>
		<property name="reconnectOnException" value="true"/>
	</bean>

Appendix B: Listener configuration

	<jms:listener-container connection-factory="connectionFactory"
		destination-resolver="serverDestinationResolver" message-converter="messageConverter">
		<jms:listener id="someName" destination="trRequestQueue"
			ref="remoteExecutionEndPoint" method="receive" response-destination="trStatusQueue"/>
	</jms:listener-container>
	<bean id="remoteExecutionEndPoint"
		class="com.sabscape.rexec.ParkImpl"/>
	<bean id="serverDestinationResolver"
		class="org.springframework.jms.support.destination.BeanFactoryDestinationResolver"/>
	<bean id="messageConverter"
		class="com.sabscape.rexec.PassthroughMessageConverter"/>

• Scale message consumption easily. We can specify the concurrency level we want and it will create additional sessions (because JMS, by design, disallows concurrent use of a Session) as required. This is modifiable at run-time as well.
• Allows our POJO message handlers a.k.a listeners to be JMS agnostic (actually integration channel agnostic). So i can have a business-driven method name like runAroundThePark() instead of something that means nothing like onMessage. Of course its not a big deal to dispatch to a business centric method from onMessage, still, why should another level of redirection be forced upon us just because our logic is being invoked through a JMS channel
• Our POJO message handling class can send a response message, again while being JMS agnostic
• Easily throttle across queues (and/or selector-based-listeners)
• The scenario is something like this. Assume that you are handling messages that are requesting some jobs to be run and these jobs involve some heavy processing. And you have been asked to ensure that not more than 4 jobs are run at a time
• And there are multiple queues that accept a variety of jobs
• Now you want to make sure that (across the whole broker) not more than 4 jobs are running at a time

How we can scale and how we can throttle across the application’s queues is going to be the content of the next post.