[Geoserver-users] Strange interefence of GeoServer with JBossWeb 2.0

Hi,

I am using GeoServer in a JBoss 4.2.x container. JBoss uses a modified version of Tomcat 6 (JBossWeb).

The strange thing is that every web page hosted on JbossWeb that requests something from a GeoServer (1.5 or 1.6) deployed to the same instance of JBossWeb will result in HTTP responses with garbled headers. This happens on a random basis, but pages that issue more than 10 requests to JBossWeb while loading will almost always suffer from that behaviour by either displaying some random characters at the top of the page or not rendering images correctly.

If I use plain Tomcat 6 with the same application, everything goes well. I tested it as well in Linux and Windows environments, both i386, and both with JDK 1.6.

To reproduce this behaviour, install Mapbuilder 1.5rc1 and GeoServer 1.5 or 1.6 on the same instance of JBoss 4.2.x and point your browser to http://localhost:8080/mapbuilder/examples/wfs-t/. You might see that either the HTML page has random characters at the top, or that some images (e.g. button icons) are not loaded. Even if the page looks fine, clicking the FeatureInfo button and then on a feature will probably result in an XML error, because the GetFeature XML returned from GeoServer might contain random characters at the beginning.

You might have to try several times after clearing the browser cache, but it happens from time to time. I have an application that issues by far more requests to JBossWeb when loading, and with that failure is even more likely.

As I said, in plain Tomcat 6 everything works fine.

Any ideas?

Thanks!
Andreas.

Andreas Hocevar wrote:

Hi,

I am using GeoServer in a JBoss 4.2.x container. JBoss uses a modified version of Tomcat 6 (JBossWeb).

The strange thing is that every web page hosted on JbossWeb that requests something from a GeoServer (1.5 or 1.6) deployed to the same instance of JBossWeb will result in HTTP responses with garbled headers. This happens on a random basis, but pages that issue more than 10 requests to JBossWeb while loading will almost always suffer from that behaviour by either displaying some random characters at the top of the page or not rendering images correctly.

Sometimes, but not always (probably only after leaving the server untouched for an hour or so), this is accompanied by an exception like that:

13:34:58,618 FATAL [JspFactoryImpl] Exception initializing page context
java.lang.IllegalStateException: Cannot create a session after the response has been committed
    at org.apache.catalina.connector.Request.doGetSession(Request.java:2284)
    at org.apache.catalina.connector.Request.getSession(Request.java:2066)
    at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
    at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:844)
    at org.apache.jasper.runtime.PageContextImpl._initialize(PageContextImpl.java:149)
    at org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:127)
    at org.apache.jasper.runtime.JspFactoryImpl.internalGetPageContext(JspFactoryImpl.java:107)
    at org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java:63)
    at org.apache.jsp.lib.mapbuilderConfig_jsp._jspService(mapbuilderConfig_jsp.java:44)
    at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:387)
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
    at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
    at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
    at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

Regards,
Andreas.

Andreas Hocevar ha scritto:

Andreas Hocevar wrote:

Hi,

I am using GeoServer in a JBoss 4.2.x container. JBoss uses a modified version of Tomcat 6 (JBossWeb).

The strange thing is that every web page hosted on JbossWeb that requests something from a GeoServer (1.5 or 1.6) deployed to the same instance of JBossWeb will result in HTTP responses with garbled headers. This happens on a random basis, but pages that issue more than 10 requests to JBossWeb while loading will almost always suffer from that behaviour by either displaying some random characters at the top of the page or not rendering images correctly.

Sometimes, but not always (probably only after leaving the server untouched for an hour or so), this is accompanied by an exception like that:

13:34:58,618 FATAL [JspFactoryImpl] Exception initializing page context
java.lang.IllegalStateException: Cannot create a session after the response has been committed
    at org.apache.catalina.connector.Request.doGetSession(Request.java:2284)
    at org.apache.catalina.connector.Request.getSession(Request.java:2066)
    at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
    at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:844)
    at org.apache.jasper.runtime.PageContextImpl._initialize(PageContextImpl.java:149)
    at org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:127)
    at org.apache.jasper.runtime.JspFactoryImpl.internalGetPageContext(JspFactoryImpl.java:107)
    at org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java:63)
    at org.apache.jsp.lib.mapbuilderConfig_jsp._jspService(mapbuilderConfig_jsp.java:44)

Hmmm... no, I've never heard of this issue but I don't use JBoss either... the above exception does not seem to have anything to do with Geoserver thought, it's hitting a standard jsp deployed in another web application?

