Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
[EMAIL PROTECTED] wrote: jfclere 2005/06/08 09:52:58 Modified:jni/examples/org/apache/tomcat/jni SSLServer.java jni/java/org/apache/tomcat/jni BIOCallback.java SSL.java SSLContext.java jni/native/src ssl.c sslcontext.c Log: Change the BIOCallback interface to use write(byte[] buf) and read(byte[] buf); Add SSL_accept to do the client handshake. Arrange the corresponding example. +++ CUT +++ Hi, I am not 100% happy with the code. Mladen already asked me to rollback the changes. I think the worst thing is setSock() I have added to BIOCallback. My idea is/was to use BIOCallback or a similar interface to be able to openssl either with normal JAVA sockets or APR native ones. Comments? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
jean-frederic clere wrote: [EMAIL PROTECTED] wrote: Log: Change the BIOCallback interface to use write(byte[] buf) and read(byte[] buf); Add SSL_accept to do the client handshake. Arrange the corresponding example. +++ CUT +++ Hi, I am not 100% happy with the code. Mladen already asked me to rollback the changes. I think the worst thing is setSock() I have added to BIOCallback. Yes please rollback. My idea is/was to use BIOCallback or a similar interface to be able to openssl either with normal JAVA sockets or APR native ones. I plan to create the SSLSocket that will use created Socket (here I speak about Native sockets only) then obtain apr_os_sock_t and then do a SSL accept on that accepted socket. SSLSocket.create will create tcn_ssl_t from SSLContext and will contain both apr_sock_t* and SSL*. We need APR socket to be able to do the polling on the SSL sockets as well. Please give me a day or two to finish the skeleton implementation, that will do a basic s_server/s_client. BIOCallback will be used only for: 1. Password callbacks 2. Error logging 3. Custom byte streams for certificate data contained in non file system storage. For example right now we have: SSLContext.setCertificate(..., file, ...) I plan to add the: SSLContext.setCertificate(..., BIOCallback, ...) read/write callback methods could be used for reading certificate data from database blobs, or directly from keystorage. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_util.c
mturk 2005/06/09 01:14:51 Modified:jk/native/common jk_util.c Log: Fix typo. Revision ChangesPath 1.70 +4 -4 jakarta-tomcat-connectors/jk/native/common/jk_util.c Index: jk_util.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v retrieving revision 1.69 retrieving revision 1.70 diff -u -r1.69 -r1.70 --- jk_util.c 15 May 2005 15:22:05 - 1.69 +++ jk_util.c 9 Jun 2005 08:14:51 - 1.70 @@ -786,12 +786,12 @@ v = jk_map_get_string(m, buf, NULL); if (!v) return JK_LB_LOCK_DEFAULT; -else if (*v == 'o' || *v == 'O' || *v == '1') +else if (*v == 'o' || *v == 'O' || *v == '0') return JK_LB_LOCK_DEFAULT; -else if (*v == 'p' || *v == 'P' || *v == '0') +else if (*v == 'p' || *v == 'P' || *v == '1') return JK_LB_LOCK_PESSIMISTIC; else -return JK_LB_BYREQUESTS; +return JK_LB_LOCK_DEFAULT; } int jk_get_lb_worker_list(jk_map_t *m, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35264] - Typo and slight inconsistency in jk locking constants
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35264. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35264 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-06-09 10:16 --- Fixed in the CVS. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
- Original Message - From: jean-frederic clere [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, June 09, 2005 12:20 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c [EMAIL PROTECTED] wrote: jfclere 2005/06/08 09:52:58 Modified:jni/examples/org/apache/tomcat/jni SSLServer.java jni/java/org/apache/tomcat/jni BIOCallback.java SSL.java SSLContext.java jni/native/src ssl.c sslcontext.c Log: Change the BIOCallback interface to use write(byte[] buf) and read(byte[] buf); Add SSL_accept to do the client handshake. Arrange the corresponding example. +++ CUT +++ Hi, I am not 100% happy with the code. Mladen already asked me to rollback the changes. I think the worst thing is setSock() I have added to BIOCallback. My idea is/was to use BIOCallback or a similar interface to be able to openssl either with normal JAVA sockets or APR native ones. Comments? It looked OK to me. Basically it's the APR implementation of SSLEngine. Don't really see a problem. Of course, I don't really care about the APR-SSL Connector one way or the other. Since the config is the same as for mod_ssl, there is absolutely no reason to not simply use mod_ssl instead. If I just wanted the native-code optimizations, I'd use PureTLS instead. Cheers Jean-Frederic - 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: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
Bill Barker wrote: I am not 100% happy with the code. Mladen already asked me to rollback the changes. It looked OK to me. Basically it's the APR implementation of SSLEngine. Don't really see a problem. It does not, because it should fit inside the APR standard socket implementation. Having callbacks would actually make a thing way slower, because we would have to call the native, and from the native call the Java that would call back the native again. Of course, I don't really care about the APR-SSL Connector one way or the other. Since the config is the same as for mod_ssl, there is absolutely no reason to not simply use mod_ssl instead. If I just wanted the native-code optimizations, I'd use PureTLS instead. It's not an APR-SSL connector, but rather the SSL support for the APR connector. Since all that is optional feel free to just not use it :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
jfclere 2005/06/09 02:13:55
Modified:jni/examples/org/apache/tomcat/jni SSLServer.java
jni/java/org/apache/tomcat/jni BIOCallback.java SSL.java
SSLContext.java
jni/native/src ssl.c sslcontext.c
Log:
Undo my previous commit.
Revision ChangesPath
1.4 +1 -52
jakarta-tomcat-connectors/jni/examples/org/apache/tomcat/jni/SSLServer.java
Index: SSLServer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jni/examples/org/apache/tomcat/jni/SSLServer.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SSLServer.java8 Jun 2005 16:52:57 - 1.3
+++ SSLServer.java9 Jun 2005 09:13:54 - 1.4
@@ -47,27 +47,6 @@
}
}
-private class CallBack implements BIOCallback {
-long clientSock = 0;
-public int write(byte [] buf) {
-return(Socket.send(clientSock, buf, 0, buf.length));
-}
-public int read(byte [] buf) {
-return(Socket.recv(clientSock, buf, 0, buf.length));
-}
-public int puts(String data) {
-System.out.println(CallBack.puts);
-return -1;
-}
-public String gets(int len) {
-System.out.println(CallBack.gets);
-return ;
-}
-public void setsock(long sock) {
-clientSock = sock;
-}
-}
-
public SSLServer()
{
int i;
@@ -81,36 +60,6 @@
SSLContext.setCertificate(serverCtx, serverCert, serverKey,
serverPassword, SSL.SSL_AIDX_RSA);
SSLContext.setVerifyDepth(serverCtx, 10);
SSLContext.setVerifyClient(serverCtx, SSL.SSL_CVERIFY_REQUIRE);
-
-CallBack SSLCallBack = new CallBack();
-long callback = SSL.newBIO(serverPool, SSLCallBack);
-/*
-SSLContext.setBIO(serverCtx, callback, 1);
-SSLContext.setBIO(serverCtx, callback, 0);
- */
-long serverSSL = SSL.make(serverCtx, callback, callback);
-
-long serverSock = Socket.create(Socket.APR_INET,
Socket.SOCK_STREAM,
-Socket.APR_PROTO_TCP,
serverPool);
-long inetAddress = Address.info(SSLServer.serverAddr,
Socket.APR_INET, SSLServer.serverPort, 0, serverPool);
-int rc = Socket.bind(serverSock, inetAddress);
-if (rc != 0) {
-throw(new Exception(Can't bind: + Error.strerror(rc)));
-}
-Socket.listen(serverSock, 5);
-long clientSock = Socket.accept(serverSock, serverPool);
-long sa = Address.get(Socket.APR_REMOTE, clientSock);
-Sockaddr raddr = new Sockaddr();
-if (Address.fill(raddr, sa)) {
-System.out.println(Remote Host: + Address.getnameinfo(sa,
0));
-System.out.println(Remote IP: + Address.getip(sa) +
- : + raddr.port);
-}
-SSLCallBack.setsock(clientSock);
-int retcode = SSL.accept(serverSSL);
-if (retcode=0) {
-throw(new Exception(Can't SSL accept: +
SSLContext.geterror(serverCtx, retcode)));
-}
} catch (Exception e) {
e.printStackTrace();
1.3 +7 -7
jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/BIOCallback.java
Index: BIOCallback.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/BIOCallback.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- BIOCallback.java 8 Jun 2005 16:52:58 - 1.2
+++ BIOCallback.java 9 Jun 2005 09:13:54 - 1.3
@@ -26,17 +26,17 @@
/**
* Write data
- * @param buf containg the bytes to write.
- * @return Number of characters written.
+ * @param data String to write
+ * @return Number of characters written
*/
-public int write(byte [] buf);
+public int write(String data);
/**
* Read data
- * @param buf buffer to store the read bytes.
- * @return number of bytes read.
+ * @param len Maximum number of characters to read
+ * @return String with up to len bytes readed
*/
-public int read(byte [] buf);
+public String read(int len);
/**
* Puts string
1.15 +1 -16
jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/SSL.java
Index: SSL.java
===
RCS file:
Re: AJP using APR
Bill Barker wrote: So, where is it already? Some of use want to see how you can beat Costin ;-). Right now, I'm not planning on beating anyone, it's just my crap work code (which doesn't actually work yet). I haven't benched anything, and my experience with AJP is very limited. I used the package org.apache.coyote.ajp for it, and it reuses most of the message code, parsing and composition from regular AJP. One of the issues I'm facing, however, is that the usage of JNI will make the current code subpar, where it would be a lot better to do message reading and writing (this means composition of the messages to avoid useless bytes copying) using direct buffers. So there's a lot of work left, and it will remain experimental for a little while. If I understand you correctly, you want MsgAjp to use ByteBuffer instead of byte []. At the cost of never supporting JDK 1.3 ever again, this would probably actually improve the performance of ChannelSocket (after changing it to use a blocking SocketChannel). Well, yes, I'll have to use a direct ByteBuffer like I do for HTTP. Otherwise, byte array copy over JNI will be slower. It's quite annoying, but using JNI imposes a certain design for buffering :( One of the possibilities is to have AjpMessage (I renamed it, sorry) backed by a direct BB, or - as I am investigating at the moment - just write directly to a large BB. Reading, which faces the same problem, will likely have to use a large direct BB to avoid useless copying. For example, the current AJP code does two reads to read a message. Since in JNI, the best optimization is to lower the amount of JNI calls, this will have to be changed (which has fairly large consequences). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35282] New: - Unable to use connector AJP on W2003 Server with IIS 6.0 and JBOSS 3.2.5
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35282. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35282 Summary: Unable to use connector AJP on W2003 Server with IIS 6.0 and JBOSS 3.2.5 Product: Tomcat 5 Version: 5.0.0 Platform: PC OS/Version: other Status: NEW Severity: major Priority: P2 Component: Connector:AJP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] On a W2003 server with IIS 6.0, we used JBOSS 3.2.5 for our application. We try to use the AJP connector. So we get the dll isapi_redirect-1.2.13.dll and the howto document. So, i create an ISAPI filter called jakarta on IIS Web Site. I create a virtual directory called jakarta. I create a virtual directory called CCS on my application.war under JBOSS. I create file uriworkermap.properties: /CCS/*.jsp=titi I create file workers.properties: workers.tomcat_home=c:/xxx/jboss-3.2.5/server/CCS/deploy/jbossweb-tomcat50.sar workers.java_home=c:/j2sdk1.4.2_04 ps=\ worker.list=titi worker.titi.port=8009 worker.titi.host=localhost worker.titi.type=ajp13 worker.ajp13.lbfactor=1 I update the registry database: [HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0] extension_uri=/jakarta/isapi_redirect-1.2.13.dll log_file=C:\\xxx\\jboss-3.2.5\\server\\CCS\\log\\isapi.log log_level=debug worker_file=C:\\xxx\\jboss-3.2.5\\server\\CCS\\deploy\\jbossweb- tomcat50.sar\\META-INF\\workers.properties worker_mount_file=C:\\xxx\\jboss-3.2.3\\server\\CCS\\deploy\\jbossweb- tomcat50.sar\\META-INF\\uriworkermap.properties I restart IIS. My filter ISAPI is green. I start JBOSS. I fail to connect to http://localhost/CCS/User/Login.jsp. In my isapi.log file, i have: [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] jk_shm_open::jk_shm.c (91): Initialized shared memory size=66560 free=65536 addr=0x13a9310 [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] init_jk::jk_isapi_plugin.c (1132): Using registry. [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] init_jk::jk_isapi_plugin.c (1135): Using log file C:\AccessCommerce\CCS42\jboss-3.2.5 \server\CCS\log\isapi.log. [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] init_jk::jk_isapi_plugin.c (1136): Using log level 1. [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] init_jk::jk_isapi_plugin.c (1137): Using extension uri . [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] init_jk::jk_isapi_plugin.c (1138): Using worker file C:\AccessCommerce\CCS42\jboss-3.2.5 \server\CCS\deploy\jbossweb-tomcat50.sar\workers.properties. [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] init_jk::jk_isapi_plugin.c (1139): Using worker mount file C:\AccessCommerce\CCS42\jboss-3.2.5 \server\CCS\deploy\jbossweb-tomcat50.sar\uriworkermap.properties. [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] init_jk::jk_isapi_plugin.c (1141): Using uri select 0. [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] uri_worker_map_add::jk_uri_worker_map.c (260): wildchar rule /CCS/*=titi was added [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] build_worker_map::jk_worker.c (236): creating worker titi [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] wc_create_worker::jk_worker.c (141): about to create instance titi of ajp13 [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] wc_create_worker::jk_worker.c (154): about to validate and init titi [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] ajp_validate::jk_ajp_common.c (1794): worker titi contact is 'localhost:8009' [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] ajp_init::jk_ajp_common.c (1883): setting socket keepalive to 0 [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] ajp_init::jk_ajp_common.c (1922): setting socket timeout to -1 [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] ajp_init::jk_ajp_common.c (1926): setting socket buffer size to 0 [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] ajp_init::jk_ajp_common.c (1930): setting connection recycle timeout to 0 [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] ajp_init::jk_ajp_common.c (1934): setting cache timeout to 0 [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] ajp_init::jk_ajp_common.c (1938): setting connect timeout to 0 [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] ajp_init::jk_ajp_common.c (1942): setting reply timeout to 0 [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] ajp_init::jk_ajp_common.c (1946): setting prepost timeout to 0 [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] ajp_init::jk_ajp_common.c (1950): setting recovery opts to 0 [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] ajp_init::jk_ajp_common.c (1954): setting number of retries to 3 [Thu Jun 09 10:04:32 2005] [2408:2416] [debug] ajp_create_endpoint_cache::jk_ajp_common.c (1831): setting connection cache size
cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c
jfclere 2005/06/09 02:33:40
Modified:jni/java/org/apache/tomcat/jni BIOCallback.java
jni/native/src ssl.c
Log:
Change the BIOCallback interface to use write(byte[] buf) and
read(byte[] buf);
The buff is in the native encoding that allows to use it for both
stdio/stderri
redirection and for the sockets (JAVA or APR).
Revision ChangesPath
1.4 +7 -7
jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/BIOCallback.java
Index: BIOCallback.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/BIOCallback.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- BIOCallback.java 9 Jun 2005 09:13:54 - 1.3
+++ BIOCallback.java 9 Jun 2005 09:33:40 - 1.4
@@ -26,17 +26,17 @@
/**
* Write data
- * @param data String to write
- * @return Number of characters written
+ * @param buf containg the bytes to write.
+ * @return Number of characters written.
*/
-public int write(String data);
+public int write(byte [] buf);
/**
* Read data
- * @param len Maximum number of characters to read
- * @return String with up to len bytes readed
+ * @param buf buffer to store the read bytes.
+ * @return number of bytes read.
*/
-public String read(int len);
+public int read(byte [] buf);
/**
* Puts string
1.29 +19 -17jakarta-tomcat-connectors/jni/native/src/ssl.c
Index: ssl.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/ssl.c,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- ssl.c 9 Jun 2005 09:13:55 - 1.28
+++ ssl.c 9 Jun 2005 09:33:40 - 1.29
@@ -551,10 +551,12 @@
if (b-init in != NULL) {
BIO_JAVA *j = (BIO_JAVA *)b-ptr;
JNIEnv *e = j-cb.env;
-if ((*e)-CallIntMethod(e, j-cb.obj,
-j-cb.mid[0],
-tcn_new_string(e, in, inl)))
-ret = inl;
+jbyteArray jb = (*e)-NewByteArray(e, inl);
+(*e)-SetByteArrayRegion(e, jb, 0, inl, (jbyte *)in);
+jint o = (*e)-CallIntMethod(e, j-cb.obj,
+j-cb.mid[0], jb);
+(*e)-ReleaseByteArrayElements(e, jb, (jbyte *)in, 0);
+ret = o;
}
return ret;
}
@@ -565,16 +567,16 @@
if (b-init out != NULL) {
BIO_JAVA *j = (BIO_JAVA *)b-ptr;
JNIEnv *e = j-cb.env;
-jobject o;
-if ((o = (*e)-CallObjectMethod(e, j-cb.obj,
-j-cb.mid[1], (jint)(outl - 1 {
-TCN_ALLOC_CSTRING(o);
-if (J2S(o)) {
-int l = (int)strlen(J2S(o));
-ret = TCN_MIN(outl, l);
-memcpy(out, J2S(o), ret);
-}
-TCN_FREE_CSTRING(o);
+jbyteArray jb = (*e)-NewByteArray(e, outl);
+
+jint o = (*e)-CallObjectMethod(e, j-cb.obj,
+j-cb.mid[1], jb);
+if (o=0) {
+int i;
+jbyte *jout = (*e)-GetByteArrayElements(e, jb, 0);
+memcpy(out, jout, o);
+(*e)-ReleaseByteArrayElements(e, jb, jout, 0);
+ret = o;
}
}
return ret;
@@ -666,8 +668,8 @@
cls = (*e)-GetObjectClass(e, callback);
j-cb.env= e;
-j-cb.mid[0] = (*e)-GetMethodID(e, cls, write,
(Ljava/lang/String;)I);
-j-cb.mid[1] = (*e)-GetMethodID(e, cls, read,
(I)Ljava/lang/String;);
+j-cb.mid[0] = (*e)-GetMethodID(e, cls, write, ([B)I);
+j-cb.mid[1] = (*e)-GetMethodID(e, cls, read, ([B)I);
j-cb.mid[2] = (*e)-GetMethodID(e, cls, puts,
(Ljava/lang/String;)I);
j-cb.mid[3] = (*e)-GetMethodID(e, cls, gets,
(I)Ljava/lang/String;);
/* TODO: Check if method id's are valid */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35282] - Unable to use connector AJP on W2003 Server with IIS 6.0 and JBOSS 3.2.5
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35282. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35282 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|other |Windows Server 2003 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
Mladen Turk wrote: Bill Barker wrote: I am not 100% happy with the code. Mladen already asked me to rollback the changes. It looked OK to me. Basically it's the APR implementation of SSLEngine. Don't really see a problem. It does not, because it should fit inside the APR standard socket implementation. Having callbacks would actually make a thing way slower, because we would have to call the native, and from the native call the Java that would call back the native again. Well we just need a nativeBIO and a javaBIO. Of course, I don't really care about the APR-SSL Connector one way or the other. Since the config is the same as for mod_ssl, there is absolutely no reason to not simply use mod_ssl instead. If I just wanted the native-code optimizations, I'd use PureTLS instead. It's not an APR-SSL connector, but rather the SSL support for the APR connector. Since all that is optional feel free to just not use it :) 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: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
jean-frederic clere wrote: It does not, because it should fit inside the APR standard socket implementation. Having callbacks would actually make a thing way slower, because we would have to call the native, and from the native call the Java that would call back the native again. Well we just need a nativeBIO and a javaBIO. The plan is to use the: 1. apr_sock_accept/connect 2. obtain a os_sock 3. Make a BIO with os_sock_t 4. Use APR for socket_opt_set/socket_opt_get 5. Do a SSL_accept/SSL_connect 6. Make verify/handshake 7. use SSL_write/SSL_read for I/O. All that will use the poller and the pool cleanup. The Java part will go to the SSLSocket with the Socket API with specific read* and write* Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c
mturk 2005/06/09 03:24:53
Modified:jni/native/src ssl.c
Log:
Check for exceptions when allocating a new byte array.
Also use critial methods instead array copying.
On each call delete a local reference to the object so that
GC clears that ASAP.
Revision ChangesPath
1.30 +18 -17jakarta-tomcat-connectors/jni/native/src/ssl.c
Index: ssl.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/ssl.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- ssl.c 9 Jun 2005 09:33:40 - 1.29
+++ ssl.c 9 Jun 2005 10:24:53 - 1.30
@@ -547,36 +547,37 @@
static int jbs_write(BIO *b, const char *in, int inl)
{
-int ret = 0;
+jint ret = 0;
if (b-init in != NULL) {
BIO_JAVA *j = (BIO_JAVA *)b-ptr;
JNIEnv *e = j-cb.env;
jbyteArray jb = (*e)-NewByteArray(e, inl);
-(*e)-SetByteArrayRegion(e, jb, 0, inl, (jbyte *)in);
-jint o = (*e)-CallIntMethod(e, j-cb.obj,
-j-cb.mid[0], jb);
-(*e)-ReleaseByteArrayElements(e, jb, (jbyte *)in, 0);
-ret = o;
+if (!(*e)-ExceptionOccurred(e)) {
+(*e)-SetByteArrayRegion(e, jb, 0, inl, (jbyte *)in);
+ret = (*e)-CallIntMethod(e, j-cb.obj,
+ j-cb.mid[0], jb);
+(*e)-DeleteLocalRef(e, jb);
+}
}
return ret;
}
static int jbs_read(BIO *b, char *out, int outl)
{
-int ret = 0;
+jint ret = 0;
if (b-init out != NULL) {
BIO_JAVA *j = (BIO_JAVA *)b-ptr;
JNIEnv *e = j-cb.env;
jbyteArray jb = (*e)-NewByteArray(e, outl);
-
-jint o = (*e)-CallObjectMethod(e, j-cb.obj,
-j-cb.mid[1], jb);
-if (o=0) {
-int i;
-jbyte *jout = (*e)-GetByteArrayElements(e, jb, 0);
-memcpy(out, jout, o);
-(*e)-ReleaseByteArrayElements(e, jb, jout, 0);
-ret = o;
+if (!(*e)-ExceptionOccurred(e)) {
+ret = (*e)-CallIntMethod(e, j-cb.obj,
+ j-cb.mid[1], jb);
+if (ret 0) {
+jbyte *jout = (*e)-GetPrimitiveArrayCritical(e, jb, NULL);
+memcpy(out, jout, ret);
+(*e)-ReleasePrimitiveArrayCritical(e, jb, jout, 0);
+}
+(*e)-DeleteLocalRef(e, jb);
}
}
return ret;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src poll.c
mturk 2005/06/09 03:29:43 Modified:jni/native/src poll.c Log: Make sure the statistics are initialized to zero on creation. Revision ChangesPath 1.16 +2 -2 jakarta-tomcat-connectors/jni/native/src/poll.c Index: poll.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/poll.c,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- poll.c27 May 2005 16:39:13 - 1.15 +++ poll.c9 Jun 2005 10:29:43 - 1.16 @@ -119,7 +119,7 @@ TCN_THROW_IF_ERR(apr_pollset_create(pollset, (apr_uint32_t)size, p, f), pollset); } -tps = apr_palloc(p, sizeof(tcn_pollset_t)); +tps = apr_pcalloc(p, sizeof(tcn_pollset_t)); tps-pollset = pollset; tps-socket_set = apr_palloc(p, size * sizeof(apr_pollfd_t)); tps-socket_ttl = apr_palloc(p, size * sizeof(apr_interval_time_t)); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c
mturk 2005/06/09 03:44:06 Modified:jni/native/src ssl.c Log: Release the byte array elements with JNI_ABORT, because we are not interested in copying the data back from the write call. Revision ChangesPath 1.31 +2 -1 jakarta-tomcat-connectors/jni/native/src/ssl.c Index: ssl.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/ssl.c,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- ssl.c 9 Jun 2005 10:24:53 - 1.30 +++ ssl.c 9 Jun 2005 10:44:06 - 1.31 @@ -556,6 +556,7 @@ (*e)-SetByteArrayRegion(e, jb, 0, inl, (jbyte *)in); ret = (*e)-CallIntMethod(e, j-cb.obj, j-cb.mid[0], jb); +(*e)-ReleaseByteArrayElements(e, jb, (jbyte *)in, JNI_ABORT); (*e)-DeleteLocalRef(e, jb); } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35283] New: - jasper don't compile with a jdk1.5.0 code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35283. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35283 Summary: jasper don't compile with a jdk1.5.0 code Product: Tomcat 5 Version: 5.5.9 Platform: Sun OS/Version: Solaris Status: NEW Severity: major Priority: P1 Component: Jasper AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] hello..I'm triing to compile a jsp using the jdk1.5.0 features and I seems that it works as a jdk1.4 compiler. In a jsp using this code: % Integer i=0; % I have: 11:27:35,095 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: 22 in the jsp file: /pages/TablePre.jsp Generated servlet error: Type mismatch: cannot convert from int to Integer An error occurred at line: 25 in the jsp file: /pages/TablePre.jsp Generated servlet error: Type mismatch: cannot convert from Integer to int at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:84) at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:328) at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:397) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:288) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:267) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:255) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:556) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:293) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252 ) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:966) at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:604) at org.apache.struts.tiles.TilesUtilImpl.doInclude(TilesUtilImpl.java:101) at org.apache.struts.tiles.TilesUtil.doInclude(TilesUtil.java:137) at org.apache.struts.taglib.tiles.InsertTag.doInclude(InsertTag.java:758) at org.apache.struts.taglib.tiles.InsertTag$InsertHandler.doEndTag(InsertTag.java:890) at org.apache.struts.taglib.tiles.InsertTag.doEndTag(InsertTag.java:460) at org.apache.jsp.pages.Table_jsp._jspx_meth_tiles_get_2(org.apache.jsp.pages.Table_jsp:221) at org.apache.jsp.pages.Table_jsp._jspx_meth_html_html_0(org.apache.jsp.pages.Table_jsp:132) at org.apache.jsp.pages.Table_jsp._jspService(org.apache.jsp.pages.Table_jsp:73) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252 ) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1056) at org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:261) at org.apache.struts.tiles.TilesRequestProcessor.processTilesDefinition(TilesRequestProcessor.java: 237) at
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
Mladen Turk wrote: jean-frederic clere wrote: It does not, because it should fit inside the APR standard socket implementation. Having callbacks would actually make a thing way slower, because we would have to call the native, and from the native call the Java that would call back the native again. Well we just need a nativeBIO and a javaBIO. The plan is to use the: 1. apr_sock_accept/connect 2. obtain a os_sock 3. Make a BIO with os_sock_t 4. Use APR for socket_opt_set/socket_opt_get 5. Do a SSL_accept/SSL_connect 6. Make verify/handshake 7. use SSL_write/SSL_read for I/O. All that will use the poller and the pool cleanup. The Java part will go to the SSLSocket with the Socket API with specific read* and write* OK, I will create a SSLBIO.java/sslbio.c to go on testing/experimenting using with the BIOCallback, the interest there is to use an hardware accelator with openssl. 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]
DO NOT REPLY [Bug 35283] - jasper don't compile with a jdk1.5.0 code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35283. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35283 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-06-09 13:11 --- I have not tried it myself, but see: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html and a work through here http://forum.java.sun.com/thread.jspa?threadID=579806messageID=3044385 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src error.c network.c poll.c
mturk 2005/06/09 04:13:40
Modified:jni/java/org/apache/tomcat/jni Status.java
jni/native/include tcn.h
jni/native/src error.c network.c poll.c
Log:
Use user errors for TIMEUP and EAGAIN.
This way we'll be able to save an extra JNI call on each poll
or sendfile.
Revision ChangesPath
1.7 +4 -1
jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Status.java
Index: Status.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Status.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Status.java 19 Apr 2005 16:32:11 - 1.6
+++ Status.java 9 Jun 2005 11:13:40 - 1.7
@@ -175,6 +175,9 @@
public static final int APR_EMISMATCH = (APR_OS_START_STATUS + 24);
public static final int APR_EBUSY = (APR_OS_START_STATUS + 25);
+public static final int TIMEUP= (APR_OS_START_USERERR + 1);
+public static final int EAGAIN= (APR_OS_START_USERERR + 2);
+
private static native boolean is(int err, int idx);
/**
* APR_STATUS_IS Status Value Tests
1.14 +4 -1 jakarta-tomcat-connectors/jni/native/include/tcn.h
Index: tcn.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/include/tcn.h,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- tcn.h 8 Jun 2005 07:16:33 - 1.13
+++ tcn.h 9 Jun 2005 11:13:40 - 1.14
@@ -39,6 +39,9 @@
#define APR_MAX_IOVEC_SIZE 1024
#endif
+#define TCN_TIMEUP APR_OS_START_USERERR + 1
+#define TCN_EAGAIN APR_OS_START_USERERR + 2
+
#define TCN_CLASS_PATH org/apache/tomcat/jni/
#define TCN_FINFO_CLASS TCN_CLASS_PATH FileInfo
#define TCN_AINFO_CLASS TCN_CLASS_PATH Sockaddr
1.11 +9 -3 jakarta-tomcat-connectors/jni/native/src/error.c
Index: error.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/error.c,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- error.c 7 Jun 2005 10:08:08 - 1.10
+++ error.c 9 Jun 2005 11:13:40 - 1.11
@@ -173,7 +173,10 @@
APR_IS(54, APR_STATUS_IS_NOTDETACH);
APR_IS(55, APR_STATUS_IS_CHILD_DONE);
APR_IS(56, APR_STATUS_IS_CHILD_NOTDONE);
-APR_IS(57, APR_STATUS_IS_TIMEUP);
+case 57:
+if (APR_STATUS_IS_TIMEUP(err) || err == TCN_TIMEUP)
+return JNI_TRUE;
+break;
APR_IS(58, APR_STATUS_IS_INCOMPLETE);
/* empty slot: +9 */
/* empty slot: +10 */
@@ -193,7 +196,10 @@
APR_IS(74, APR_STATUS_IS_EMISMATCH);
APR_IS(75, APR_STATUS_IS_EBUSY);
/* Socket errors */
-APR_IS(90, APR_STATUS_IS_EAGAIN);
+case 90:
+if (APR_STATUS_IS_EAGAIN(err) || err == TCN_EAGAIN)
+return JNI_TRUE;
+break;
APR_IS(91, TCN_STATUS_IS_ETIMEDOUT);
APR_IS(92, APR_STATUS_IS_ECONNABORTED);
APR_IS(93, APR_STATUS_IS_ECONNRESET);
1.24 +41 -11jakarta-tomcat-connectors/jni/native/src/network.c
Index: network.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/network.c,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- network.c 30 May 2005 06:15:52 - 1.23
+++ network.c 9 Jun 2005 11:13:40 - 1.24
@@ -291,8 +291,11 @@
(*e)-ReleaseByteArrayElements(e, buf, bytes, JNI_ABORT);
if (ss == APR_SUCCESS)
return (jint)nbytes;
-else
+else {
+if (APR_STATUS_IS_EAGAIN(ss))
+ss = TCN_EAGAIN;
return -(jint)ss;
+}
}
TCN_IMPLEMENT_CALL(jint, Socket, sendb)(TCN_STDARGS, jlong sock,
@@ -311,8 +314,11 @@
if (ss == APR_SUCCESS)
return (jint)nbytes;
-else
+else {
+if (APR_STATUS_IS_EAGAIN(ss))
+ss = TCN_EAGAIN;
return -(jint)ss;
+}
}
TCN_IMPLEMENT_CALL(jint, Socket, sendv)(TCN_STDARGS, jlong sock,
@@ -344,8 +350,11 @@
}
if (ss == APR_SUCCESS)
return (jint)written;
-else
+else {
+if (APR_STATUS_IS_EAGAIN(ss))
+ss = TCN_EAGAIN;
return -(jint)ss;
+}
}
TCN_IMPLEMENT_CALL(jint, Socket, sendto)(TCN_STDARGS, jlong sock,
@@ -376,8 +385,11 @@
(*e)-ReleaseByteArrayElements(e, buf, bytes, JNI_ABORT);
if (ss == APR_SUCCESS)
return (jint)nbytes;
-else
+
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
jean-frederic clere wrote: OK, I will create a SSLBIO.java/sslbio.c to go on testing/experimenting using with the BIOCallback, the interest there is to use an hardware accelator with openssl. Please, can you give me a day to finish initial implementation. Hardware accelerator is used by default on SSL.initialize(egineName) Once again, can you hold up with adding new files? Thanks, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat connector
Hi Bill, You sent this a while back, and I have to pick it up again. Would you be able to explain how this would all hook together - are you saying that Apache could load-balance the request (non-HTTP) and our extension of JkHandler could handle the request? cheers, David - Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Tuesday, March 22, 2005 8:16 AM Subject: Re: tomcat connector Wow, didn't know this was possible! This will be perfect for us...except that we need to go through Apache mod_jk to load-balance requests as they come in, BEFORE they reach tomcat. Please tell me there is a way to do this?! (and how?!) It might be easier in this case to extend JkHandler http://jakarta.apache.org/tomcat/tomcat-5.5-doc/catalina/docs/api/org/apache /jk/core/JkHandler.html, and implement the invoke method. Then you can insert it into the Handler chain via something like: class.myhandler=com.myfirm.mypackage.MyHandler request.next=myhandler myhandler.next=container # any other properties that your Handler needs to be set |-+ | | Bill Barker| | | [EMAIL PROTECTED]| | | .com| | || | | 03/21/2005 03:30 | | | PM | | | Please respond to| | | Tomcat | | | Developers List | | || |-+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35289] - [PATCH] - Allow a redirect parameter in the Form_Authentication
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35289. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35289 --- Additional Comments From [EMAIL PROTECTED] 2005-06-09 17:06 --- Created an attachment (id=15352) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15352action=view) An implementation of the RFE -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PayPal Account Security Measures
I did not make any transactions on my Paypal account. Please cancel... marie [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: You have recieve this email because you or someone had tried to used your paypal account at http://www.springbok-computers.co.uk Below is the details about the transaction made: Transaction site : http://www.springbok-computers.co.uk Order ID : FMO17436466 Amount : $263 Date : Wednesday, Jun 08 To confirm or decline this transaction, please follow the link provide below. Please save the fraud alert id for your reference. http://www.paypal-confirmation%2Did-0746795.com If we do not get the confirmation within 5 business days, your account will be suspended until further notice. Sincerely, The PayPal Security Team PROTECT YOUR PASSWORD NEVER give your password to anyone and ONLY log in at https://www.paypal.com/. Protect yourself against fraudulent websites by opening a new web browser (e.g. Internet Explorer or Netscape) and typing in the PayPal URL every time you log in to your account. Please do not reply to this email. This mailbox is not monitored and you will not receive a response. For assistance, log in to your PayPal account and click the Help link located in the top right corner of any PayPal page. PayPal Alert ID : 0746795 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35289] New: - [PATCH] - Allow a redirect parameter in the Form_Authentication
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35289. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35289 Summary: [PATCH] - Allow a redirect parameter in the Form_Authentication Product: Tomcat 5 Version: 5.0.30 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The problem I have found with the currenct implementation is that you must hit a protected resource before reaching a login box. How can we allow a login box on any page that will use j_security as the form action and still allow the FormAuthenticator object to know where to redirect the page? A solution is to add a hidden parameter to the login form that tells the FormAuthenticator where to go next. Here is a simple patch I am using until a more permenent solution is found. --- FormAuthenticator.java.New 2005-06-09 10:32:33.21875 -0400 +++ FormAuthenticator.java 2005-06-09 10:53:25.59375 -0400 @@ -267,10 +267,7 @@ // Redirect the user to the original request URI (which will cause // the original request to be restored) -String redirectURI = hreq.getParameter(j_security_redirect); requestURI = savedRequestURL(session); -if (redirectURI != null ) -requestURI = redirectURI; if (log.isDebugEnabled()) log.debug(Redirecting to original ' + requestURI + '); if (requestURI == null) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/coyote - New directory
remm2005/06/09 09:14:47 jakarta-tomcat-connectors/jk/java/org/apache/coyote - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/coyote/ajp - New directory
remm2005/06/09 09:14:47 jakarta-tomcat-connectors/jk/java/org/apache/coyote/ajp - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
May Chun Chew/FEA/PEC is out of the office.
I will be out of the office starting 06/10/2005 and will not return until 06/20/2005. I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java
pero2005/06/09 13:24:25
Modified:catalina/src/share/org/apache/catalina/connector
Connector.java
Log:
Fix duplicate createObjectName from Mapper
Revision ChangesPath
1.25 +2 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java
Index: Connector.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- Connector.java6 Jun 2005 21:31:19 - 1.24
+++ Connector.java9 Jun 2005 20:24:25 - 1.25
@@ -1113,7 +1113,7 @@
log.debug(sm.getString(
coyoteConnector.MapperRegistration,
mapperOname));
Registry.getRegistry(null, null).registerComponent
-(mapper, createObjectName(this.domain,Mapper),
Mapper);
+(mapper, mapperOname, Mapper);
} catch (Exception ex) {
log.error(sm.getString
(coyoteConnector.protocolRegistrationFailed), ex);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs/config http.xml
pero2005/06/09 13:25:31 Modified:webapps/docs/config http.xml Log: Fix Typo! Revision ChangesPath 1.26 +1 -1 jakarta-tomcat-catalina/webapps/docs/config/http.xml Index: http.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/http.xml,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- http.xml 4 Jun 2005 17:34:23 - 1.25 +++ http.xml 9 Jun 2005 20:25:31 - 1.26 @@ -169,7 +169,7 @@ attribute name=xpoweredBy required=false pSet this attribute to codetrue/code to cause Tomcat to advertise - support for the Srevlet specification using the header recommended in the + support for the Servlet specification using the header recommended in the specification. The default value is codefalse/code./p /attribute - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35297] New: - [PATCH] Chunked transfer encoding for IIS JK/ISAPI
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35297. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35297 Summary: [PATCH] Chunked transfer encoding for IIS JK/ISAPI Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] This patch adds chunked encoding for IIS responses - i.e. Transfer-Encoding: chunked responses for HTTP/1.1 clients - allowing IIS to maintain persistent connections to HTTP/1.1 clients through the ISAPI redirector. IIS hands a lot of the responsibility for HTTP protocol handling to the ISAPI extension - Apache is sooo much nicer to deal with. IIS will keep connections alive if there is a Content-Length specified in the request, but won't do transfer encoding for requests that don't like Apache does. Contents of the patch: - Added 'enable_chunked_encoding' param (bool) to enable chunked encoding (default is disabled) - Modified isapi_private_data_t to track whether chunked encoding is enabled per request - Modified start_response to: - Detect HTTP 1.1 clients and enable chunked encoding for the response (if the Tomcat response hasn't already precluded that) - Determine whether IIS should be told to keep the connection alive (IIS makes us manage this as well if we want to have the ability to keep connections) - Set the Transfer-Encoding: chunked header when used - Use the HSE_SEND_HEADER_EX_INFO/ServerSupportFunction API to allow us to tell IIS to keep the connections open - Factored the WriteClient calls into a new function (for the new write()) - Added support in write() for writing a chunked encoded response chunk - Added a flush hook for IIS (with flush_packets false) to allow the chunked encoded terminator (the 0 chunk) to be written on response completion I'd consider the chunked encoding experimental at the moment - we're beta testing at the moment - which is why it's disabled by default. We've run this against fairly complex web applications, with a mix of jsp, htm, xml, Content-Length, no Content-Length and some Connection: close behaviour, IE, Firefox etc. All seems to work fine at the moment - chunked encoding isn't that complex - though IE does get confused if there are non-chunk-encoded files in the cache. The only reported failure is when using Fiddler with an HTTP/1.0 client, though I suspect this is Fiddlers problem (it can't handle 1.0 to the unpatched connector). Straight HTTP/1.0 from IE works fine. It'd be great to get this into the codebase and have people beta test it to see if if any problems show up. Any problems are likely to be the result of incorrect negotiation of keep-alive or incorrect detection of responses from Tomcat that preclude using chunked encoding. cheers tim -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster/clusterbase - New directory
pero2005/06/09 13:31:03 jakarta-tomcat-catalina/modules/cluster/clusterbase - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster/clusterbase/webapps/myapps - New directory
pero2005/06/09 13:31:14 jakarta-tomcat-catalina/modules/cluster/clusterbase/webapps/myapps - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster/clusterbase/webapps - New directory
pero2005/06/09 13:31:09 jakarta-tomcat-catalina/modules/cluster/clusterbase/webapps - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster/clusterbase/webapps/myapps/WEB-INF/classes - New directory
pero2005/06/09 13:31:25 jakarta-tomcat-catalina/modules/cluster/clusterbase/webapps/myapps/WEB-INF/classes - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster/test/src/share/org/apache/catalina/cluster/mcast - New directory
pero2005/06/09 13:31:36 jakarta-tomcat-catalina/modules/cluster/test/src/share/org/apache/catalina/cluster/mcast - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster/clusterbase/webapps/myapps/WEB-INF/classes/mypackage - New directory
pero2005/06/09 13:31:30 jakarta-tomcat-catalina/modules/cluster/clusterbase/webapps/myapps/WEB-INF/classes/mypackage - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35297] - [PATCH] Chunked transfer encoding for IIS JK/ISAPI
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35297. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35297 --- Additional Comments From [EMAIL PROTECTED] 2005-06-09 22:33 --- Created an attachment (id=15357) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15357action=view) Chunked encoding patch for JK/ISAPI Patch against jk_isapi_plugin.c r1.49 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33739] - 5.5 Docs missing CATALINA_BASE info formerly in RUNNING.txt
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33739 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2005-06-09 22:13 --- This is still NOT clear at all, and the reason is simple to fix -- the Release Notes state : Make sure to read the RUNNING.txt file in this directory if you are using J2SE 1.4. but the directory structure of the archives does not match that of all the directories from which the Release Notes are visible. It would eliminate confusion if the phrase in this directory were changed to: in the fulldocs downloadable file(s). In my opinion this is not worth re-opening the bug, except to correct this confusion for all future users. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster/clusterbase/webapps/myapps/WEB-INF - New directory
pero2005/06/09 13:31:19 jakarta-tomcat-catalina/modules/cluster/clusterbase/webapps/myapps/WEB-INF - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml cluster-howto.xml
pero2005/06/09 13:38:30 Modified:webapps/docs changelog.xml cluster-howto.xml Log: - Cluster ping now transfer cluster domain information and DeltaManager only send and receive message from same domain members - JMX Support for McastService (Membership) Revision ChangesPath 1.315 +7 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.314 retrieving revision 1.315 diff -u -r1.314 -r1.315 --- changelog.xml 6 Jun 2005 21:31:19 - 1.314 +++ changelog.xml 9 Jun 2005 20:38:30 - 1.315 @@ -221,6 +221,13 @@ subsection name=Cluster changelog add +Cluster ping now transfer cluster domain information and DeltaManager only +send and receive message from same domain members (pero) + /add + add +JMX Support for McastService (Membership) (pero) + /add + add Redesign SimpleTcpCluster message receiving to ClusterReceiverBase (pero) /add add 1.7 +149 -15 jakarta-tomcat-catalina/webapps/docs/cluster-howto.xml Index: cluster-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/cluster-howto.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- cluster-howto.xml 29 Apr 2005 20:14:58 - 1.6 +++ cluster-howto.xml 9 Jun 2005 20:38:30 - 1.7 @@ -212,17 +212,42 @@ pComponent Levels: source -Server - | -Service - | -Engine - / \ - Cluster ReplicationValve - | - Manager - | - Session + Server + | + Service + | + Engine + | + Host + | + -- +/ \ + ClusterContext(1-N) +| \ +| -- Manager +| \ +| -- DeltaManager +| + --- + || | \ + Sender Receiver Membership \ + -- Valve + | \ + | -- ReplicationValve + | -- JvmRouteBinderValve + | + -- LifecycleListener + | + -- ClusterListener + | \ + | -- ClusterSessionListener + | -- JvmRouteSessionIDBinderListener + | + -- Deployer +\ + -- FarmWarDeployer + + /source/p @@ -287,7 +312,9 @@ tr tdprocessSenderFrequency/td -td/td +tdControl the sender keepalive status and drop sender socket connection after timeout is reached. +Check every processSenderFrequency value engine background ticks. +/td tdcode2/code/td /tr @@ -573,8 +600,95 @@ /p /section +section name=Cluster Configuration for ReplicationTransmitter ( DeltaManager Attribute) +p +List of Attributesbr/ +table border=1 cellpadding=5 + + tr +th align=center bgcolor=aquaAttribute/th +th align=center bgcolor=aquaDescription/th +th align=center bgcolor=aquaDefault value/th + /tr + + tr +tdexpireSessionsOnShutdown/td +tdWhen server stopped, expire all sessions also at backup nodes (only for testing)/td +tdcodefalse/code/td + /tr + + tr +tdmaxActiveSessions/td +tdNumber of active sessions. (Default is no limit)/td +tdcode-1/code/td + /tr + + tr +tdnotifyListenersOnReplication/td +tdNotify application session listener to session creation +and expiring events at backup nodes/td +tdcodetrue/code/td + /tr + + tr +tdnotifySessionListenersOnReplication/td +tdNotify application session listener to attribute changes at backup nodes/td +tdcodetrue/code/td + /tr + + tr +tdstateTransferTimeout/td +tdTimeout that session state transfer is complete/td +tdcode60/code/td + /tr + + tr +tdsendAllSessions/td +tdFlag to send sessions as splited blocks/td +tdcodetrue/code/td + /tr + + tr +tdsendAllSessionsSize/td +tdNumber
cvs commit: jakarta-tomcat-catalina/webapps/docs cluster-howto.xml
pero2005/06/09 13:42:55
Modified:webapps/docs cluster-howto.xml
Log:
Fix!
Revision ChangesPath
1.8 +3 -3 jakarta-tomcat-catalina/webapps/docs/cluster-howto.xml
Index: cluster-howto.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/cluster-howto.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- cluster-howto.xml 9 Jun 2005 20:38:30 - 1.7
+++ cluster-howto.xml 9 Jun 2005 20:42:55 - 1.8
@@ -730,19 +730,19 @@
tr
tdClusterSender/td
-tdConfiguration and stats of the sender infrastractur/td
+tdConfiguration and stats of the sender infrastructure/td
tdcodetype=ClusterSender,host=${HOST}/code/td
/tr
tr
tdClusterReceiver/td
-tdConfiguration and stats of the recevier infrastractur/td
+tdConfiguration and stats of the recevier infrastructure/td
tdcodetype=ClusterReceiver,host=${HOST}/code/td
/tr
tr
tdClusterMembership/td
-tdConfiguration and stats of the membership infrastractur/td
+tdConfiguration and stats of the membership infrastructure/td
tdcodetype=ClusterMembership,host=${HOST}/code/td
/tr
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33739] - 5.5 Docs missing CATALINA_BASE info formerly in RUNNING.txt
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33739 [EMAIL PROTECTED] changed: What|Removed |Added Severity|minor |enhancement -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35298] New: - Multiple JK/ISAPI redirectors on a single IIS site are not supported
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35298. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35298 Summary: Multiple JK/ISAPI redirectors on a single IIS site are not supported Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: major Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The current JK/ISAPI redirector uses 4 special headers to pass redirector information from the FilterProc to the ExtensionProc. These are cleared in the FilterProc prior to attempting a match on the incoming URL. Since IIS passes requests through all the filters, any JK/ISAPI redirector in the ISAPI Filters stack that is below the matching redirector will cause the headers to be cleared and the request to fail. A common deployment scenario for our products is to use a single web customer website (running on port 80) with multiple virtual directories and ISAPI redirectors - one for each product in the deployed solution. I'm aware that the mod_jk config is geared towards a single redirectory with a single config file, but even our Apache sites use multiple virtual hosts with separate mod_jk configs. It's not immediately obvious if there's actually a benefit in clearing the headers. If someone wanted to spoof these, then they could talk directly to the ExtensionProc anyway, and you can ensure they're set correctly just by being careful in the FilterProc. The offending lines in jk_isapi_plugin.c r1.49, lines 749..755 /* * Just in case somebody set these headers in the request! */ SetHeader(pfc, URI_HEADER_NAME, NULL); SetHeader(pfc, QUERY_HEADER_NAME, NULL); SetHeader(pfc, WORKER_HEADER_NAME, NULL); SetHeader(pfc, TOMCAT_TRANSLATE_HEADER_NAME, NULL); We've used two solutions to this successfully in internal builds: 1. Don't clear the headers 2. Unique URI_HEADER_NAME et al during the redirector load i.e. using the extension_uri or the DLL process ID. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35299] New: - JK/ISAPI documentation does not explain isapi_redirect.properties
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35299. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35299 Summary: JK/ISAPI documentation does not explain isapi_redirect.properties Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Windows Server 2003 Status: NEW Severity: normal Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Configuration of the ISAPI redirector using isapi_redirect.properties is the preferred method of configuration for many sites as it allows: - Non registry based config - Multiple redirector configurations per server machine/IIS (currently one per website) Using the properties file for config is not documented in any of the Tomcat docs, leading many people to think that this support has been dropped. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35300] New: - Thread pool expands when many threads are idle
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35300.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35300
Summary: Thread pool expands when many threads are idle
Product: Tomcat 5
Version: 5.0.28
Platform: All
OS/Version: other
Status: NEW
Severity: normal
Priority: P5
Component: Connector:HTTP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
In our production environment, tomcat connector thread pool expands even when
all the threads are not in use. We have configured server.xml with 150 threads.
!-- A HTTP/1.1 Connector on port 8080 --
Connector port=8080 address=${jboss.bind.address}
maxThreads=300 minSpareThreads=150 maxSpareThreads=200
enableLookups=false redirectPort=8443 acceptCount=100
connectionTimeout=6 disableUploadTimeout=true
bufferSize=8192 /
Is there any reason to increase threads in the pool when many of the threads
are idle? Please see attached thread dump.
Thanks
Purush
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35300] - Thread pool expands when many threads are idle
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35300. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35300 --- Additional Comments From [EMAIL PROTECTED] 2005-06-09 23:48 --- Created an attachment (id=15360) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15360action=view) Thread dump -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35302] New: - [PATCH] error page redirection for JK/ISAPI on service fail
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35302. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35302 Summary: [PATCH] error page redirection for JK/ISAPI on service fail Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: Windows Server 2003 Status: NEW Severity: enhancement Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] When a service fails in the ISAPI ExtensionProc, IIS just drops the connection. The behaviour then differs between browsers - IE shows a generic 'Unable to connect to server' page, Firefox displays a blank window. It is desirable for many of our clients to be able to tell the user what is going on, and point them in the direction of technical support. This patch adds the ability to configure an error page to use when the endpoint service in ExtensionProc fails. The error page is a URL (absolute or relative) that is sent as a 302 to the client when the service fails. Contents of the patch: - Added a new optional error_page configuration property for the ISAPI redirector - Added a buffer for the page URL and a pointer that serves as a flag (i.e. if it's NULL there is no error page, otherwise it points to the buffer) - Modified ExtensionProc to send the redirect on service failure -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35302] - [PATCH] error page redirection for JK/ISAPI on service fail
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35302. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35302 --- Additional Comments From [EMAIL PROTECTED] 2005-06-10 00:31 --- Created an attachment (id=15361) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15361action=view) Error page support for ISAPI redirector Patch against jk_isapi_plugin.c r1.49 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35303] New: - Response flushing callbacks uninitialised
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35303. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35303 Summary: Response flushing callbacks uninitialised Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The two fields of jk_ws_service_t added for response flushing (flush and flush_packets) are not initialised for all connectors - currently only the Apache 1.3 ans 2.0 connectors. This results in their use in the AJP callbacks in jk_ajp_common.c potentially accessing unitialised data - this is the case when the ISAPI redirector is used. The fix is to initialise the two fields in jk_init_ws_service. Patch against r1.49 is attached. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35303] - Response flushing callbacks uninitialised
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35303. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35303 --- Additional Comments From [EMAIL PROTECTED] 2005-06-10 00:37 --- Created an attachment (id=15362) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15362action=view) Flush parameter initialisation Patch against jk_util.c r1.69 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35302] - [PATCH] error page redirection for JK/ISAPI on service fail
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35302.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35302
--- Additional Comments From [EMAIL PROTECTED] 2005-06-10 01:25 ---
(From update of attachment 15361)
Index: jk/native/iis/jk_isapi_plugin.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c,v
retrieving revision 1.49
diff -u -r1.49 jk_isapi_plugin.c
--- jk/native/iis/jk_isapi_plugin.c 18 May 2005 18:04:53 - 1.49
+++ jk/native/iis/jk_isapi_plugin.c 9 Jun 2005 23:21:35 -
@@ -20,6 +20,7 @@
* Author: Larry Isaacs [EMAIL PROTECTED] *
* Author: Ignacio J. Ortega [EMAIL PROTECTED] *
* Author: Mladen Turk [EMAIL PROTECTED]*
+ * Author: Tim Whittington [EMAIL PROTECTED]*
* Version: $Revision: 1.49 $ *
***/
@@ -69,6 +70,8 @@
#define URI_SELECT_UNPARSED_VERB(unparsed)
#define URI_SELECT_ESCAPED_VERB (escaped)
+#define ERROR_PAGE_TAG (error_page)
+
#define BAD_REQUEST -1
#define BAD_PATH-2
#define MAX_SERVERNAME 128
@@ -133,6 +136,8 @@
static int log_level = JK_LOG_EMERG_LEVEL;
static char worker_file[MAX_PATH * 2];
static char worker_mount_file[MAX_PATH * 2] = {0};
+static char error_page_buf[INTERNET_MAX_URL_LENGTH] = {0};
+static char *error_page = NULL;
#define URI_SELECT_OPT_PARSED 0
#define URI_SELECT_OPT_UNPARSED 1
@@ -1017,9 +1022,26 @@
service() returned OK);
}
else {
-lpEcb-dwHttpStatusCode = is_error;
jk_log(logger, JK_LOG_ERROR,
service() failed);
+
+/** Try to redirect the client to a page explaining
the ISAPI redirector is down */
+if (error_page) {
+int len_of_error_page = strlen(error_page);
+if (!lpEcb-ServerSupportFunction(lpEcb-ConnID,
+
HSE_REQ_SEND_URL_REDIRECT_RESP,
+ error_page,
+
(LPDWORD)len_of_error_page,
+ (LPDWORD)NULL))
{
+jk_log(logger, JK_LOG_ERROR,
+HttpExtensionProc error, Error page
redirect failed\n);
+lpEcb-dwHttpStatusCode = is_error;
+}
+}
+else {
+lpEcb-dwHttpStatusCode = is_error;
+}
+
}
e-done(e, logger);
}
@@ -1139,6 +1161,9 @@
jk_log(logger, JK_LOG_DEBUG, Using worker mount file %s.,
worker_mount_file);
jk_log(logger, JK_LOG_DEBUG, Using uri select %d.,
uri_select_option);
+if (error_page) {
+jk_log(logger, JK_LOG_DEBUG, Using error page '%s'.\n,
error_page);
+}
}
if (uri_worker_map_alloc(uw_map, NULL, logger)) {
rc = JK_FALSE;
@@ -1256,7 +1281,11 @@
ok = JK_FALSE;
}
}
-
+tmp = jk_map_get_string(map, ERROR_PAGE_TAG, NULL);
+if (tmp) {
+strcpy(error_page_buf, tmp);
+error_page = error_page_buf;
+}
}
else {
rc = RegOpenKeyEx(HKEY_LOCAL_MACHINE,
@@ -1322,6 +1351,12 @@
ok = JK_FALSE;
}
}
+if (get_registry_config_parameter(hkey,
+ ERROR_PAGE_TAG,
+ tmpbuf, sizeof(tmpbuf))) {
+strcpy(error_page_buf, tmpbuf);
+error_page = error_page_buf;
+}
RegCloseKey(hkey);
}
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer of code - next steps?
For those interested in Summer of code what do we need to do next? Is having the Wiki up to date enough? And we sit back while participants submit their proposals and Google chooses whom will get the stipend, while the folks listed on the Wiki mentor? http://code.google.com/soc_application.html -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk glitches
I hope that the below snapshot of my jkstatus shows up okay. This is from my current setup using mod_jk 1.2.13 and using the method=Traffic setting. What's not obvious from this static snapshot is that the middle webserver (webl6) is currently getting all requests. This is in spite of the fact that the 4th server shows 28 busy connections... don't believe it, it's not getting any connections. The only webserver getting requests of the 5 is the middle one. I don't know how that happened but it appears that the Rd (bytes read) got reset so in order to balance things out it is now sending everything to the one server. At first I thought maybe it was because transferred, readed (sic) and mytraffic are size_t and maybe one of them rolled over. But that would rollover at 4MB right? Since I'm not fluent in this code, maybe someone who is could comment. From my cursory look, it appears there might be a couple of issues here: 1. Relying on total bytes (requests) can lead to situations where all requests go to a single worker if one of counters gets messed up. Perhaps it would be more reliable to keep a moving average instead which might only temporarily disrupt normal operations. 2. Based on the Busy counts being incorrect, there doesn't appear to be any semaphore locking of the shared memory. Could that be why the Rd value got reset? ~Tom Worker Status for loadbalance Type Sticky session Force Sticky session Retries Method Lock lb True False 3 Traffic Optimistic Name Type Host Addr Stat F V Acc Err Wr Rd Busy Max RR Cd webl7 ajp13 webl7:8009 172.18.7.100:8009 OK 100 100 495464 242 239M 2.4G 1 41 webl4 ajp13 webl4:8009 172.18.4.100:8009 OK 130 130 648407 368 312M 3.1G 1 50 webl6 ajp13 webl6:8009 172.18.6.100:8009 OK 169 169 1056555 305 507M 1.1G 7 56 webl8 ajp13 webl8:8009 172.18.8.100:8009 OK 220 220 4163167 1662 2.0G 3.8G 28 109 webl5 ajp13 webl5:8009 172.18.5.100:8009 OK 25 25 124571 53 60M 606M 1 19
Re: mod_jk glitches
It didn't paste as well as I'd hoped... the relevant information, formatted in text is: NameFAccWrRdBusyMax webl7100495464 239M 2.4G 1 41 webl4130648407 312M 3.1G 1 50 webl6169 1056555 507M 1.1G 7 56 now getting ALL requests webl8220 41631672.0G 3.8G 28 109 webl5 25 12457160M 606M 1 19 Where the headings come from the status tool: NameWorker route name FLoad Balancer Factor AccNumber of requests Wr Number of bytes transferred Rd Number of bytes read Busy Current number of busy connections Max Maximum number of busy connections Hoping this time it's readable... On Jun 9, 2005, at 8:13 PM, Tom Anderson wrote: I hope that the below snapshot of my jkstatus shows up okay. This is from my current setup using mod_jk 1.2.13 and using the method=Traffic setting. What's not obvious from this static snapshot is that the middle webserver (webl6) is currently getting all requests. This is in spite of the fact that the 4th server shows 28 busy connections... don't believe it, it's not getting any connections. The only webserver getting requests of the 5 is the middle one. I don't know how that happened but it appears that the Rd (bytes read) got reset so in order to balance things out it is now sending everything to the one server. At first I thought maybe it was because transferred, readed (sic) and mytraffic are size_t and maybe one of them rolled over. But that would rollover at 4MB right? Since I'm not fluent in this code, maybe someone who is could comment. From my cursory look, it appears there might be a couple of issues here: 1. Relying on total bytes (requests) can lead to situations where all requests go to a single worker if one of counters gets messed up. Perhaps it would be more reliable to keep a moving average instead which might only temporarily disrupt normal operations. 2. Based on the Busy counts being incorrect, there doesn't appear to be any semaphore locking of the shared memory. Could that be why the Rd value got reset? ~Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35303] - Response flushing callbacks uninitialised
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35303. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35303 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-06-10 05:24 --- This is actually incorrect. MLR on my part. It'd probably still be more robust if these were inited in jk_init_ws_service. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/coyote/ajp AjpAprProcessor.java Constants.java LocalStrings.properties AjpAprProtocol.java AjpMessage.java
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 09, 2005 9:14 AM Subject: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/coyote/ajp AjpAprProcessor.java Constants.java LocalStrings.properties AjpAprProtocol.java AjpMessage.java remm2005/06/09 09:14:51 Added: jk/java/org/apache/coyote/ajp AjpAprProcessor.java Constants.java LocalStrings.properties AjpAprProtocol.java AjpMessage.java Log: - Add my WIP AJP implementation using APR. Performance sucks right now, and I think it has lots of bugs ;) - It won't be compiled in or used for now. Yeah, it has a few bugs ;). Would it mess you up if I were to fix some of the more glaring ones in the CVS copy? I'm thinking mostly of the double call to endRequest, and the failure to clean up the Request body parameters. The handling of remote/localHost/Port is also wrong, but relatively harmless. Also the lack of C2B handling on the Response headers is going to bite you someday, but for initial testing on a iso-8859-1 machine it's alright. 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: mod_jk glitches
I should have trusted my instincts and not my math. A size_t (32 bits on most machines) rolls over at 4 GB, not 4 MB... d'oh! So this falls apart under a decent load, after a day or two in my case. I guess I'll be going back to the request method. For me, that should last about 1000 days before rolling over. I suggest that maybe doubles would be better for the read/write bytes. Although I still prefer a model that doesn't break at rollover (reset all counters or moving averages for example). On Jun 9, 2005, at 8:13 PM, Tom Anderson wrote: At first I thought maybe it was because transferred, readed (sic) and mytraffic are size_t and maybe one of them rolled over. But that would rollover at 4MB right?
