Synchronization using application object gets IllegalStateException


I use a separate thread to update a table in a tab sheet, and every once in a while my application gets this:

17:34:45 INFO  [WebappClassLoader]
 Illegal access: this web application instance has been stopped already.  Could not load$1.  The eventual following stack trace 
is caused by an error thrown for debugging purposes as well as to attempt 
to terminate the thread which caused the illegal access, and has no functional impact.
	at org.apache.catalina.loader.WebappClassLoader.loadClass(
	at org.apache.catalina.loader.WebappClassLoader.loadClass(
	at java.lang.ClassLoader.loadClassInternal(
	at com.itmill.toolkit.ui.AbstractSelect.getContainerProperty(
	at com.itmill.toolkit.ui.Table.refreshRenderedCells(
	at com.itmill.toolkit.ui.Table.valueChange(
	at com.itmill.toolkit.ui.Table.addItem(
	at (here is my class at the line that calls addItem() in the table)

I read on the forum where I could use the application instance to synchronize, so my code looks like this:

            Integer id = new Integer(job.getJobId());
            synchronized (getApplication())
                if (table.containsId(id))
                table.addItem(new Object[] { name, runTime, jobData }, id);

Should I do anything else to stop this exception? The application appears to work ok, except that it misses that one update (every once in a while).


Im confused by the

web application instance has been stopped already
[/quote] message from the web container - it appears that your application stops (or context was undeployed) for some reason, so this could be even not an toolkit sync problem but another one.

Could you check that nothing accidently kills the server/thread ?

Thanks, I don’t understand that message either.

I am converting to itmill from JSPs , and they have worked (and continue to work) for long periods on the same server, so I know that the server itself is not being killed.

Regarding a possibly killed thread: I’m using Tomcat (embedded in JBoss) as my server, and I’ve not written anything specifically to kill threads. Are you suggesting that there’s possibly a timeout (or something) on the server side that’s causing a thread containing the itmill application/context to die?

Actually, webapp context should terminate on any timeout and work until it manually undeployed, server stopped or some fatal error occurs in a web container or app.

When this exception happens, is the web context still alive or it restarts , e.g. if you refresh a page/itmill application - is the current session with all it states alive or a new session is opened ?

I just tried it, and it appears that the context is alive, I did a page refresh and confirmed that several state variables (member variables in my subclass of Application) retained their values without having to reload from the back-end database.

Since the timing seems rather random, I don’t really think it’s a timeout. Sometimes it happens within a minute or two of starting my server and connecting the client, sometimes it takes hours.

First a little disclaimer: Never seen this before, so I’m basically just thinking out loud here… :slight_smile:

Your thread tries to load a class that is available in a web application that is not anymore available (has been restarted/undeployed)… or at least that what the update threads class loader thinks.

The class probably is available, but it has been loaded by a WebappClassLoader that has been already invalidated (undeployment/redeployment).

This can happen, when if the thread lives longer than a web application is deployed, but you say that the application is alive all the time.

So, I’m thinking of the situation where the update thread uses
WebAppClassLoader than the itmill application uses. Are there several itmill-toolkit-x.x.x.jar files available to the web server (in different web app contexts or in common lib) that may have been loaded concurrently? Is the thread started within the same webapp context than the itmill application?

Anyway, I don’t think that there is much that you can do in a itmill application to avoid this. If you have multiple classloaders present you might try to use Thread.setContextClassLoader to force some specific classloader to be used.