[mapserver-users] Mapscript/Java/Servlet users: give this a whirl...

[C F]

Thanks for you sharing your experience.  That really helps... even if it 
wasn't what I wanted to hear :)
In fact, on my way in to work this morning (where I have plenty of time to 
sit in my car and ponder such things).... I began going over all my 
requirements again and wondering if I may be able to get around the whole 
problem by doing something similar to what you said.... just using JSP (or 
whatever) to manipulate the submitted URL parameters (and possibly creating 
a mapfile on the fly) and forwarding the request to the CGI program.  That 
just might be good enough for me.
Just out of curiousity though, I think I will try your thread locking 
solution below.  I agree with you about "scalability".  That is not my 
primary concern right now.  If I ever get that many users, I'll find a way 
to deal with it.  My main concern is stability, speed and functionality.  It 
seems that mapserv is pretty bulletproof, so maybe this jsp->cgi option is 
the best if I'm able to accomplish everything I need.


>From: David Graham <dgraham at i3.com>
>To: C F <gis_consultant at hotmail.com>
>CC: hwehr at hs-harz.de,  mapserver-users at lists.gis.umn.edu
>Subject: Re: [mapserver-users] Mapscript/Java/Servlet users: give this a 
>whirl...
>Date: Thu, 27 Jun 2002 10:52:45 -0600
>
>CF,
>
>It is a threading issue. I was woring with java and mapserver back last 
>fall with pre-release 3.5. I know they have been working on the thread safe 
>issues in mapserver but it does not supprise me that it has not gotten 
>there yet. I have sepent a good bit of time inside the mapserver (maplib) 
>code and have found numerous items that sent up red flags for thread safe 
>utilization. In the end I deciced not to connect mapserver directly to 
>tomcat but to simply call the mapserv CGI from tomcat. This was suitable 
>for us since we did not need dynamic content on the map part. It may not 
>work for you.
>
>One thing you might want to do is to mashal threads prior to calling the 
>offending subroutine. You would do it by sinchronizing on a singular object 
>in the JVM. Yes this will cause a bottle neck and a lack of scalablility. 
>But you should ask yourself what is your current user base before you worry 
>too much about scalablility. (My experience shows that scalablility is over 
>rated. Most businesses I have worked for that worried too much about 
>scalablility up front, have found themselfs decaring bankrupsy because 
>traffic never did ramp up! Is your product really going to be in that much 
>demand?)
>
>Here is how you would do it.
>
>public static class MyLock {
>// This class does nothing is just used to lock threads against.
>}
>
>inside your subroutine
>code....
>synchronize ( MyLock ) {
>offending_subroutine( args );
>}
>more code...
>
>Dave Graham
>


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com