[ebagdonas]

Using:
MyEclipse – Version: 5.1.0 GA, Build id: 20061111-5.1.0-GA
Java – 1.4.2_13
Jboss 4.0.4 : using tomcat, jndi – tomcat is pointed to the exploded web application (part of the developer environment)
Build environment – MyEclipse (standard builder) builds class files to classes directory of exploded war directory

Problem

1) If a change is made to a class that is not being debugged the change is not picked up – for example adding a new line – the class is compiled, its timestamp is updated in the classes directory; however jboss has frequent cpu usage spikes and occasionally runs out of memory. (Note that the memory settings were updated as presented in the forums. tx)

2) If the change is made to a class that is being debugged the change is picked up and works fine.
* – note that the class would not be one that would reuire an application restart – eg a simple action handler.

The use case support desired is – modify code. save / compile, reload page and see the results without using debugging.

Thoughts / suggestions.

[Riyad Kalla]

It sounds like MyEclipse is doing it part of the equation correctly, the only part that you are missing (changing unused classes) is when JBoss doesn’t reload the new class correctly.

There are actually 3 pieces to this puzzle:

1) Hot swap, this is a debugger/VM level interaction that occurs with the class you are debugging. If the shape of the class doesn’t change, this can occur according to the spec.

2) If #1 fails, you need to make sure your server is setup to reload changes. Most app servers, like Tomcat, will reload the web application context when it detects changes.

3) If #1 and #2 fail, you need to restart the server to get the changes picked up.

It sounds like MyEclipse is doing #1 correctly and it’s portion of #2, but JBoss/Tomcat is not reloading the changed class file. You might check the docs to see if you can get it to recognize the changes easily and reload.

Also as far as JBoss memory/cpu spikes and running out of memory, that is outside the realm of MyEclipse and my only guess there is that if you are consuming huge amounts of memory you may have a leak some where or are abusing HIbernate and not realizing it (e.g. not lazy-loading collections).

[ebagdonas]

Thank you – the information you present confirms what we know, and I will take a look at the tomcat docs to see if there is something that was missed.

#1 – as stated is working correctly.
#2 – is apparently not working as – although in server.xml we have reloadable=”true” based on the use case presented:

The use case support desired is – modify code. save / compile, reload page and see the results without using debugging.

As for the memory I agree that this is outside the realm of ME – although we have run the app through profilers and have have the application in production without memory errors. Again – I’ll take a look at the documents to see if by reloading we are not doing something twice that should be done once.

[Riyad Kalla]

You know I’ve seen VM’s crash before because of too many reload cycles, like if I’m working in Tomcat and cause it to reload the context 20 or so times, so it’s possible the out of memory errors are at the app server level and not in your actual app.

[ebagdonas]

I think we have closure.

1) Hotswap works fine in all cicrumstances.
2) If the debugger is connected then you can – modify code. save / compile, reload page and see the results without actually debugging.
3) Both of these were done with reloadable=”false” aka the default.

After some investigation the memory / performance problems was due to singleton in our application that reallocated all its resource on reload. The default reload time (15s) may have had something to do with it as well. None the lese without reload – no problems.

[ebagdonas]

..

[Riyad Kalla]

Thank you for the follow up, it sounds like things are going more smoothly now.

[Author]

Posts