Connector issues
Hi,
we, in Enhydra Development Team, have a little problem with Tomcat 5.5.9
administration.
There are some Connector issues that I want to point out here.
1. In new Enhydra 6.4-1 (based on Tomcat 5.5.9) we are enabling secure SSL HTTP
Connector initialization (default connector configuration present in
'server.xml' configuration file with adaptable port setting). This part is
working great!
But, when we try to administer installed Tomcat through its 'admin' application
(change something in server configuration and commit changes) SSL HTTP
connector configuration gets corrupted. All connector parameters are saved
except 'sslProtocol' attribute setting which is not saved (I presume) because
of its default value (TLS). On server restart (when there is no 'sslProtocol'
parameter defined) SSL HTTP connector is initialized (without any exception -
OK) but isn't functional any more and 'admin application - SSL HTTP Connector -
SSL Protocol' parameter setting is empty.
Tomcat documentation is saying that 'sslProtocol' parameter is not obligate
(default value is TLS) but it's a bit different in practice (must be some bug
in HTTP connector-protocol initialization).
I've tried to find the cause of the problem in Tomcat source code!
It seems that problem can be resolved with simple implementation change in
'org.apache.catalina.connector.Connector' class
/**
* Set the secure connection flag that will be assigned to requests
* received through this connector.
*
* @param secure The new secure connection flag
*/
public void setSecure(boolean secure) {
this.secure = secure;
// additionally set 'secure' ProtocolHandler property trough
IntrospectionUtils class
setProperty(secure, String.valueOf(secure));
}
This code adaptation seems to be working for me. I didn't manage to test this
(my spare time is very limited) heavily but I hope that someone will take some
time to look into this.
2. We (in Enhydra) have 'Enhydra Director' - web server plug-in for Apache,
IIS and IPlanet supporting advanced load balancing, clustering and runtime
administration.
To enable communication between Tomcat and 'Director' we have our own protocol
implementation ('Enhydra Director Protocol').
When we add director-protocol implementation (binary) to Tomcat and (manually)
insert additional (Director) Connector configuration in 'server.xml' file
everything is working (perfect).
But, there is a question of runtime creation and reconfiguration (like for
other HTTP and AJP protocol implementations).
We adapted original Tomcat Admin application (few simple implementation
changes) and 'org.apache.catalina.mbeans.MBeanFactory' (implemented creation of
Director connector) Tomcat class together with 'mbeans-decriptors.xml' file.
Is there a way to enable creation and configuration of custom connector
(protocol) implementations during server runtime in predefined (elegant)
manner?
I don't want to patch original Tomcat binaries!
Regards,
Slobodan Vujasinovic
Enhydra Development Team
Re: AJP/Java connector issues
Mladen Turk wrote:
Hi,
Just noticed a strange behavior in the Java part of the
JK dealing with large (over 8184 bytes) data transfers.
Since with 8192 bytes AJP packet size, the maximum
transferred size per each packet is 8184 bytes one
would expect that for 2 bytes file the packets
would be in a form of:
1:8184,2:8184,3:3632 thus total of 2 bytes.
But in fact the behavior is rely weird:
1:8184,2:8,3:8184,4:8,5:3616.
Instead only three, the five! packets are transferred.
Seems that algorithm is breaking 8192 bytes of data to
two packets (8184 and 8 bytes).
I have an ugly patch for that. Find it attached (that just for gettting
comments).
Cheers
Jean-Frederic
Bill,
Any idea how to solve this, because it's way too
inefficient.
What's makes the things even worse is that for each
packet Apache2 creates a transient bucket thus
rising the memory usage.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: Response.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Response.java,v
retrieving revision 1.12
diff -u -r1.12 Response.java
--- Response.java 25 Apr 2005 22:06:30 - 1.12
+++ Response.java 20 May 2005 15:56:25 -
@@ -68,6 +68,16 @@
public Response() {
+outputBuffer = new OutputBuffer();
+outputStream = new CoyoteOutputStream(outputBuffer);
+writer = new CoyoteWriter(outputBuffer);
+urlEncoder.addSafeCharacter('/');
+}
+
+public Response(int size) {
+outputBuffer = new OutputBuffer(size);
+outputStream = new CoyoteOutputStream(outputBuffer);
+writer = new CoyoteWriter(outputBuffer);
urlEncoder.addSafeCharacter('/');
}
@@ -174,20 +184,19 @@
/**
* The associated output buffer.
*/
-protected OutputBuffer outputBuffer = new OutputBuffer();
+protected OutputBuffer outputBuffer;
/**
* The associated output stream.
*/
-protected CoyoteOutputStream outputStream =
-new CoyoteOutputStream(outputBuffer);
+protected CoyoteOutputStream outputStream;
/**
* The associated writer.
*/
-protected CoyoteWriter writer = new CoyoteWriter(outputBuffer);
+protected CoyoteWriter writer;
/**
Index: Connector.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java,v
retrieving revision 1.18
diff -u -r1.18 Connector.java
--- Connector.java 30 Apr 2005 03:32:43 - 1.18
+++ Connector.java 20 May 2005 15:56:42 -
@@ -897,7 +897,12 @@
*/
public Response createResponse() {
-Response response = new Response();
+System.out.println(Connector: createResponse: getProtocol: +
getProtocol());
+Response response = null;
+if (AJP/1.3.equals(getProtocol()))
+response = new Response(8184);
+else
+response = new Response();
response.setConnector(this);
return (response);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP/Java connector issues
- Original Message -
From: jean-frederic clere [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Friday, May 20, 2005 9:02 AM
Subject: Re: AJP/Java connector issues
Mladen Turk wrote:
Hi,
Just noticed a strange behavior in the Java part of the
JK dealing with large (over 8184 bytes) data transfers.
Since with 8192 bytes AJP packet size, the maximum
transferred size per each packet is 8184 bytes one
would expect that for 2 bytes file the packets
would be in a form of:
1:8184,2:8184,3:3632 thus total of 2 bytes.
But in fact the behavior is rely weird:
1:8184,2:8,3:8184,4:8,5:3616.
Instead only three, the five! packets are transferred.
Seems that algorithm is breaking 8192 bytes of data to
two packets (8184 and 8 bytes).
I have an ugly patch for that. Find it attached (that just for gettting
comments).
If we move the protocol check into Response.setConnector, the patch isn't
even that ugly ;-).
Cheers
Jean-Frederic
Bill,
Any idea how to solve this, because it's way too
inefficient.
What's makes the things even worse is that for each
packet Apache2 creates a transient bucket thus
rising the memory usage.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: Response.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catali
na/connector/Response.java,v
retrieving revision 1.12
diff -u -r1.12 Response.java
--- Response.java 25 Apr 2005 22:06:30 - 1.12
+++ Response.java 20 May 2005 15:56:25 -
@@ -68,6 +68,16 @@
public Response() {
+outputBuffer = new OutputBuffer();
+outputStream = new CoyoteOutputStream(outputBuffer);
+writer = new CoyoteWriter(outputBuffer);
+urlEncoder.addSafeCharacter('/');
+}
+
+public Response(int size) {
+outputBuffer = new OutputBuffer(size);
+outputStream = new CoyoteOutputStream(outputBuffer);
+writer = new CoyoteWriter(outputBuffer);
urlEncoder.addSafeCharacter('/');
}
@@ -174,20 +184,19 @@
/**
* The associated output buffer.
*/
-protected OutputBuffer outputBuffer = new OutputBuffer();
+protected OutputBuffer outputBuffer;
/**
* The associated output stream.
*/
-protected CoyoteOutputStream outputStream =
-new CoyoteOutputStream(outputBuffer);
+protected CoyoteOutputStream outputStream;
/**
* The associated writer.
*/
-protected CoyoteWriter writer = new CoyoteWriter(outputBuffer);
+protected CoyoteWriter writer;
/**
Index: Connector.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catali
na/connector/Connector.java,v
retrieving revision 1.18
diff -u -r1.18 Connector.java
--- Connector.java 30 Apr 2005 03:32:43 - 1.18
+++ Connector.java 20 May 2005 15:56:42 -
@@ -897,7 +897,12 @@
*/
public Response createResponse() {
-Response response = new Response();
+System.out.println(Connector: createResponse: getProtocol: +
getProtocol());
+Response response = null;
+if (AJP/1.3.equals(getProtocol()))
+response = new Response(8184);
+else
+response = new Response();
response.setConnector(this);
return (response);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication
in error, please notify us immediately by e-mail and then delete all copies of
this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through
the Internet is not secure. Do not send confidential or sensitive information,
such as social security numbers, account numbers, personal identification
numbers and passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AJP/Java connector issues
Hi, Just noticed a strange behavior in the Java part of the JK dealing with large (over 8184 bytes) data transfers. Since with 8192 bytes AJP packet size, the maximum transferred size per each packet is 8184 bytes one would expect that for 2 bytes file the packets would be in a form of: 1:8184,2:8184,3:3632 thus total of 2 bytes. But in fact the behavior is rely weird: 1:8184,2:8,3:8184,4:8,5:3616. Instead only three, the five! packets are transferred. Seems that algorithm is breaking 8192 bytes of data to two packets (8184 and 8 bytes). Bill, Any idea how to solve this, because it's way too inefficient. What's makes the things even worse is that for each packet Apache2 creates a transient bucket thus rising the memory usage. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP/Java connector issues
Mladen Turk wrote: Hi, Just noticed a strange behavior in the Java part of the JK dealing with large (over 8184 bytes) data transfers. Since with 8192 bytes AJP packet size, the maximum transferred size per each packet is 8184 bytes one would expect that for 2 bytes file the packets would be in a form of: 1:8184,2:8184,3:3632 thus total of 2 bytes. But in fact the behavior is rely weird: 1:8184,2:8,3:8184,4:8,5:3616. Instead only three, the five! packets are transferred. Look to Ajp13.java: public static final int MAX_SEND_SIZE = MAX_PACKET_SIZE - H_SIZE - 4; 8184. The CoyoteWriter gets called with blocks of 8192 bytes max... 8184+8... Seems that algorithm is breaking 8192 bytes of data to two packets (8184 and 8 bytes). Bill, Any idea how to solve this, because it's way too inefficient. What's makes the things even worse is that for each packet Apache2 creates a transient bucket thus rising the memory usage. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP/Java connector issues
Mladen Turk wrote: Hi, Just noticed a strange behavior in the Java part of the JK dealing with large (over 8184 bytes) data transfers. Since with 8192 bytes AJP packet size, the maximum transferred size per each packet is 8184 bytes one would expect that for 2 bytes file the packets would be in a form of: 1:8184,2:8184,3:3632 thus total of 2 bytes. But in fact the behavior is rely weird: 1:8184,2:8,3:8184,4:8,5:3616. Instead only three, the five! packets are transferred. Seems that algorithm is breaking 8192 bytes of data to two packets (8184 and 8 bytes). Ajp13.java... No that is the old code the new one is in JkCoyoteHandler.java. In JkCoyoteHandler the method doWrite cuts the 8192 bytes in 2 messages: one of 8184 and the other of 8 bytes that is the problem. Bill, Any idea how to solve this, because it's way too inefficient. What's makes the things even worse is that for each packet Apache2 creates a transient bucket thus rising the memory usage. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP/Java connector issues
- Original Message - From: Mladen Turk [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Cc: Bill Barker [EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 11:44 PM Subject: AJP/Java connector issues Hi, Just noticed a strange behavior in the Java part of the JK dealing with large (over 8184 bytes) data transfers. Since with 8192 bytes AJP packet size, the maximum transferred size per each packet is 8184 bytes one would expect that for 2 bytes file the packets would be in a form of: 1:8184,2:8184,3:3632 thus total of 2 bytes. But in fact the behavior is rely weird: 1:8184,2:8,3:8184,4:8,5:3616. Instead only three, the five! packets are transferred. Seems that algorithm is breaking 8192 bytes of data to two packets (8184 and 8 bytes). Bill, Any idea how to solve this, because it's way too inefficient. What's makes the things even worse is that for each packet Apache2 creates a transient bucket thus rising the memory usage. It's probably Nagle (which is off by default). Try tcpNoDelay=false. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP/Java connector issues
- Original Message - From: Mladen Turk [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Cc: Bill Barker [EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 11:44 PM Subject: AJP/Java connector issues Hi, Just noticed a strange behavior in the Java part of the JK dealing with large (over 8184 bytes) data transfers. Since with 8192 bytes AJP packet size, the maximum transferred size per each packet is 8184 bytes one would expect that for 2 bytes file the packets would be in a form of: 1:8184,2:8184,3:3632 thus total of 2 bytes. But in fact the behavior is rely weird: 1:8184,2:8,3:8184,4:8,5:3616. Instead only three, the five! packets are transferred. Seems that algorithm is breaking 8192 bytes of data to two packets (8184 and 8 bytes). Bill, Any idea how to solve this, because it's way too inefficient. What's makes the things even worse is that for each packet Apache2 creates a transient bucket thus rising the memory usage. I see what this is now: The default Connector OutputBuffer size is 8K, so it's sending the output to JkInputStream in 8K chunks. JkInputStream sends all of the 8K to Apache in two chunks. As a Coyote OutputBuffer, it's not really JkInputStream's job to do additional buffering. It's probably better to do response.setBufferSize(2); so that the Connector will send the whole thing to JkInputStream as one chunk. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP/Java connector issues
Bill Barker wrote: I see what this is now: The default Connector OutputBuffer size is 8K, so it's sending the output to JkInputStream in 8K chunks. JkInputStream sends all of the 8K to Apache in two chunks. As a Coyote OutputBuffer, it's not really JkInputStream's job to do additional buffering. It's probably better to do response.setBufferSize(2); so that the Connector will send the whole thing to JkInputStream as one chunk. Sure that seems to be the problem, but it's hard to convince the users to write the applications having AJP packet size in mind ;) The best would be that instead default 8192 bytes, when AJP connector is loaded that response size is either set to 8184 or 16386 bytes (one or two packets) by default. Is something like that possible? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP/Java connector issues
- Original Message - From: Mladen Turk [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, May 19, 2005 2:19 PM Subject: Re: AJP/Java connector issues Bill Barker wrote: I see what this is now: The default Connector OutputBuffer size is 8K, so it's sending the output to JkInputStream in 8K chunks. JkInputStream sends all of the 8K to Apache in two chunks. As a Coyote OutputBuffer, it's not really JkInputStream's job to do additional buffering. It's probably better to do response.setBufferSize(2); so that the Connector will send the whole thing to JkInputStream as one chunk. Sure that seems to be the problem, but it's hard to convince the users to write the applications having AJP packet size in mind ;) The best would be that instead default 8192 bytes, when AJP connector is loaded that response size is either set to 8184 or 16386 bytes (one or two packets) by default. Is something like that possible? It would be really easy to default to 8184 for all Connectors (just change the value in o.a.c.connector.OutputBuffer). I'm not so sure how happy that would make Remy. It wouldn't be too hard to have Connector.createResponse check the protocol, and if it's AJP/1.3 then set the buffer size to 16386 (currently it's not possible to decrease the buffer size). It wouldn't be that hard to add buffering to JkInputStream so that it always tries to write out a 8184 packet. This would also prevent fracturing in the event that the webapp programmer decides to call response.setBufferSize herself. The downside would be an extra arraycopy when writing (and, of course, an extra 8184*numThreads bytes of memory used :). Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP/Java connector issues
Bill Barker wrote: Is something like that possible? It would be really easy to default to 8184 for all Connectors (just change the value in o.a.c.connector.OutputBuffer). I'm not so sure how happy that would make Remy. Not much I'm afraid ;) It wouldn't be too hard to have Connector.createResponse check the protocol, and if it's AJP/1.3 then set the buffer size to 16386 (currently it's not possible to decrease the buffer size). That would be great. It wouldn't be that hard to add buffering to JkInputStream so that it always tries to write out a 8184 packet. This would also prevent fracturing in the event that the webapp programmer decides to call response.setBufferSize herself. The downside would be an extra arraycopy when writing (and, of course, an extra 8184*numThreads bytes of memory used :). Not very optimal IMO. If somebody sets the buffer size by hand, then, well, he probably knows better :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP/Java connector issues
Mladen Turk wrote: Bill Barker wrote: Is something like that possible? It would be really easy to default to 8184 for all Connectors (just change the value in o.a.c.connector.OutputBuffer). I'm not so sure how happy that would make Remy. Not much I'm afraid ;) It wouldn't be too hard to have Connector.createResponse check the protocol, and if it's AJP/1.3 then set the buffer size to 16386 (currently it's not possible to decrease the buffer size). That would be great. It wouldn't be that hard to add buffering to JkInputStream so that it always tries to write out a 8184 packet. This would also prevent fracturing in the event that the webapp programmer decides to call response.setBufferSize herself. The downside would be an extra arraycopy when writing (and, of course, an extra 8184*numThreads bytes of memory used :). Not very optimal IMO. If somebody sets the buffer size by hand, then, well, he probably knows better :) None of these solve a real issue. Right now, the AJP packet generation will do byte copying, which is bad unless you also use that mandatory copying to minimize the amount of network packets sent. It's the same as chunking in HTTP, and does need a socket buffer for best efficiency. Conviniently, with APR, I need to have direct buffers to handle read and write, so I'll use them as the socket buffers (like in HTTP). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector issues
Jeff Tulley wrote: I think I've got a fix for the connector thing, gotta still try it out to be sure. I just thought that the mbeans-descriptors fix is low hanging fruit. IE, with just a simple little fix, every time somebody is forced to go back to the old connector for one reason or another, they won't immediately come back to the list with the complaint of I'm getting the following exception. I had been in favor of making the exception look nicer (but got vetoed by Craig way back then). OTOH, I am against adding the declaration in the descriptors, which would make it sound the thing is supported. The AJP 1.3 connector is based on the code from the old HTTP/1.1 connector, which likely had issues in its thread pool (in addition to being very wasteful GC wise). I strongly advise against using it. But if an upgrade to commons-modeler would also fix the problem without changing deprecated code, I'm all for doing that instead. Let me go check out my code changes to CoyoteRequest, see how they work... Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector issues
I think I've got a fix for the connector thing, gotta still try it out to be sure. I just thought that the mbeans-descriptors fix is low hanging fruit. IE, with just a simple little fix, every time somebody is forced to go back to the old connector for one reason or another, they won't immediately come back to the list with the complaint of I'm getting the following exception. But if an upgrade to commons-modeler would also fix the problem without changing deprecated code, I'm all for doing that instead. Let me go check out my code changes to CoyoteRequest, see how they work... Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 4/2/03 8:57:09 PM Sorry for the delay. IMO the right solution is to fix #10229 for coyote. There are a lot of problems in the old connectors - even if mod_jk2 is not yet as stable as mod_jk1, the java side and coyote are far better than the old impl. I'm +0 on fixing the MBean exception - AFAIK upgrading commons-modeler should fix most of the problems with undeclared mbeans. The real problem is that the Ajp13Connector has a lot of problems and it's no longer supported - all work is on the coyote connector, I don't know anyone testing or supporting Ajp13. Costin Jeff Tulley wrote: There are some real problems with the Coyote Connectors right now. The main problem biting me (and a few others recently) is bugzilla bug # 10229 - form parameters not being preserved across a login redirection. The answer given on the user list (by me also) is typically, Use an non-Coyote connector. Unfortunately that is not a good answer. If they move back to the deprecated AJP13Connector, they will experience MBean exceptions that, among other things, make the Tomcat shutdown not function correctly. Beyond that they are stuck with not using a webserver plugin and instead going directly to an HTTP connector (non-Coyote). I would propose two things: 1) Fix the MBean exception in the Ajp13Connector. I can provide a patch for this, it is very simple. Even though this is deprecated, the reality is that people might need to use it due to bugs and/or unimplemented features in the Coyote connectors. It may be their only choice, and if we can make it work easily, why not? 2) Fix this form authentication problem in the Coyote connector. I will look into this and see if it is something that I can do and submit a patch for. I actually have similar issues with the native side connector story but that is for another day. Anybody know off hand what needs to happen for item #2 above? Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector issues
Sorry for the delay. IMO the right solution is to fix #10229 for coyote. There are a lot of problems in the old connectors - even if mod_jk2 is not yet as stable as mod_jk1, the java side and coyote are far better than the old impl. I'm +0 on fixing the MBean exception - AFAIK upgrading commons-modeler should fix most of the problems with undeclared mbeans. The real problem is that the Ajp13Connector has a lot of problems and it's no longer supported - all work is on the coyote connector, I don't know anyone testing or supporting Ajp13. Costin Jeff Tulley wrote: There are some real problems with the Coyote Connectors right now. The main problem biting me (and a few others recently) is bugzilla bug # 10229 - form parameters not being preserved across a login redirection. The answer given on the user list (by me also) is typically, Use an non-Coyote connector. Unfortunately that is not a good answer. If they move back to the deprecated AJP13Connector, they will experience MBean exceptions that, among other things, make the Tomcat shutdown not function correctly. Beyond that they are stuck with not using a webserver plugin and instead going directly to an HTTP connector (non-Coyote). I would propose two things: 1) Fix the MBean exception in the Ajp13Connector. I can provide a patch for this, it is very simple. Even though this is deprecated, the reality is that people might need to use it due to bugs and/or unimplemented features in the Coyote connectors. It may be their only choice, and if we can make it work easily, why not? 2) Fix this form authentication problem in the Coyote connector. I will look into this and see if it is something that I can do and submit a patch for. I actually have similar issues with the native side connector story but that is for another day. Anybody know off hand what needs to happen for item #2 above? Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Connector issues
There are some real problems with the Coyote Connectors right now. The main problem biting me (and a few others recently) is bugzilla bug # 10229 - form parameters not being preserved across a login redirection. The answer given on the user list (by me also) is typically, Use an non-Coyote connector. Unfortunately that is not a good answer. If they move back to the deprecated AJP13Connector, they will experience MBean exceptions that, among other things, make the Tomcat shutdown not function correctly. Beyond that they are stuck with not using a webserver plugin and instead going directly to an HTTP connector (non-Coyote). I would propose two things: 1) Fix the MBean exception in the Ajp13Connector. I can provide a patch for this, it is very simple. Even though this is deprecated, the reality is that people might need to use it due to bugs and/or unimplemented features in the Coyote connectors. It may be their only choice, and if we can make it work easily, why not? 2) Fix this form authentication problem in the Coyote connector. I will look into this and see if it is something that I can do and submit a patch for. I actually have similar issues with the native side connector story but that is for another day. Anybody know off hand what needs to happen for item #2 above? Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector issues
Jeff Tulley wrote: There are some real problems with the Coyote Connectors right now. The main problem biting me (and a few others recently) is bugzilla bug # 10229 - form parameters not being preserved across a login redirection. The answer given on the user list (by me also) is typically, Use an non-Coyote connector. Unfortunately that is not a good answer. If they move back to the deprecated AJP13Connector, they will experience MBean exceptions that, among other things, make the Tomcat shutdown not function correctly. Beyond that they are stuck with not using a webserver plugin and instead going directly to an HTTP connector (non-Coyote). I would propose two things: 1) Fix the MBean exception in the Ajp13Connector. I can provide a patch for this, it is very simple. Even though this is deprecated, the reality is that people might need to use it due to bugs and/or unimplemented features in the Coyote connectors. It may be their only choice, and if we can make it work easily, why not? I would be interested in the patch to this. I have no issues with the Coyote connector at the moment -- but I would like to see the fallback (i.e. Ajp13Connector) in a more functional state. 2) Fix this form authentication problem in the Coyote connector. I will look into this and see if it is something that I can do and submit a patch for. I actually have similar issues with the native side connector story but that is for another day. I was under the impression that mod_jk2 was not production ready by most measures -- and that mod_jk was good enough for most purposes (and quite production ready)... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector issues
I actually have similar issues with the native side connector story but that is for another day. I was under the impression that mod_jk2 was not production ready by most measures -- and that mod_jk was good enough for most purposes (and quite production ready)... I said those were issues for another day. :) Actually yes, mod_jk works. And it is good enough for most purposes. What we want is a lot of the new features that had been slated for mod_webapp, but there is no further development on it. Also, mod_jk2 as you say is not production ready. It has some coding assumptions that make it not portable to some other platforms, which is a real problem (I'd have to look at the code for specifics; this is second-hand from the person who tried to port it to NetWare). Yet what I hear time and time again is encouragement for people moving away from mod_jk and to mod_jk2. It makes sense if that is the future direction of the connectors, but the story is full of holes still. We have chosen to stick with mod_jk for now, but would sure like to move on to mod_jk2. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Patch] mbeans-descriptors.xml (was Re: Connector issues)
Here is the patch for the Ajp13Connector. The one caveat is that this patch allows Tomcat to startup and shutdown without MBean exceptions, but the Tomcat Admin application still will not work with this connector enabled. That is, the admin app functions, but do not click on Connector in the application, since it is looking for a Coyote connector and does not find the getters and setters it is looking for. When I tried it, I clicked on Connector first and it seemed like I couldn't get anything else to work after that. If I clicked on something else first (Host, for instance), then clicked on Connector I got the error but the rest of the admin application worked fine. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 4/1/03 10:12:32 AM 1) Fix the MBean exception in the Ajp13Connector. I can provide a patch for this, it is very simple. Even though this is deprecated, the reality is that people might need to use it due to bugs and/or unimplemented features in the Coyote connectors. It may be their only choice, and if we can make it work easily, why not? ta.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] mbeans-descriptors.xml (was Re: Connector issues)
Jeff Tulley wrote: Here is the patch for the Ajp13Connector. The one caveat is that this patch allows Tomcat to startup and shutdown without MBean exceptions, but the Tomcat Admin application still will not work with this connector enabled. That is, the admin app functions, but do not click on Connector in the application, since it is looking for a Coyote connector and does not find the getters and setters it is looking for. When I tried it, I clicked on Connector first and it seemed like I couldn't get anything else to work after that. If I clicked on something else first (Host, for instance), then clicked on Connector I got the error but the rest of the admin application worked fine. It's not a good idea to imply that the old AJP connector is to be used. It is slow and unreliable, and will not work with Tomcat 5. Also, it is not compatible with the admin webapp, and the MBean descriptor is only used in conjunction with the admin webapp in Tomcat, so adding the AJP connector there will only lead to problems later. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] mbeans-descriptors.xml (was Re: Connector issues)
I agree. But, as I said in my earlier email, there are defects in the Coyote Connector driving people to use something else. If I absolutely need bug#10229 fixed, what choice do I have? I am wondering if the reality is that people will be forced to use the Ajp13Connector, so we might as well fix this very simple bug. Yes there will be other problems, but at least the connector still works. The mbean descriptor is not only used with the admin, but also it seems like Tomcat would not shut down if this connector was enabled. I think it was a ServiceLifeCycleException of some sort. We should also fix the Coyote Connector problem. I am trying to get some time to look at that issue. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 4/1/03 11:08:30 AM Jeff Tulley wrote: Here is the patch for the Ajp13Connector. The one caveat is that this patch allows Tomcat to startup and shutdown without MBean exceptions, but the Tomcat Admin application still will not work with this connector enabled. That is, the admin app functions, but do not click on Connector in the application, since it is looking for a Coyote connector and does not find the getters and setters it is looking for. When I tried it, I clicked on Connector first and it seemed like I couldn't get anything else to work after that. If I clicked on something else first (Host, for instance), then clicked on Connector I got the error but the rest of the admin application worked fine. It's not a good idea to imply that the old AJP connector is to be used. It is slow and unreliable, and will not work with Tomcat 5. Also, it is not compatible with the admin webapp, and the MBean descriptor is only used in conjunction with the admin webapp in Tomcat, so adding the AJP connector there will only lead to problems later. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector issues
- Original Message - From: Jeff Tulley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 9:12 AM Subject: Connector issues There are some real problems with the Coyote Connectors right now. The main problem biting me (and a few others recently) is bugzilla bug # 10229 - form parameters not being preserved across a login redirection. The answer given on the user list (by me also) is typically, Use an non-Coyote connector. Unfortunately that is not a good answer. If they move back to the deprecated AJP13Connector, they will experience MBean exceptions that, among other things, make the Tomcat shutdown not function correctly. Beyond that they are stuck with not using a webserver plugin and instead going directly to an HTTP connector (non-Coyote). I would propose two things: 1) Fix the MBean exception in the Ajp13Connector. I can provide a patch for this, it is very simple. Even though this is deprecated, the reality is that people might need to use it due to bugs and/or unimplemented features in the Coyote connectors. It may be their only choice, and if we can make it work easily, why not? 2) Fix this form authentication problem in the Coyote connector. I will look into this and see if it is something that I can do and submit a patch for. I actually have similar issues with the native side connector story but that is for another day. Anybody know off hand what needs to happen for item #2 above? Primarily, o.a.c.tc4.CoyoteRequest needs to implement addParameter (at least more than it does now :). There are probably a few other related methods that aren't functional as well. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
