thread safe implementations

[Sean Gillies]

Dan,

Truly, the Java mapscript had been abandoned for a while.  Then Umberto
stepped forward and contributed a new Makefile and patches, and it seems
to be in a workable state.  I've also fixed the most obvious threading
issues in MapServer itself.

I'd really appreciate it if the two of you would download the new 4.4.0
beta releases and try them out.  Make some servlets and pound on them
and
see if Java mapscript is reliable.  I think this is really the only way
to know for sure.

BTW, once you have MapServer itself compiled, the Java Makefile in 4.4.0
works fine with FC2.

Sean

On Nov 4, 2004, at 8:12 AM, Dan Barron wrote:

> Umberto,
>
> I'm not going to try to recreate the functionality of the cgi - I'm not
> fully sure yet what absolute path I will take - I really have not done
> much
> threaded java code.  I've looked at the java mapscript - and your map
> server wiki entries for compiling java mapscript - I'm not convinced I
> have
> a good compile yet (platform is Fedora Core 2).  Is the java mapscript
> viable at this point?  I have read posts from earlier this year saying
> it
> looked abandoned?
>
> I would really like to get to an all java solution if possible - I
> currently use a combination of java/php (java opens a connection to a
> php
> script then parses the returned data) - not the best but it seems to
> work
> fine under light loads.
>
> I'd be interested to hear more about what you are up to - it sounds
> interesting.  I would really like to just build a threaded front end
> (maybe
> a thread pool?) to the map server functionality via java mapscript and
> nothing more.
>
> Thanks,
> Dan
>
> At 11:51 PM 11/3/2004, unicoletti at prometeo.it wrote:
>> Dan,
>> if by creating a java implementation you mean writing a web app to
>> deliver the
>> same (or  subset) of the functionality the cgi does, then I am
>> writing one.
>>
>> I think I am one of the few java mapscript users around :-)
>>
>> Regards,
>> umberto
>>
>> Quoting Sean Gillies <sgillies at FRII.COM>:
>>
>>> Dan,
>>>
>>> It's not clear to me what you mean by creating a java implementation
>>> on your own.  Implementation of what?  Do you mean a programming API
>>> like the php mapscript module?
>>>
>>> If this is what you mean, you should look at the Java stuff that
>>> you can generate using SWIG.  In mapserver versions 4.2.4+ and in
>>> the 4.4.0 beta1 there is a Java makefile under
>>> mapserver/mapscript/java.
>>> It seems to work, but as I've said -- I'm not a Java user and so am
>>> not beating on the Java mapscript module heavily enough or often
>>> enough to say anything about its readiness.
>>>
>>> Sean
>>>
>>> On Nov 3, 2004, at 10:37 AM, Dan Barron wrote:
>>>
>>>> Hmmm - I was really hoping someone had done (or attempted) a java
>>>> implementation - I'm not versed in Zope or Python.  Well, I guess I
>>>> will
>>>> attempt to create a java implementation on my own.
>>>>
>>>> Thanks Sean.
>>>>
>>>> Dan
>>>>
>>>> At 01:10 PM 11/2/2004, Sean Gillies wrote:
>>>>> On Nov 2, 2004, at 10:47 AM, Dan Barron wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Just curious what the current consensus and recommendations are
>>>>>> for
>>>>>> creating a thread safe front end or wrapper for mapserver in
>>>>>> either
>>>>>> php or
>>>>>> java? I'm assuming that mapserver is still not thread safe - that
>>>>>> correct?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Dan
>>>>>
>>>>> Dan,
>>>>>
>>>>> I caught and fixed three sources of potential threading problems
>>>>> before
>>>>> the 4.2.4 release and these fixes will also be in 4.4.0.  I think
>>>>> we're
>>>>> close to thread safety, but it's hard to say without more testing.
>>>>>  As
>>>>> far as I know, my ZMapServer (Zope + Python mapscript) software is
>>>>> the
>>>>> only thing out there that is using MapServer in a multi-threaded
>>>>> environment.  It works, but is not a complete proof of thread
>>>>> safety.
>>>>>
>>>>> There remains much work to be done to in improving MapServer's
>>>>> threaded performance.  The single lexer for parsing mapfiles and
>>>>> class expressions is a bottleneck that will be addressed in the
>>>>> future.
>>>>>
>>>>> cheers,
>>>>> Sean
>>>>>
>>>>> --
>>>>> Sean Gillies
>>>>> sgillies at frii dot com
>>>>> http://users.frii.com/sgillies
>>>>
>>>
>