RE: More Ajp13 Work Completed
Hi, Could you send the patches to the list since : * I'd like to test them before applying to the 3.2 tree. They could be ready for 3.2.1. * I'll add them to my tomcat RPM to give production sites an up to date (and sus before 3.2.1) Also what about token / acl in ajp13 for connections between apache and tomcat ??? Thanks "Pour la plupart des hommes, se corriger consiste à changer de défauts." -- Voltaire -Original Message- From: Dan Milstein [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 07, 2000 7:09 AM To: [EMAIL PROTECTED] Subject: More Ajp13 Work Completed All, First off, I want to thank you for nominating me to be a committer. I'm very much looking forward to working on the project. What are the next steps? I just completed another good-sized chunk of work: I believe that I've fixed the multipart form bug (reports #536 and #542), and I rewrote the patch to fix the multiple cookies bug (no longer creating a new Enumeration for every request, as per Costin's suggestion). I'm kind of assuming that I should just hold onto these (rather than bombarding Costin and/or the list with patches), on the theory that I'll be able to commit them myself soon. Does that make sense? Or I could just post the fixes to the list, if that would be better. In the course of fixing multipart form, I modified doRead(byte[], int, int) to use System.arraycopy, which should make it much faster (and it's used for every single Post request, so that's good). I want to do a bit more testing but it's looking pretty good. The old code would also have died on a Request with a body but without a Content-Length (which is allowed for certain Transfer-Encodings by the HTTP/1.1 spec -- I just looked it up). Possibly, I fixed Bug Report #468, which has to do with the content-length not being equal to the actual number of bytes sent -- I'll look into that one. One other thing: in the course of getting this all working, I fixed what seemed to me to be a very serious bug with regard to the persistent connection between the web server and the container. Basically, the read position into the buffer of request data wasn't getting properly reset to 0 for each new request, so reads would start in the middle of the request data in certain cases. At least, that's what I found while I was working on this, but it seems inconceivable to me that this would have been out there without people complaining -- during my testing it was very confusing -- since it depended on what had happened during the previous Request, it seemed totally arbitrary. Does this ring any bells for anyone? If so, then I've fixed it ;-) -Dan -- Dan Milstein // [EMAIL PROTECTED]
RE: More Ajp13 Work Completed
First off, I want to thank you for nominating me to be a committer. I'm very much looking forward to working on the project. Any good help is welcome What are the next steps? I just completed another good-sized chunk of work: I believe that I've fixed the multipart form bug (reports #536 and #542), and I rewrote the patch to fix the multiple cookies bug (no longer creating a new Enumeration for every request, as per Costin's suggestion). I'm kind of assuming that I should just hold onto these (rather than bombarding Costin and/or the list with patches), on the theory that I'll be able to commit them myself soon. Does that make sense? Or I could just post the fixes to the list, if that would be better. You could also send me the patches, I'll apply to TC 3.2. I will incorporate them also to my RPM... In the course of fixing multipart form, I modified doRead(byte[], int, int) to use System.arraycopy, which should make it much faster (and it's used for every single Post request, so that's good). I want to do a bit more testing but it's looking pretty good. The old code would also have died on a Request with a body but without a Content-Length (which is allowed for certain Transfer-Encodings by the HTTP/1.1 spec -- I just looked it up). Possibly, I fixed Bug Report #468, which has to do with the content-length not being equal to the actual number of bytes sent -- I'll look into that one. Whaoou you fix too fast ;-) One other thing: in the course of getting this all working, I fixed what seemed to me to be a very serious bug with regard to the persistent connection between the web server and the container. Basically, the read position into the buffer of request data wasn't getting properly reset to 0 for each new request, so reads would start in the middle of the request data in certain cases. At least, that's what I found while I was working on this, but it seems inconceivable to me that this would have been out there without people complaining -- during my testing it was very confusing -- since it depended on what had happened during the previous Request, it seemed totally arbitrary. Does this ring any bells for anyone? If so, then I've fixed it ;-) Could be also related to problems with RequestDispatcher. Thanks to send me the patches not allready applied to TC 3.2 Regards
RE: More Ajp13 Work Completed - keep-it-running sentinel needed...
With this pace of fixing it would be nice to start having 3.2.1 beta releases soon. =:o) I am very interested on connector related fixes. The other thing I am interested is on what happens when Tomcat freezes. mod_jserv restarts JServ when these one freezes, but mod_jk does not look to provide such mechanism. This is a paste from the "mod_jk-howto" FAQ: Q. Whenever I restart Tomcat, Apache locks up! A. The Ajp13 protocol keeps an open socket between Tomcat and Apache. When you restart Tomcat, you need to restart Apache as well. Can't mod_jk recover from a Tomcat crash? I am not familiar with mod_jk but, if it helps, I could provide a Java sentinel to keep Tomcat running. When Tomcat freezes, it could also kill and restart Apache together with Tomcat... but that sounds quite overkill and disturbs Apache while this one is running ok. Isn't it possible to make mod_jk recover gracefuly from the loss of Tomcat and try to reconnect with a new instance of Tomcat aterwards? It _looks_ like mod_jserv did just that with JServ. Tomcat already froze on us on a test and JServ sometimes does it too (but it is restarted by mod_jserv). I would like to move to Tomcat but I need to have this extra safety layer. Again, I am willing to contribute a Java made portable sentinel but I know nothing about sockets programming in C. Can someone else comment on these issues? Thanks and have fun, Paulo Gaspar -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 07, 2000 11:22 Whaoou you fix too fast ;-)
RE: More Ajp13 Work Completed - keep-it-running sentinel needed...
With this pace of fixing it would be nice to start having 3.2.1 beta releases soon. =:o) I am very interested on connector related fixes. The other thing I am interested is on what happens when Tomcat freezes. mod_jserv restarts JServ when these one freezes, but mod_jk does not look to provide such mechanism. This is a paste from the "mod_jk-howto" FAQ: Q. Whenever I restart Tomcat, Apache locks up! A. The Ajp13 protocol keeps an open socket between Tomcat and Apache. When you restart Tomcat, you need to restart Apache as well. Can't mod_jk recover from a Tomcat crash? I am not familiar with mod_jk but, if it helps, I could provide a Java watchdog to keep Tomcat running. When Tomcat freezes, it could also kill and restart Apache together with Tomcat... but that sounds quite overkill and disturbs Apache while this one is running ok. Isn't it possible to make mod_jk recover gracefully from the loss of Tomcat and try to reconnect with a new instance of Tomcat afterwards? It _looks_ like mod_jserv did just that with JServ. Tomcat already froze on us on a test and JServ sometimes does it too (but it is restarted by mod_jserv). I would like to move to Tomcat but I need to have this extra safety layer. Again, I am willing to contribute a Java made portable watchdog but I know nothing about sockets programming in C. Can someone else comment on these issues? Thanks and have fun, Paulo Gaspar -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 07, 2000 11:22 Whaoou you fix too fast ;-)
RE: More Ajp13 Work Completed - keep-it-running sentinel needed...
-Original Message- From: Kief Morris [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 07, 2000 13:09 How do you see this working? It seems to me that this couldn't be done entirely in Java, it would at least have to run the appropriate start script to make sure classpaths are set, etc. So ajp13 or the watchdog would have to run the start script if it found it couldn't talk to Tomcat. The "workers.properties" file has all the necessary data. It is also possible to start the watchdog instead of tomcat in those start scripts. After having the watchdog started with the right environment variables, this one can use them to call java to run Tomcat. It would also have to worry about restarting it unecessarily - suppose you restart Tomcat manually, how will the watchdog be prevented from thinking it was down and starting a second process? You should restart the watchdog and not Tomcat directly. It is the only way for the Watchdog to have control over Tomcat, so that it can also kill the Tomcat process if this one freezes. Notice that, if mod_jk recovers communication, the watchdog can be a completely separated process. Have fun, Paulo Gaspar
RE: More Ajp13 Work Completed
One other thing: in the course of getting this all working, I fixed what seemed to me to be a very serious bug with regard to the persistent connection between the web server and the container. Basically, the read position into the buffer of request data wasn't getting properly reset to 0 for each new request, so reads would start in the middle of the request data in certain cases. At least, that's what I found while I was working on this, but it seems inconceivable to me that this would have been out there without people complaining -- during my testing it was very confusing -- since it depended on what had happened during the previous Request, it seemed totally arbitrary. Does this ring any bells for anyone? If so, then I've fixed it ;-) That sounds like a problem I was having with ajp13: It seemed that random requests would return no-data on JSPs. This was when I was first setting up Tomcat over here, so I went back to ajp12 for the time being, but it sounds like this could have been the problem. Thanks for the fix. ;-) Now if someone can modify the mod_jk connector to reopen connections to Tomcat after Tomcat is restarted I'll be very happy. Maybe I should brush up on my C socket programming when I get some spare time. ;-) -Dave
More Ajp13 Work Completed
All, First off, I want to thank you for nominating me to be a committer. I'm very much looking forward to working on the project. What are the next steps? I just completed another good-sized chunk of work: I believe that I've fixed the multipart form bug (reports #536 and #542), and I rewrote the patch to fix the multiple cookies bug (no longer creating a new Enumeration for every request, as per Costin's suggestion). I'm kind of assuming that I should just hold onto these (rather than bombarding Costin and/or the list with patches), on the theory that I'll be able to commit them myself soon. Does that make sense? Or I could just post the fixes to the list, if that would be better. In the course of fixing multipart form, I modified doRead(byte[], int, int) to use System.arraycopy, which should make it much faster (and it's used for every single Post request, so that's good). I want to do a bit more testing but it's looking pretty good. The old code would also have died on a Request with a body but without a Content-Length (which is allowed for certain Transfer-Encodings by the HTTP/1.1 spec -- I just looked it up). Possibly, I fixed Bug Report #468, which has to do with the content-length not being equal to the actual number of bytes sent -- I'll look into that one. One other thing: in the course of getting this all working, I fixed what seemed to me to be a very serious bug with regard to the persistent connection between the web server and the container. Basically, the read position into the buffer of request data wasn't getting properly reset to 0 for each new request, so reads would start in the middle of the request data in certain cases. At least, that's what I found while I was working on this, but it seems inconceivable to me that this would have been out there without people complaining -- during my testing it was very confusing -- since it depended on what had happened during the previous Request, it seemed totally arbitrary. Does this ring any bells for anyone? If so, then I've fixed it ;-) -Dan -- Dan Milstein // [EMAIL PROTECTED]
