incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Date Thu, 12 Jan 2006 12:45:37 GMT
A further issue:

On undeploying the demo app on TC, I sometimes see :

12:43:35,951 INFO  [WebappClassLoader] Illegal access: this web 
application instance has been stopped already.  Could not load 
org.activecluster.impl.NodeImpl.  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.
12:43:35,952 INFO  [WebappClassLoader] Illegal access: this web 
application instance has been stopped already.  Could not load 
org.activecluster.impl.NodeImpl.  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.
12:43:37,250 INFO  [WebappClassLoader] Illegal access: this web 
application instance has been stopped already.  Could not load 
org.activecluster.impl.NodeImpl.  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.
12:43:40,942 INFO  [WebappClassLoader] Illegal access: this web 
application instance has been stopped already.  Could not load 
org.activemq.message.ActiveMQTopic.  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.

On shutting down Geronimo after undeploying the demo app, AMQ sometimes 
seems to be unhappy....

I am hoping that both of these issues will go away once we and Geronimo 
upgrade to AMQ4.


Jules



Jules Gosnell wrote:

> Here is a list of outstanding issues associated with this work:
>
> - ActiveMQ's shutdown hook seems to trigger when Geronimo is shutdown, 
> removing AMQ before WADI - WADI doesn't like this. I have added a 
> property to the node.sh script which suppresses this behaviour. I will 
> document it in the Getting Started doc.
>
> - There 'may' be issues with nodes finding each other, when a Geronimo 
> node is introduced into a WADI cluster - investigating.
>
> - Jeff - you should look over the changes and make sure that they do 
> not impact on any other TC fn-ality. They were done with Emacs, so the 
> formatting may be offensive. Please feel free to make them your own 
> and bring any issues back to the list. The WADIGBean, is no longer 
> used, so you may want to remove this from the repo.
>
> - Jan and Jeff - since this config is now done on the container bean 
> and not in the geronimo-web.xml, you may no longer need to implement 
> your own geronimo-web.xml schemas (I haven't looked very closely at 
> TC). You may want to consider this and perhaps lose them.
>
> - In order to get the same webapp to work in all containers 
> (tomcat5[05], jetty[56], geronimo-[tomcat/jetty], jboss-tomcat), I had 
> to move deps back to Geronimo container-level. These include Axion, 
> which I know will upset Jeff. As I have stated before, WADI's 
> dependence on Axion is easily removed. If Jeff or anyone wants to look 
> at replacing it with Derby, it is fine with me, as long as they do 
> some testing and confirm that having created a session on a single 
> node and restarted it, the session survives (if the DB is still 
> running). This needs to be tested on all supported containers. Axion 
> was used because it is an in-VM DB (so imposes no further integration 
> dependencies on the Getting Started stuff and is useful for 
> unit-testing) and was in use by Geronimo at the time. So I suggest 
> that any replacement needs to also be able to run in-vm aswell. As we 
> go further and move WADI's actual configuration from the app to the 
> container-level, these issues will disappear and WADI will be able to 
> be hooked to whatever persistance mechanism is shipped in Geronimo by 
> default.
>
> - Jan & Jeff , you may want to consider pushing some of this session 
> manager selection code up into a shared GeronimoWebContainer 
> abstraction so that you don't both end up maintaining similar but 
> diverging code...
>
> - I may have overlooked a couple of issues. If I come across them, I 
> shall post them.
>
> Further work on Geronimo integration :
>
> - more testing
> - make a new WADI release and update geronimo-trunk to use it
> - look at applying diffs to a G1.0 tree and producing a binary patch 
> for 1.0 distros.
> - update website and release it
>
>
> Jules
>
>
>
> Jules Gosnell wrote:
>
>> Guys,
>>
>> Jan and I have just refactored the Geronimo Jetty and Tomcat 
>> integrations to take the same approach to the installation of a 3rd 
>> party session manager, to ease the integration of WADI. This is now 
>> checked in on Geronimo's trunk.
>>
>> Each top level web container GBean now supports a pair of attributes 
>> - LocalSessionManager and DistributableSessionManager. These may be 
>> used to override the container's choice of SessionManager for webapps 
>> with and without the <distributable/> tag present in the 
>> WEB-INF/web.xml, respectively.
>>
>> The attributes expect to be given a classname, if required, this 
>> class will be loaded and instantiated. The resulting instance will be 
>> used as the session manager. If not provided, the container will use 
>> a sensible default. Currently Jetty and TC are set up to use their 
>> own default session managers in the local case and the correct WADI 
>> session manager in the distributable case.
>>
>> This means that the same WADI-enabled webapp, with its plan held 
>> internally (WEB-INF/geronimo-web.xml) may now be hot-deployed on 
>> either a Jetty or a Tomcat based Geronimo, without changes :-)
>>
>> I will post specific WADI issues to the WADI dev lists 
>> (wadi-dev@incubator.apache.org, dev@wadi.codehaus.org).
>>
>> This shouldn't be seen as a final position on the subject - there is 
>> still much to talk about, but is a useful interim step, that allows 
>> us to have something working whilst we figure out how to go forward.
>>
>> Enjoy,
>>
>>
>> Jules
>>
>
>


-- 
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/


Mime
View raw message