Hi Jesse,

Just to correct some of your points (and I was not saying that you could not post such a question in this mailing list, just that perhaps the people who know the answer are perhaps more on the Apache side rather than on the Jahia side...)

At 10:06 08/06/2004, you wrote:
a) Tomcat is bundled as part of Jahia and it relies on tomcat so I don�t have any way of moving to a different servlet engine (e.g. Jetty)

Wrong. The jahia CMS runs well under Weblogic (already in production with a large customer). Others did customized it to run with Websphere (http://list.jahia.org/dev_list/msg01317.html)... There is nothing specific to Tomcat in the Jahia code. We just package Tomcat by default to ease the first time user experience. Tomcat is also the reference implementation for the Servlet API so, as we can not ask to each Jahia contributor to test their code modifications with a dozen of different J2EE servers, we currently limit our code requirements and tests to the RI. But as servlets are not EJB, portability should not be so complex...

P.S:Portability should be easily possible at least for the CMS part. The portal layer uses some advanced filtering capabilities described in the Servlet specification and running fine under Tomcat but that other containers, mainly for performance reasons, bypass or do not implement from a similar and compliant manner. We hope this will change with the introduction of Pluto/Jetspeed2 in the next release of Jahia which is not using the same servlet calls to filter webapps outputs.

b) This list is specifically for installation problems pertaining to Jahia, which I would class this problem as

If I come back to your first point, yes, Tomcat is prepackaged with the Jahia default distribution but not Apache and mod-JK ;-)) No more seriously speaking the problem seems to be in the Tomcat/Mod-JK code rather than in the Jahia code itself, but as we are not committers in any of these two projects...

and finally
c) I�ve tried the tomcat user list and had no reply as of yet

That is a good answer ;-))

St�phane

 
Jesse
 

From: Stéphane Croisier [mailto:[EMAIL PROTECTED]]
Sent: 08 June 2004 09:01
To: [EMAIL PROTECTED]
Subject: RE: Jahia & SSL
 
Hello,

Are the Apache mailing lists not a better place to discuss such an issue which is more related to customization + performance fine tuning of JK and/or Tomcat than to Jahia itself...

My 2cts...
Stéphane

At 08:49 08/06/2004, you wrote:

Hi Michel,
 
I�m running Jahia 4.0.3 and I don�t get any errors in the tomcat console or any of the log files for tomcat.  I get the following error in the isapi.log (the JK connector log)
 
[Tue Jun 08 07:44:22 2004]  [jk_ajp_common.c (1318)]: Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. Failed errno = 61
[Tue Jun 08 07:44:22 2004]  [jk_isapi_plugin.c (928)]: HttpExtensionProc error, service() failed
 
I�m guessing this has to do with the number of worker threads available in Tomcat for handling AJP13 connections because it is an intermittent problem which appears only under higher loads, but I have set the number much higher than the number of clients accessing so I wouldn�t expect these problems.
 
Jesse
 

From: Michel Romy [mailto:[EMAIL PROTECTED]]
Sent: 07 June 2004 16:51
To: [EMAIL PROTECTED]
Subject: Re: Jahia & SSL
 
Hi jesse,

could you also mention the version of jahia you are running ? And can you trace what the errors are ? Have you got some exception in the tomcat console ?

Michel


Hi all,
 
I�m having serious trouble getting Jahia to work under SSL correctly.  I am running on a Win 2K3 machine with SUN JDK 1.4.2_04 and have used all of the following configurations in various combinations:
 
Tomcat 4.1.18 (as bundled with Jahia)
Tomcat 4.1.30
Tomcat 5.0.16
Tomcat 5.0.24
 
Apache 2.0.24 (with JK and JK2)
IIS (with JK)
 
The system works fine under these configurations for the most part, but when I run a load test (using JMeter, though I have also written a custom client in both Java and C# to rule out JMeter problems) after a while I get connection refused exceptions in the client.  Sometimes there are errors in the jk log files, but not always.  I increased the maxConnections for the AJP connector in tomcat to well above the number of client�s I am running, with no effect.  The error rate runs at anywhere between 0.01% and 2%, but the load on the server is not too sever.  The average response time for requests are well below 200 milliseconds, so I don�t think that the server is just running out of steam.
 
All of the requests are coming out of the front cache since I spider the website before running the load test to warm up the cache, so I don�t think it is anything to do with the size of the DB connection pool (though I wouldn�t expect that to cause the observed behaviour anyway)
 
I�ve played with maxKeepAlive, minConnections, maxConnections, acceptCount.  I�ve used both the CoyoteConnector and the deprecated AJP13Connector.
 
I�m kind of stuck now and would appreciate any suggestions might you have.
 
Jesse

--- Disclaimer ---

Unless otherwise agreed expressly in writing by a Director of Edina Software, this communication is to be treated as confidential and the information in it may not be used or disclosed except for the purpose for which it has been sent. If you have reason to believe that you are not the intended recipient of this communication, please contact the sender immediately.

--- Disclaimer ---

Unless otherwise agreed expressly in writing by a Director of Edina Software, this communication is to be treated as confidential and the information in it may not be used or disclosed except for the purpose for which it has been sent. If you have reason to believe that you are not the intended recipient of this communication, please contact the sender immediately.


--- Disclaimer ---

Unless otherwise agreed expressly in writing by a Director of Edina Software, this communication is to be treated as confidential and the information in it may not be used or disclosed except for the purpose for which it has been sent. If you have reason to believe that you are not the intended recipient of this communication, please contact the sender immediately.

Reply via email to