Googling for "Cannot create a session after the response has been committed jbossweb" returns a lot of hits thought, various apps that
are breaking in jboss with the same error. It seems one has to access
the session before writing a single byte to the output.

About the garbled headers, I don't know either... I remember that struts
sets the headers multiple times during its activity, but afaik all other
geoserver operations do not...

Cheers
Andrea

Hi,

Andrea Aime wrote:

Hmmm... no, I've never heard of this issue but I don't use JBoss either... the above exception does not seem to have anything to do with Geoserver thought, it's hitting a standard jsp deployed in another web application?

Yes, but the strange thing is that these exceptions do not occur when Geoserver is not deployed.

About the garbled headers, I don't know either... I remember that struts
sets the headers multiple times during its activity, but afaik all other
geoserver operations do not...

Hm. The problem is that I just cannot use Geoserver like this in a productive environment. It makes me crazy, because I googled using hundreds of different search terms, but nobody ever seems to have witnessed anything like this.

Again, strange is that I can reproduce this on various systems and with various applications: as soon as Geoserver is deployed, files from war/ear archives that contain servlets and/or jsp are affected. And not only output generated by servlets and/or jsp, but also static files like images, xml files and so on.

Regards,
Andreas.

Andreas Hocevar ha scritto:

Hi,

Andrea Aime wrote:

Hmmm... no, I've never heard of this issue but I don't use JBoss either... the above exception does not seem to have anything to do with Geoserver thought, it's hitting a standard jsp deployed in another web application?

Yes, but the strange thing is that these exceptions do not occur when Geoserver is not deployed.

About the garbled headers, I don't know either... I remember that struts
sets the headers multiple times during its activity, but afaik all other
geoserver operations do not...

Hm. The problem is that I just cannot use Geoserver like this in a productive environment. It makes me crazy, because I googled using hundreds of different search terms, but nobody ever seems to have witnessed anything like this.

Again, strange is that I can reproduce this on various systems and with various applications: as soon as Geoserver is deployed, files from war/ear archives that contain servlets and/or jsp are affected. And not only output generated by servlets and/or jsp, but also static files like images, xml files and so on.

Andreas, it's not that I don't want to help you, but I really don't
know how... I don't use JBoss, I don't run other apps besides GeoServer,
and moreover, I have really no clue about what is going on...

The only problematic interaction between GeoServer and other apps
in JBoss that I'm aware of is GeoServer programmatically controlling
log4j, and jboss sorely failing to isolate the other apps from
what geoserver is doing (http://jira.codehaus.org/browse/GEOS-1671).
Yet I don't see how playing with logging might interact with the http headers of other apps...

Can you give us more information? How are the headers getting ruined?
What's the extra chars you see, are there extra fields?

Cheers
Andrea

Andrea-

Andrea Aime wrote:

Andreas, it's not that I don't want to help you, but I really don't
know how... I don't use JBoss, I don't run other apps besides GeoServer,
and moreover, I have really no clue about what is going on...

I understand that, and I appreciate your efforts, thank you! Unfortunately, I also have no clue. Meanwhile I found out that you do not need another application at all. JBoss also seems to behave strange with just Geoserver deployed. This is a stack trace I got a minute ago when I tried to open the Geoserver admin page after starting JBoss, then issuing a wms request, and then opening the JBoss admin page (http://localhost:8080/):

21:44:22,244 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing
java.lang.IllegalStateException: Cannot call sendRedirect() after the response has been committed
    at org.apache.catalina.connector.Response.sendRedirect(Response.java:1228)
    at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:438)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:239)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

The Geoserver admin page was not loaded, instead I got a blank page.

