I have some interesting news to report.
First of all, thanks Umberto for fixing the make test error so
quickly. You rock!
Ok, onto bussiness. I found out that make threadtests was a
wonderful way to reproduce the original error that was making tomcat
crash, and probably why it only happened on the server and not on my
machine. Running it with 1 thread (as it was being run in my single
processor / single user machine), it wouldn't crash. But running the
threadtests on the 4 processor server with 10 threads, it crashed
consistently about 65% of the time, on a 300 runs test. I increased it
to 30 threads and I got a 100% crash rate.
Now, witth Svn rev 6167, the same 300 consecutive runs with 10
threads of threadtests had a whooping ZERO crash rate!
Just to be sure, I increased it to 100 threads, and am about to let
it burn 10.000 times. I cant see how the application will will fare on
a real life situation yet, as apparently the folks responsible for
generating new versions on the production server don't come to work on
sundays. Slackers.
I will report back in the morning.
Best regards,
Rodrigo
--
*Rodrigo Del C. Andrade*
/Programador/
/SIC - SSE - Soluções Segurança Pública/
*DÍGITRO TECNOLOGIA*
*E-mail:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
*Fone:* +55 48 3281-7314 / +55 48 3281-7000
*Fax:* +55 48 3281-7299
*Site:* www.digitro.com <http://www.digitro.com>
Umberto Nicoletti wrote:
On 6/1/07, Oliver Wesp <[EMAIL PROTECTED]> wrote:
Hi everybody,
I just want thank everybody for the information in this thread. We're
facing similar issues with java mapscript crashing the vm. Unfortunately
the application relies on the dynamic creation of layers and classes.
I tried the svn version this afternoon and it seems to be stable. No
more tomcat crashes till now. I will do some more testing on monday but
it looks like Umberto was right with expecting some good news :-)
Yes, party time! ;-)
Umberto
Just in case this information is usefull: We're running our application
on Solaris 8 using Shapefiles, GDAL Raster (HFA) and WMS as datasources.
Tomcat is 5.0.28, JAVA is j2sdk1.4.2_11.
Regards,
Oliver
Umberto Nicoletti schrieb:
> I suggest against this practice (no pun intended Benedikt, I sincerely
> appreciate your help).
> I say let's wait until Rodrigo tries out a rfc-24 enabled build,
> frankly I am quite positive rfc-24 will fix his issues.
>
> Regards,
> Umberto
>
> On 6/1/07, Benedikt Rothe <[EMAIL PROTECTED]> wrote:
>>
>> Hi
>>
>> Some developers (Umberto, Tamas) work on a solution of this problem.
>>
>> As a workaround I made good experiences with
>> http://lists.umn.edu/cgi-bin/wa?A2=ind0506&L=mapserver-users&P=87500
>>
>> > if we dynamically create mapserver-objects, we allway use code like
>> this:
>> > classObj cO = new classObj(...);
>> > ..
>> > // Do something with cO
>> > ..
>> > //now cO isn't used any more
>> > cO.delete()
>>
>> With "freeing manually" we made the Mapserver inside Tomcat quite
stable.
>> Hope, this helps
>> Benedikt
>>
>>
>> UMN MapServer Users List <[email protected]> schrieb am
>> 31.05.2007 15:13:41:
>>
>> >
>> > Hello dear list.
>> >
>> > A problem is happening in our production machine which we were
>> > unable to reproduce on our development machines. We have a very
>> > large application almost ready for deployment, in which one of the
>> > modules is written in java mapscript 4.10.1, and the error on the
>> > attached log happened for the first time when we installed the
>> > application on the production server. Whats worse, the GIS module
>> > causing the error brings down Tomcat and the whole application
with
>> it.
>> > This is a excerpt from the JVM log:
>> >
>> > # An unexpected error has been detected by HotSpot Virtual
Machine:
>> > #
>> > # SIGSEGV (0xb) at pc=0x636ff93b, pid=19162, tid=1759710128
>> > #
>> > # Java VM: Java HotSpot(TM) Server VM (1.5.0_07-b03 mixed mode)
>> > # Problematic frame:
>> > # C [libmapscript.so+0x3893b]
>> >
>> Java_edu_umn_gis_mapscript_mapscriptJNI_delete_1layerObj+0xf
>> > #
>> >
