Rainer Jung wrote:
On 25.02.2009 13:56, Mladen Turk wrote:
Rainer Jung wrote:
On 19.02.2009 16:28, mt...@apache.org wrote:
Author: mturk
Date: Thu Feb 19 15:28:47 2009
New Revision: 745898
URL: http://svn.apache.org/viewvc?rev=745898&view=rev
Log:
Update uriworkermap on watchog interval
Modified:
tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
Modified: tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c?rev=745898&r1=745897&r2=745898&view=diff
==============================================================================
--- tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c (original)
+++ tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c Thu Feb
19 15:28:47 2009
@@ -2377,6 +2377,11 @@
jk_log(logger, JK_LOG_DEBUG,
"Watchdog thread running");
}
+ if (worker_mount_file[0]) {
+ jk_shm_lock();
+ uri_worker_map_update(uw_map, 0, logger);
+ jk_shm_unlock();
+ }
Why the shm lock/unlock? The map itself has a lock that gets used. We
don't use the shm lock around map_uri_to_worker_ext(), which also goes
down to map_uri_to_worker_ext().
Because IIS6+ can have multiple worker processes.
map lock is thread lock not shared across childs.
But do those processes share the same map? It is not in shared memory,
so each process should have it's own copy? Otherwise we would need to
consider the same for Apache 2.x.
Well, perhaps the mutex lock is not needed. I just payed safe
to make sure the entire update transaction is atomic cause it
happens from the watchdog thread, and jk_shm_lock() is the
only api we have for that.
Nevertheless: why is that needed for IIS? Isn't the map automatically
reloaded if needed?
Yes, but on the first request. If we have a watchdog we can do that
in advance before there is an request.
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