The only problematic interaction between GeoServer and other apps
in JBoss that I'm aware of is GeoServer programmatically controlling
log4j, and jboss sorely failing to isolate the other apps from
what geoserver is doing (http://jira.codehaus.org/browse/GEOS-1671).
Yet I don't see how playing with logging might interact with the http headers of other apps...

Hm. This is interesting. I now even removed the log4j jar from the geoserver deployment. But nothing changed. Then I replaced the log4j jar of the JBoss distribution with the one from the Geoserver distribution. There was a small change: now, when issueing a WMS request for the first time, the following is logged:

21:51:24,803 INFO [DispatcherServlet] Initializing servlet 'dispatcher'
21:51:24,813 INFO [DispatcherServlet] FrameworkServlet 'dispatcher': initialization started
21:51:24,813 INFO [[/geoserver]] Loading WebApplicationContext for Spring FrameworkServlet 'dispatcher'
21:51:24,814 INFO [XmlBeanDefinitionReader] Loading XML bean definitions from ServletContext resource [/WEB-INF/dispatcher-servlet.xml]
21:51:24,834 INFO [XmlWebApplicationContext] Bean factory for application context [WebApplicationContext for namespace 'dispatcher-servlet']: org.springframework.beans.factory.support.DefaultListableBeanFactory defining beans [requestDispatcher,filePublisher,urlMapping]; parent: org.springframework.beans.factory.support.DefaultListableBeanFactory defining beans [catalog,serviceFinder,wfs,wfsConfig,wfsRegisterar,wfsConfigRegisterar,wfsAbstractService,wfsService,wfsGetCapabilities,wfsDescribeFeatureType,wfsGetFeature,wfsLockFeature,wfsGetFeatureWithLock,wfsTransaction,validation,validationConfig,validationRegisterar,validationConfigRegisterar,config,geoServer,globalConfig,data,dataConfig,dataRegisterar,dataConfigRegisterar,globalConfigRegisterar,geoServerRegisterar,speedServiceStrategy,fileServiceStrategy,bufferServiceStrategy,partialBufferServiceStrategy2,wms,wmsConfig,wmsRegisterar,wmsConfigRegisterar,wmsAbstractService,wmsService,wmsGetCapabilities,wmsGetCapabilitiesLegacy,wmsDescribeFeatureType,wmsGetFeatureInfo,wmsGetLegendGraphic,wmsGetMap,wmsGetMapLegacy,wmsPutStyles,kmlReflector,wmsReflect,GIFLegendProducerFactory,JaiLegendProducerFactory,PNGLegendProducerFactory,PNGMapProducerFactory,GeoTiffMapProducerFactory,TiffMapProducerFactory,SVGMapProducerFactory,GIFMapProducerFactory,KMLMapProducerFactory,KMZMapProducerFactory,PDFMapProducerFactory,JPEGMapProducerFactory,OpenLayersMapProducerFactory,GeoRSSMapProducerFactory,wcs,wcsConfig,wcsRegisterar,wcsConfigRegisterar,wcsAbstractService,wcsService,wcsGetCapabilities,wcsDescribeCoverage,wcsGetCoverage,applicationState,applicationStateRegisterar]; root of BeanFactory hierarchy
21:51:24,834 INFO [XmlWebApplicationContext] 3 beans defined in application context [WebApplicationContext for namespace 'dispatcher-servlet']
21:51:24,834 INFO [XmlWebApplicationContext] Unable to locate MessageSource with name 'messageSource': using default [org.springframework.context.support.DelegatingMessageSource@anonymised.com]
21:51:24,834 INFO [XmlWebApplicationContext] Unable to locate ApplicationEventMulticaster with name 'applicationEventMulticaster': using default [org.springframework.context.event.SimpleApplicationEventMulticaster@anonymised.com5...]
21:51:24,834 INFO [UiApplicationContextUtils] Unable to locate ThemeSource with name 'themeSource': using default [org.springframework.ui.context.support.DelegatingThemeSource@anonymised.com]
21:51:24,834 INFO [DefaultListableBeanFactory] Pre-instantiating singletons in factory [org.springframework.beans.factory.support.DefaultListableBeanFactory defining beans [requestDispatcher,filePublisher,urlMapping]; parent: org.springframework.beans.factory.support.DefaultListableBeanFactory defining beans [catalog,serviceFinder,wfs,wfsConfig,wfsRegisterar,wfsConfigRegisterar,wfsAbstractService,wfsService,wfsGetCapabilities,wfsDescribeFeatureType,wfsGetFeature,wfsLockFeature,wfsGetFeatureWithLock,wfsTransaction,validation,validationConfig,validationRegisterar,validationConfigRegisterar,config,geoServer,globalConfig,data,dataConfig,dataRegisterar,dataConfigRegisterar,globalConfigRegisterar,geoServerRegisterar,speedServiceStrategy,fileServiceStrategy,bufferServiceStrategy,partialBufferServiceStrategy2,wms,wmsConfig,wmsRegisterar,wmsConfigRegisterar,wmsAbstractService,wmsService,wmsGetCapabilities,wmsGetCapabilitiesLegacy,wmsDescribeFeatureType,wmsGetFeatureInfo,wmsGetLegendGraphic,wmsGetMap,wmsGetMapLegacy,wmsPutStyles,kmlReflector,wmsReflect,GIFLegendProducerFactory,JaiLegendProducerFactory,PNGLegendProducerFactory,PNGMapProducerFactory,GeoTiffMapProducerFactory,TiffMapProducerFactory,SVGMapProducerFactory,GIFMapProducerFactory,KMLMapProducerFactory,KMZMapProducerFactory,PDFMapProducerFactory,JPEGMapProducerFactory,OpenLayersMapProducerFactory,GeoRSSMapProducerFactory,wcs,wcsConfig,wcsRegisterar,wcsConfigRegisterar,wcsAbstractService,wcsService,wcsGetCapabilities,wcsDescribeCoverage,wcsGetCoverage,applicationState,applicationStateRegisterar]; root of BeanFactory hierarchy]
21:51:24,850 INFO [DispatcherServlet] Using context class [org.springframework.web.context.support.XmlWebApplicationContext] for servlet 'dispatcher'
21:51:24,851 INFO [DispatcherServlet] Unable to locate MultipartResolver with name 'multipartResolver': no multipart request handling provided
21:51:24,852 INFO [DispatcherServlet] Unable to locate LocaleResolver with name 'localeResolver': using default [org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver@anonymised.com]
21:51:24,853 INFO [DispatcherServlet] Unable to locate ThemeResolver with name 'themeResolver': using default [org.springframework.web.servlet.theme.FixedThemeResolver@anonymised.com]
21:51:24,861 INFO [DispatcherServlet] No HandlerAdapters found in servlet 'dispatcher': using default
21:51:24,869 INFO [DispatcherServlet] No ViewResolvers found in servlet 'dispatcher': using default
21:51:24,869 INFO [DispatcherServlet] FrameworkServlet 'dispatcher': initialization completed in 56 ms
21:51:24,869 INFO [DispatcherServlet] Servlet 'dispatcher' configured successfully

This was not logged with the JBoss version of log4j. But the problems persist.

Can you give us more information? How are the headers getting ruined?
What's the extra chars you see, are there extra fields?

This is hard to accomplish, because it happens on a random base. But I was able to catch one. I got the following stack trace when trying to open the Geoserver admin page, after clicking around on some pages also served by the same JBossWeb instance:

22:05:25,736 ERROR [[action]] Servlet.service() for servlet action threw exception
java.lang.IllegalStateException: Cannot forward after response has been committed
    at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:313)
    at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
    at org.vfny.geoserver.config.web.tiles.MultipleDelegatingTilesRequestProcessor.doForward(MultipleDelegatingTilesRequestProcessor.java:372)
    at org.vfny.geoserver.config.web.tiles.MultipleDelegatingTilesRequestProcessor.processTilesDefinition(MultipleDelegatingTilesRequestProcessor.java:217)
    at org.vfny.geoserver.config.web.tiles.MultipleDelegatingTilesRequestProcessor.processForwardConfig(MultipleDelegatingTilesRequestProcessor.java:80)
    at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:241)
    at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
    at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:103)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
    at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
    at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
    at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)
