Opened 16 years ago
Closed 16 years ago
#2533 closed defect (fixed)
protect calls to pj_transform() with TLOCK_PROJ
Reported by: | richf | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | MapServer C Library | Version: | 5.0 |
Severity: | normal | Keywords: | proj threads |
Cc: | tamas, hobu |
Description
It is hypothesized that this is the cause of errors of the form:
msProcessProjection(): Projection library error. no system list, errno: 22
and:
msProcessProjection(): Projection library error.
For more details, see the following mailing list thread:
http://www.nabble.com/msProcessProjection%28%29%3A-Projection-library-error.-to15815968.html
I can test any fix in my local environment that has been (sporadically) encountering the problem. Packaging up a reproducible test case would, however, not be trivial.
Change History (10)
comment:1 by , 16 years ago
Keywords: | proj threads added |
---|---|
Status: | new → assigned |
comment:2 by , 16 years ago
I have built the trunk along with a local patch for bug 2497:
http://trac.osgeo.org/mapserver/attachment/ticket/2497/ms_postgis_begin_to_connect.diff
and I will test tomorrow.
If this is successful, do you believe that this change could be applied to branch-5-0 as well as the trunk?
comment:3 by , 16 years ago
Rich,
Yes, the change is trivially appliable to 5.0 branch as well, but before I migrate it back I would want to review possible performance impacts.
comment:4 by , 16 years ago
I ran a test starting this morning, going for 6 hours, with the trunk (including this change) plus a local patch for bug 2497.
There were no reported errors, and no crashes. The only sign of any badness was the following message from tomcat:
Mar 4, 2008 2:50:13 PM org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (600) are currently busy, waiting. Increase maxThreads (600) or check the servlet status
which is not out of the question given the nature of the stress test, clearly beyond the scope of this bug, and even more importantly did not cause any badness.
I have also now build the tip of branch-5-0, along with local patches both for bug 2497 and for bug 2533 (in other words, this patch). I have started running the same 6 hour test and will report the results tomorrow.
comment:5 by , 16 years ago
Cc: | added |
---|
Adding Howard as this may also relate to the problem his client, the mapdotnet folks, have had with proj.4 in mapserver.
comment:6 by , 16 years ago
my latest test (svn r7432 from https://svn.osgeo.org/mapserver/branches/branch-5-0/mapserver, plus patches for bug 2497 and bug 2533) also ran fine for 6 hours under heavy load. i will be continuing to use this build for development and stress testing and will report if there are any other relevant issues here.
comment:7 by , 16 years ago
More tests eventually did cause a crash. While both the projection errors that caused this bug and the crash originate from mapObj.new(), I think they might be separate issues. Meaning that this bug fix might be necessary, but not sufficient. For more details, see:
http://www.nabble.com/msProcessProjection%28%29%3A-Projection-library-error.-to15815968.html
comment:8 by , 16 years ago
re: comment 7
The crash that I said I believe is a separate issue is now filed as bug 2550: http://trac.osgeo.org/mapserver/ticket/2550
comment:9 by , 16 years ago
according to the latest release notes:
http://trac.osgeo.org/mapserver/browser/tags/rel-5-2-0/mapserver/HISTORY.TXT
this was fixed as of:
Version 5.2.0-beta1 (2008-06-11): Acquire TLOCK_PROJ for pj_transform() calls (#2533).
can this bug now be closed?
I have surrounded all calls to pj_transform() by acquisition of the TLOCK_PROJ in trunk (r7428).
Testing to see if this helps would be appreciated.