• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

independant contexts?

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetings all,

We are in the midst to trying to port a web application from JRun to Tomcat and We have run across a problem accessing an external DLL from within a tomcat host.

software: Window 2000 Server, IIS(6), Tomcat 5.0, isapi_redirector2.dll

Within our default host, we have created a number of contexts representing a number web applications. a number of these web application share one thing in common in that they use the same external DLL top do work for them.

the issue is that while one context is using the external DLL, none of the others can use it.

As I understand it the problem is that the DLL cannot be loaded twice into the same JVM. So, we are looking into how to execute these contexts (web-apps) in there own JVMs.

Suggestions and HOW-TOs would be most helpful

thanks!
dave hanson
 
Ranch Hand
Posts: 180
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What about tackling it from a different angle... why not write a singleton class that wraps your dll to create a loader and put that in the tomcat shared lib directory (I think its the shared one -- check on that but there is one that you put stuff like that into) so that it is loaded in only the tomcat jvm classloader.

The classes that rely on the original native class will need to be adapted to use the singleton class.

If I have totally lost you, feel free to email me for a better description. It's been a long tiring day.

Hope this helps.
 
Dave Hanson
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks for the reply...

howeverm I was really hoping for a solution that was related to the configuration of tomcat. I had been led to believe that this sort of configuration was possible and quite common. but as ussual, documentation is tough to get figured out.

Unfortunately the singleton solution would not work due to the fact that each of the three or more distinct applications would all attempt to load the same DLL in their singletons.

nope, I need to figure out how to make it so that each of these webapps can open it's own copy of the DLL for use.

any help would be greatly appreciated!
d
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Unfortunately the singleton solution would not work due to the fact that each of the three or more distinct applications would all attempt to load the same DLL in their singletons.


Have you actually tried this? Seems to me that if each application has its own class loader, your three singletons are in separate contexts, each with its own copy of the DLL is exactly what you want.
Bill
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by William Brogden:
[...] Seems to me that if each application has its own class loader, your three singletons are in separate contexts, each with its own copy of the DLL is exactly what you want.

But DLLs are loaded by the JVM using a System.loadLibrary() call, not by the Java classloader, aren't they?

Dave - please change your display name, by the way - I've never dealt with this issue, but it seems to me that you could get around it by sticking the offending library in Tomcat's shared lib directory. That way, all your webapps share a single copy of the class. Obviously it reduces the isolation between the webapps but I don't think there's a way around that short of running separate Tomcat instances.

- Peter
[ August 19, 2004: Message edited by: Peter den Haan ]
 
Dave Hanson
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
--regards the singleton idea--
Well, no, I have not as yet started to alter the code. as I mentioned earlier, there is some resistance to altering the code. ...and since it has been suggested (not here) that moving between JRun and Tomcat should be a simple and painless operation that has solidified the resistance toward changing the code.

...at any rate...
for whatever reason, the previous developer had implemented the move bby simply adding contexts (webapps) to the default host (localhost).
I have been playing with adding hosts to the base Service and that appears to be isolating the webapps in that previously accessible jars don't seen to be available any more.

comments? am I on the right track or simply going down the rabbit hole.

dh
 
Dave Hanson
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
...just for aruement's sake.

lets say I wanted to two completely isolated webapps (basically two apps running in two distinct instances of the JVM - possibly even different versions of the JVM).

how would i do this?

your assistance would be awesome!
dh
 
William Brogden
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thats not simple to do because the webapps would both have to listen to the same port, wouldn't they?
If this was my problem I would try to handle it with separate instances of a small application - each running in its own JVM and DLL instance and communicating with the web server by something like JavaSpaces. That way you could even have these small applications scattered around a network and you could create however many are needed to handle the load.
Whether or not this is practical would probably depend on how much data it takes to create the job that the DLL works on, how long it takes, etc.
I actually have a demo of JavaSpaces running on my website where the small apps do a phonetic lookup. It is kind of cool but the network delay is on the order of 250 millisecs
Bill
 
Saloon Keeper
Posts: 28486
210
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't pretend that all of this is making sense to me, but one of the primary reasons for the concept of a DLL to begin with was to share common code. While Windows file locking isn't the brightest, I'm pretty sure I remember that a DLL could be opened multiple times in a single app, even if that app isn't multithreaded. Unless I've simply confused myself with one of the other OS's I've worked with, there's a use count and it gets bumped up when new opens are done, bumped down when unloads are done, and when it goes back down to 0, the DLL can be unloaded.

