I’ve been continuing to debug the issues with the JRuby web-enabled console into our Emissary P2P Workflow System. I’ve spent an embarrassingly long time debugging this and trying to figure out what is going wrong. Finally I started just printing out object ids for things so see what I might have more than one instance of.

The issue is that sometimes the ruby context is being duplicated. So we get this type of behavior:

=> i=5
5
=> i=6
6
=> i
6
=> i
5

Now it I have finally figured out that all of this takes place with one instance of emissary.scripting.RubyConsole (my object that adapts into Jruby and sets up theglobals I want the user to have access to), one instance of org.jruby.javasupport.bsf.JRubyEngine that gets set up through the BSFManager code, one instance of org.jruby.Ruby naturally since there is one private instance of it inside JRubyEngine.

Once I started looking at the code in org.jruby.Ruby and seeing ThreadLocal and ThreadContext type of things, a little light bulb went off somewhere in the North East corner of south west North Dakota. So I changed all of my log4j output formatters to add the %t directive which is the thread name. I am serving up access to the JRuby console over an AJAX enabled web-page using my own high-performance MVC code run by Jetty. As soon as the thread name comes out, here is what we are getting:

31 Dec 14:27:23 DEBUG JettyListenerPool-10 – – eval(’i=5′) => 5 [java.lang.Long]
31 Dec 14:27:45 DEBUG JettyListenerPool-11 – – eval(’i=6′) => 6 [java.lang.Long]
31 Dec 14:27:56 DEBUG JettyListenerPool-11 – – eval(’i') => 6 [java.lang.Long]
31 Dec 14:27:57 DEBUG JettyListenerPool-10 – – eval(’i') => 5 [java.lang.Long]

The highlighted item is the thread name. The order is not important. The number of different values I can get assigned to a variable named “i” is not important either. It all depends on how busy the Jetty server is and how many threads it decides to use in answering the HTTP AJAX requests coming in. As many threads as there are is how many different values for “i” that can be stored and retrieved.

Something is amiss in thread-local land.

I’m finding this code a little hard to follow. I’ve read several of Charles’s posts from 2006 on the performance considerations and looking up the context. I am continuing to hunt for the underlying reason for the several contexts and what actual object is being created on each thread. Without a fix for this I really cannot see how the JRuby console idea through BSF can be adapted to the web server environment.

Update: Here is a comment from ThreadService that looks interesting:
// Must be called from main thread (it is currently, but this bothers me)
mainThread = Thread.currentThread();

Hmm. I guess that bother’s me too. Since the first time I call it, the call is coming from any one of my Jetty listener threads, and there is nothing special about it. I can’t see any other way around this at the moment. But it’s comforting to know it might bother someone besides me.