22:05:25,737 ERROR [[localhost]] Exception Processing ErrorPage[exceptionType=java.lang.Exception, location=/WEB-INF/pages/errors/Exception.jsp]
java.lang.IllegalStateException
    at org.apache.coyote.Response.reset(Response.java:297)
    at org.apache.catalina.connector.Response.reset(Response.java:652)
    at org.apache.catalina.connector.Response.reset(Response.java:916)
    at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:417)
    at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:271)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
    at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

The response from JBossWeb was just a blank page with a "0" as content. Unfortunately, I was never able to catch the headers, because the problems only seem to occur when many requests are issued to the server in a very short time, something I could not simulate with wget, which I used to get the headers.

Another catch was the following page of my other application. The page (including headers!) starts with the following lines:

dc9
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd&quot;&gt;
<html>
<head>

So obviously, there were no headers sent at all.

Ok, this is all information I was able to gather. I still have no clue, hopefully somebody else has? Could it maybe have to do with clustering? Because this is one of the main differences between Apache Tomcat and JBossWeb.

Regards,
Andreas.

Andreas Hocevar wrote:

Andrea-

Andrea Aime wrote:

Andreas, it's not that I don't want to help you, but I really don't
know how... I don't use JBoss, I don't run other apps besides GeoServer,
and moreover, I have really no clue about what is going on...

Sorry for my previous posting, this was an outdated body for an updated subject.

I think I was able to solve the problem: JBossWeb seems to need the "Apache Tomcat Native Library". I installed it on my Gentoo box (emerge tomcat-native), and now the errors seem to be gone.

I will do more testing tomorrow and let you know if it also works on Windows.

Regards,
Andreas.