OTOH, if the problem is contention, ANY resource that's expecting integrity when accessed by multiple threads - and every http requester can be counted as a seperate thread for most purposes (whether 1 context or 100) - is going to have to be multithreading aware, no matter what languages and servers are involved. This can be done directly in the code or by guarding the code with synchronization wrappers, but if you don't do SOMETHING, things will blow apart at unpredictable moments.
 
Dave Hanson
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by William Brogden:
Thats not simple to do because the webapps would both have to listen to the same port, wouldn't they?



nope, the apps work together communicating with each other through different ports. ...but a good point.

d
 
Dave Hanson
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tim Holloway:
I don't pretend that all of this is making sense to me, but one of the primary reasons for the concept of a DLL to begin with was to share common code. While Windows file locking isn't the brightest, I'm pretty sure I remember that a DLL could be opened multiple times in a single app, even if that app isn't multithreaded. Unless I've simply confused myself with one of the other OS's I've worked with, there's a use count and it gets bumped up when new opens are done, bumped down when unloads are done, and when it goes back down to 0, the DLL can be unloaded.

OTOH, if the problem is contention, ANY resource that's expecting integrity when accessed by multiple threads - and every http requester can be counted as a seperate thread for most purposes (whether 1 context or 100) - is going to have to be multithreading aware, no matter what languages and servers are involved. This can be done directly in the code or by guarding the code with synchronization wrappers, but if you don't do SOMETHING, things will blow apart at unpredictable moments.



Well, I've probably done a poor job of discribing the situation...
here's some history:
originally, we built a nice little engineering support application that worked great. too great. we became the victims of our own success and the number of jobs submitted soon outgrew the capacity of the system on the cheap hardware that the system was designed to work on. instead of moving the system to a more powerful machine, we suggested that the application be spread out amoung a number of cheap machines. so, basically, what we did was add a queueing system to the mix and replicated the system over 8 cheap machines. this gained a eight-fold increase in capacity with very little expense (actually the drones are retired desktops so there was no expense).

now what happens is that when the "parent" system gets a request for a report, or a model to be run, or a calculation to be done, the request is sent to the queue manager to be distributed amoung the 8 identical systems on the other machines. ...now, you may be thinking "what's the problem? ...they and all on seperate machines!" Well... each machine in the system actually runs three separate environemnts: test, prod, and demo

and that, my friends, is why I need to run a number of identical applications in isolated environments. Till now, we had been using JRun, but increaing licence costs and ther proposed addition of more drones have resulted a desire to the move the system off the JRun platform. Now, the way the system was written has allowed to move it without code changes however, it seems that there are some fundimental differences between
JRun and Tomcat that we had not expected. ...now I'm still hopefull that it is simply a lack of knowledge on our part as to how the same thing can be accomplished in the tomcat world. and so, we have come full circle to my orginal question...

lets say I wanted to two completely isolated webapps (basically two apps running in two distinct instances of the JVM - possibly even different versions of the JVM).

how would i do this?



at the moment, I keep getting this error:

2004-08-19 10:49:18 ApplicationDispatcher[/ocdrone] Servlet.service() for servlet invoker threw exception
java.lang.UnsatisfiedLinkError: Native Library C:\Tomcat\webapps\ocelot\paces_s32Interface.dll already loaded in another classloader
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)

when a drone attempts to access the DLL that has already been loaded by another copy of the application. ...for aruguments sake say a sales guy is doing a demo and a customer is running a model.

I hope this explains the situation well enough to allow you help me with my issue. you help is greatly appriecated!

dh
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dave Hanson:
lets say I wanted to two completely isolated webapps (basically two apps running in two distinct instances of the JVM - possibly even different versions of the JVM).

Over here we're using Apache (running on demo.objectivity.co.uk:80) to proxy subdirectories (e.g. demo.objectivity.co.uk:80/foo) through to the actual machines that run the demo (say, foo.internal:8080). So that's one way to do it.

- Peter
 
William Brogden
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So basically, the DLL is not Threadsafe, right?
It sounds like you have re-invented GRID computing - a current buzzword - cool.
Is there a reason that each DLL instance has to live in a web server?
If not, and the amount of data transferred is not too huge, it sure sounds like JavaSpaces to me. Take a look at http://computefarm.jini.org/
Bill
reply
    Bookmark Topic Watch Topic
  • New Topic