Re: ISAPI redirector for Microsoft IIS, Jboss EAP 7.2 - sticky session issue
On 21/05/2021 05:51, Mathiazhagan, Saravanakumar TPC wrote:
Hi Mark,
Thanks for the quick response.
I suspect some sort of configuration issue. A guess would be that JBoss
EAOP isn't configured to append the jvmRoute (to use the Tomcat
configuration setting name) to the session ID.
I configured IE to show prompt when cookies are set. I can see the jvmRoute
value in JSessionID generated, with the format {someID}.{workerName}.
You may need to look at the access log and/or network traffic to see
what is going on. That usually sheds some light on these sorts of issues.
I cross verified the access logs. One thing I noticed is consistently the
request switches between servers. So, every time the server gets request, a
new session (JSESSIONID) is being sent out.
From the network side too, no special rules are setup.
With same jvmRoute and network settings, sticky session works properly when I
use Jboss 6.4 version and 32-bit DLL.
If the 32 bit DLL has to work fine with Jboss7.2, then I get a feeling I am
missing something, but not able to figure out exactly what the issue is.
Please let me know if there are any particular configurations that need to be
checked.
At this point, I'd suggest tracing a series of requests from client to
server and checking, at each stage, that the behaviour is as you expect.
Where does it go wrong? That may point you in the right direction.
I'd be wanting to check things like:
- does a new request get a new session ID
- does the worker name match the node that handled the request
- do the access logs confirm the request went to the right worker
- for the second request, does the client sent the session cookie
- does the lb see the session cookie and route the request to the right
host
It sounds like things are going wrong around this point.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: ISAPI redirector for Microsoft IIS, Jboss EAP 7.2 - sticky session issue
Hi Mark,
Thanks for the quick response.
>I suspect some sort of configuration issue. A guess would be that JBoss
>EAOP isn't configured to append the jvmRoute (to use the Tomcat
>configuration setting name) to the session ID.
I configured IE to show prompt when cookies are set. I can see the jvmRoute
value in JSessionID generated, with the format {someID}.{workerName}.
>You may need to look at the access log and/or network traffic to see
>what is going on. That usually sheds some light on these sorts of issues.
I cross verified the access logs. One thing I noticed is consistently the
request switches between servers. So, every time the server gets request, a
new session (JSESSIONID) is being sent out.
>From the network side too, no special rules are setup.
With same jvmRoute and network settings, sticky session works properly when I
use Jboss 6.4 version and 32-bit DLL.
If the 32 bit DLL has to work fine with Jboss7.2, then I get a feeling I am
missing something, but not able to figure out exactly what the issue is.
Please let me know if there are any particular configurations that need to be
checked.
Regards,
Saravanakumar.
smime.p7s
Description: S/MIME cryptographic signature
Re: ISAPI redirector for Microsoft IIS, Jboss EAP 7.2 - sticky session issue
On 18/05/2021 19:53, Mathiazhagan, Saravanakumar TPC wrote: Can you please let me know if the above 32-bit isapi_redirect.dll file can be used with Jboss EAP 7.2.7 server? If so, please guide me on what could be causing the sticky session issue. I can't think of any reason why not. I suspect some sort of configuration issue. A guess would be that JBoss EAOP isn't configured to append the jvmRoute (to use the Tomcat configuration setting name) to the session ID. You may need to look at the access log and/or network traffic to see what is going on. That usually sheds some light on these sorts of issues. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
ISAPI redirector for Microsoft IIS, Jboss EAP 7.2 - sticky session issue
Hi, I am trying to configure the ISAPI redirector for Microsoft IIS web server to Jboss EAP7.2 app server and facing issues with Load balancing. The requests for the same session are not sticking to a single server and keeps switching between different servers, hence session is getting cleared every time. Background: I am upgrading Jboss EAP 6.4 server to Jboss EAP 7.2 version. We currently are using a 32-bit isapi_redirect.dll file which works fine with Jboss 6.4 including sticky session. Existing ISAPI Redirector setup is similar to the reference guide at below link, with isapi_redirect.dll, workers.properties and uriworkermap.properties available. http://tomcat.apache.org/connectors-doc/reference/iis.html Issue: When I switched to Jboss EAP 7.2 with 32-bit isapi_redirect.dll, everything else still works except the sticky session. Server versions: Existing App server - Jboss 6.4.19 New App server - Jboss 7.2.7 Web server - IIS 10.0.14393.0 Steps taken: I reached out Redhat and they provided 64-bit version isapi_redirect.dll file and asked to set "Enable 32-bit Applications" to "False" in the Application Pool. Our front end is Classic ASP 32-bit application. So, "Enable 32-bit Applications" can't be set to "False" in the Application Pool. Redhat had only the 64-bit file. So, they suggested to use the isapi_redirect.dll 32-bit file provided by the Apache Tomcat Connectors. I tried the isapi_redirect.dll file provided at below link, I am still facing the same issue related to sticky session. https://apache.osuosl.org/tomcat/tomcat-connectors/jk/binaries/windows/tomcat-connectors-1.2.48-windows-i386-iis.zip Can you please let me know if the above 32-bit isapi_redirect.dll file can be used with Jboss EAP 7.2.7 server? If so, please guide me on what could be causing the sticky session issue. Regards, Saravanakumar. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS
Great KC - glad it's working! Chris suggested that solution in another thread and it helped me too. Toby -Original Message- From: KC Mok Sent: Wednesday, March 11, 2020 11:55 PM To: Tomcat Users List Subject: Re: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS thank you very much, it is working now! On Thu, Mar 12, 2020, 11:50 Mills, Robert - CTR [ASM Research] wrote: > Hi KC > > I hit that also. Turns out if I added this: > >allowedRequestAttributesPattern=".*" > > Then I got past the 403. I think this is supposed to be fixed in the > next release of tomcat. > > Give it a shot. > > Toby > > -Original Message- > From: KC Mok > Sent: Wednesday, March 11, 2020 11:36 PM > To: users@tomcat.apache.org > Subject: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector > is not "working" when SSL enabled in IIS > > Hi All, > I am using ISAPI redirector to connect IIS to Tomcat via AJP connector. > > Recently I have replaced the Tomcat 9.0.22 with the new version 9.0.31. > > I have set the new required attributes of the AJP connector in the new > 9.0.31 version, and it is working fine when using http. > However, it returns error (403 Access is denied) when I use https to > access the site. > > I tried with the lastest 1.2.48 version isapi_redirect.dll, still not > working. After that, I tried to revert back to Tomcat 9.0.22, > everything is working fine. > > Does anyone have the same problem? > I wonder if I hit a bug in the new version... > please help... > > Thanks and regards, > KC > > > The information contained in this message may be privileged and/or > confidential and protected from disclosure. If the reader of this > message is not the intended recipient or agent responsible for > delivering this message to the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this > communication in error, please notify the sender immediately by > replying to this message and deleting the material from any computer. > The information contained in this message may be privileged and/or confidential and protected from disclosure. If the reader of this message is not the intended recipient or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and deleting the material from any computer.
Re: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS
Btw, I tried my luck on Tomcat 7.0.100 before when 9.0.31 not work, also hit the same problem, just fyi. thanks again for helping me out! On Thu, Mar 12, 2020, 11:55 KC Mok wrote: > thank you very much, it is working now! > > On Thu, Mar 12, 2020, 11:50 Mills, Robert - CTR [ASM Research] > wrote: > >> Hi KC >> >> I hit that also. Turns out if I added this: >> >>allowedRequestAttributesPattern=".*" >> >> Then I got past the 403. I think this is supposed to be fixed in the >> next release of tomcat. >> >> Give it a shot. >> >> Toby >> >> -Original Message- >> From: KC Mok >> Sent: Wednesday, March 11, 2020 11:36 PM >> To: users@tomcat.apache.org >> Subject: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is >> not "working" when SSL enabled in IIS >> >> Hi All, >> I am using ISAPI redirector to connect IIS to Tomcat via AJP connector. >> >> Recently I have replaced the Tomcat 9.0.22 with the new version 9.0.31. >> >> I have set the new required attributes of the AJP connector in the new >> 9.0.31 version, and it is working fine when using http. >> However, it returns error (403 Access is denied) when I use https to >> access the site. >> >> I tried with the lastest 1.2.48 version isapi_redirect.dll, still not >> working. After that, I tried to revert back to Tomcat 9.0.22, everything is >> working fine. >> >> Does anyone have the same problem? >> I wonder if I hit a bug in the new version... >> please help... >> >> Thanks and regards, >> KC >> >> >> The information contained in this message may be privileged and/or >> confidential and protected from disclosure. If the reader of this message >> is not the intended recipient or agent responsible for delivering this >> message to the intended recipient, you are hereby notified that any >> dissemination, distribution or copying of this communication is strictly >> prohibited. If you have received this communication in error, please notify >> the sender immediately by replying to this message and deleting the >> material from any computer. >> >
Re: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS
thank you very much, it is working now! On Thu, Mar 12, 2020, 11:50 Mills, Robert - CTR [ASM Research] wrote: > Hi KC > > I hit that also. Turns out if I added this: > >allowedRequestAttributesPattern=".*" > > Then I got past the 403. I think this is supposed to be fixed in the next > release of tomcat. > > Give it a shot. > > Toby > > -Original Message- > From: KC Mok > Sent: Wednesday, March 11, 2020 11:36 PM > To: users@tomcat.apache.org > Subject: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is > not "working" when SSL enabled in IIS > > Hi All, > I am using ISAPI redirector to connect IIS to Tomcat via AJP connector. > > Recently I have replaced the Tomcat 9.0.22 with the new version 9.0.31. > > I have set the new required attributes of the AJP connector in the new > 9.0.31 version, and it is working fine when using http. > However, it returns error (403 Access is denied) when I use https to > access the site. > > I tried with the lastest 1.2.48 version isapi_redirect.dll, still not > working. After that, I tried to revert back to Tomcat 9.0.22, everything is > working fine. > > Does anyone have the same problem? > I wonder if I hit a bug in the new version... > please help... > > Thanks and regards, > KC > > > The information contained in this message may be privileged and/or > confidential and protected from disclosure. If the reader of this message > is not the intended recipient or agent responsible for delivering this > message to the intended recipient, you are hereby notified that any > dissemination, distribution or copying of this communication is strictly > prohibited. If you have received this communication in error, please notify > the sender immediately by replying to this message and deleting the > material from any computer. >
RE: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS
Hi KC I hit that also. Turns out if I added this: allowedRequestAttributesPattern=".*" Then I got past the 403. I think this is supposed to be fixed in the next release of tomcat. Give it a shot. Toby -Original Message- From: KC Mok Sent: Wednesday, March 11, 2020 11:36 PM To: users@tomcat.apache.org Subject: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS Hi All, I am using ISAPI redirector to connect IIS to Tomcat via AJP connector. Recently I have replaced the Tomcat 9.0.22 with the new version 9.0.31. I have set the new required attributes of the AJP connector in the new 9.0.31 version, and it is working fine when using http. However, it returns error (403 Access is denied) when I use https to access the site. I tried with the lastest 1.2.48 version isapi_redirect.dll, still not working. After that, I tried to revert back to Tomcat 9.0.22, everything is working fine. Does anyone have the same problem? I wonder if I hit a bug in the new version... please help... Thanks and regards, KC The information contained in this message may be privileged and/or confidential and protected from disclosure. If the reader of this message is not the intended recipient or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and deleting the material from any computer.
RE: After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS
Set this on AJP Connector in tomcat server.xml allowedRequestAttributesPattern="CERT_(ISSUER|SUBJECT|COOKIE|FLAGS|SERIALNUMBER)|HTTPS_(SERVER_(SUBJECT|ISSUER)|(SECRETKEYSIZE|KEYSIZE))" All on one line. I can see tomcat fixing this in 9.0.32 which isn't yet released. Thanks, P. -Original Message- From: KC Mok Sent: Thursday, March 12, 2020 9:06 AM To: users@tomcat.apache.org Subject: After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS Hi All, I am using ISAPI redirector to connect IIS to Tomcat via AJP connector. Recently I have replaced the Tomcat 9.0.22 with the new version 9.0.31. I have set the new required attributes of the AJP connector in the new 9.0.31 version, and it is working fine when using http. However, it returns error (403 Access is denied) when I use https to access the site. I tried with the lastest 1.2.48 version isapi_redirect.dll, still not working. After that, I tried to revert back to Tomcat 9.0.22, everything is working fine. Does anyone have the same problem? I wonder if I hit a bug in the new version... please help... Thanks and regards, KC
After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS
Hi All, I am using ISAPI redirector to connect IIS to Tomcat via AJP connector. Recently I have replaced the Tomcat 9.0.22 with the new version 9.0.31. I have set the new required attributes of the AJP connector in the new 9.0.31 version, and it is working fine when using http. However, it returns error (403 Access is denied) when I use https to access the site. I tried with the lastest 1.2.48 version isapi_redirect.dll, still not working. After that, I tried to revert back to Tomcat 9.0.22, everything is working fine. Does anyone have the same problem? I wonder if I hit a bug in the new version... please help... Thanks and regards, KC
Problem with Tomcat 8.0.17, ISAPI Redirector for IIS 7.5
Hello Experts, I have configured IIS website (port 8128) with ISAPI Redirector and deployed .war files on Tomcat as per instructions from this Tomcat website URL: https://tomcat.apache.org/connectors-doc/webserver_howto/iis.html When I run the Tomcat examples using http://localhost:8128/examples on the same host where IIS and tomcat is configured, the tomcat examples are successfully executed. But when I try to access the /examples from another computer in the same domain with url http://myCompHost:8128/examples, I cannot execute tomcat examples, but a file named "examples" is downloaded. IIS log shows that the, the URL is being forwarded to worker "node1" over isapi_redirect.dll. But no further actions take place. Node1 is a worker defined as below: worker.list=node1 worker.node1.port=8009 worker.node1.host=tc10test-bb worker.node1.type=ajp13 The IIS log messages: [Thu Apr 27 14:56:36.636 2017] [4988:4380] [debug] find_match::jk_uri_worker_map.c (1003): Found an exact match '/examples=node1' [Thu Apr 27 14:56:36.636 2017] [4988:4380] [debug] handle_notify_event::jk_isapi_plugin.c (1898): check if [/examples] points to the web-inf directory [Thu Apr 27 14:56:36.636 2017] [4988:4380] [debug] handle_notify_event::jk_isapi_plugin.c (1915): [/examples] is a servlet url - should redirect to node1 [Thu Apr 27 14:56:36.636 2017] [4988:4380] [debug] handle_notify_event::jk_isapi_plugin.c (2026): forwarding to : /jakarta/isapi_redirect.dll [Thu Apr 27 14:56:36.636 2017] [4988:4380] [debug] handle_notify_event::jk_isapi_plugin.c (2028): forward URI : TOMCATURI00018000:/examples [Thu Apr 27 14:56:36.636 2017] [4988:4380] [debug] handle_notify_event::jk_isapi_plugin.c (2033): forward worker: TOMCATWORKER00018000:node1 [Thu Apr 27 14:56:36.636 2017] [4988:4380] [debug] handle_notify_event::jk_isapi_plugin.c (2035): worker index : TOMCATWORKERIDX00018000:4 Any idea what's wrong ? Amol Gulhane
Re: Tomcat 8.0.3 hangs when ISAPI redirector sends an AJP request without request body
On 03/03/2014 21:04, Konstantin Preißer wrote: -Original Message- From: Konstantin Preißer [mailto:kpreis...@apache.org] Sent: Monday, March 3, 2014 5:38 PM When sending the following request to IIS: POST /TestWebapp/Servlet HTTP/1.1 Host: localhost Connection: keep-alive Content-Length: 0 Then the ISAPI redirector sends the following AJP packet to Tomcat: [...] To me, this looks ok - as the request body is 0 (known in advance) AFAIK only the JK_AJP13_FORWARD_REQUEST packet should be sent to Tomcat. Note, that the Content-Length: 0 header is correctly included in the packet: A0 08 00 01 30 (0xA008 represents Content-Length). I tested this now also with Tomcat 8.0.0-RC1 and 8.0.0-RC2, and found that the problem also happens with RC2 but not with RC1: With RC1, s.read() immediately returns so that the read byte count is 0, whereas with RC2, Tomcat hangs after sending the request. Unfortunately I was not able to find which revision introduced the change, as I was not able to build earlier Tomcat trunk SVN revisions - I always get the following error when running ant (this one was with r1518381): This hasn't been forgotten. I have a fix for this that I will commit shortly that will be in 8.0.4 onwards. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 8.0.3 hangs when ISAPI redirector sends an AJP request without request body
Hi Mark, Konstantin K. and others, -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, March 17, 2014 3:12 PM snip This hasn't been forgotten. I have a fix for this that I will commit shortly that will be in 8.0.4 onwards. Thanks for analyzing and solving the issue! Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.0.3 hangs when ISAPI redirector sends an AJP request without request body
Hi,
I observed another strange problem when using Tomcat 8.0.3 with Java 1.7.0_51
(64-bit) on Windows Server 2012 R2, in conjunction with IIS 8.5 + ISAPI
Redirector 1.2.39 (the problem also happens with 1.2.37). I'm using the AJP NIO
and HTTP NIO connectors, but the problem also happens with AJP BIO and AJP APR.
The problem is: When I have a servlet that directly reads the request body, and
I send a HTTP request to IIS (GET or POST) with Content-Length: 0, Tomcat hangs
trying to read the request body. This does not happen when sending the same
request directly to Tomcat using the HTTP connector.
Consider this example servlet:
[[[
@WebServlet(/Servlet)
public class Servlet extends HttpServlet {
private static final long serialVersionUID = 1L;
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
doRequest(request, response, false);
}
protected void doPost(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
doRequest(request, response, true);
}
private void doRequest(HttpServletRequest request, HttpServletResponse
response, boolean isPost) throws ServletException, IOException {
System.out.println(Method: + (isPost ? POST : GET) + . Reading
request body...);
long readCount = 0;
try (InputStream s = request.getInputStream()) {
byte[] buf = new byte[4096];
int read;
while ((read = s.read(buf)) 0)
readCount += read;
}
System.out.println(Reading request body finished, Byte Count: +
readCount);
response.setContentType(text/plain);
response.setCharacterEncoding(UTF-8);
try (PrintWriter w = response.getWriter()) {
w.println(Method: + (isPost ? POST : GET) + . Reading
request body...);
w.println(Request Body length in bytes: + readCount);
}
}
}
]]]
This servlet directly reads the request InputStream and counts the bytes that
it read.
When I now send the following HTTP requests directly to Tomcat (port 8080),
everything works as expected:
Request:
GET /TestWebapp/Servlet HTTP/1.1
Host: localhost
Connection: keep-alive
Content-Length: 10
0123456789
Response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/plain;charset=UTF-8
Content-Length: 72
Date: Mon, 03 Mar 2014 15:39:35 GMT
Method: GET. Reading request body...
Request Body length in bytes: 10
Request:
GET /TestWebapp/Servlet HTTP/1.1
Host: localhost
Connection: keep-alive
Response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/plain;charset=UTF-8
Content-Length: 71
Date: Mon, 03 Mar 2014 15:38:33 GMT
Method: GET. Reading request body...
Request Body length in bytes: 0
However, when I set the ISAPI Redirector for IIS 8.5 to forward every request
to Tomcat, using following worker.properties:
# Define 1 real worker using ajp13
worker.list=worker1
# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=127.0.0.1
worker.worker1.port=8009
and uriworkermap.properties:
/*=worker1
Then, when I send the same requests to IIS, the one which has a body succeeds,
but the one which doesn't have a body does not finish:
Request:
GET /TestWebapp/Servlet HTTP/1.1
Host: localhost
Connection: keep-alive
Content-Length: 10
0123456789
Response:
HTTP/1.1 200 OK
Content-Length: 72
Content-Type: text/plain;charset=UTF-8
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Date: Mon, 03 Mar 2014 15:41:49 GMT
Method: GET. Reading request body...
Request Body length in bytes: 10
Request:
GET /TestWebapp/Servlet HTTP/1.1
Host: localhost
Connection: keep-alive
Response:
(waits forever without sending a response...)
The same happens with this request:
POST /TestWebapp/Servlet HTTP/1.1
Host: localhost
Connection: keep-alive
Content-Length: 0
Response:
(waits forever without sending a response...)
In Tomcat's log you can see that Tomcat hangs at s.read(buf), so it seems it
somehow does not notice that the request body length is 0.
Any idea what's going on there?
Note: I do not yet have examined what AJP packets are sent between Tomcat and
ISAPI Redirector.
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 8.0.3 hangs when ISAPI redirector sends an AJP request without request body
-Original Message- From: Konstantin Preißer [mailto:kpreis...@apache.org] Sent: Monday, March 3, 2014 5:19 PM To: 'Tomcat Users List' Subject: Tomcat 8.0.3 hangs when ISAPI redirector sends an AJP request without request body snip Note: I do not yet have examined what AJP packets are sent between Tomcat and ISAPI Redirector. When sending the following request to IIS: POST /TestWebapp/Servlet HTTP/1.1 Host: localhost Connection: keep-alive Content-Length: 0 Then the ISAPI redirector sends the following AJP packet to Tomcat: [ID 3] Data - Offset: 0x0, Count: 0xB1. 12 34 00 AD 02 04 00 08 48 54 54 50 2F 31 2E 31 00 00 13 2F .4.HTTP/1.1.../ 54 65 73 74 57 65 62 61 70 70 2F 53 65 72 76 6C 65 74 00 00 TestWebapp/Servlet.. 09 31 32 37 2E 30 2E 30 2E 31 00 00 09 31 32 37 2E 30 2E 30 .127.0.0.1...127.0.0 2E 31 00 00 09 6C 6F 63 61 6C 68 6F 73 74 00 00 50 00 00 03 .1...localhost..P... A0 06 00 0A 6B 65 65 70 2D 61 6C 69 76 65 00 A0 08 00 01 30...keep-alive. ...0 00 A0 0B 00 09 6C 6F 63 61 6C 68 6F 73 74 00 03 00 00 00 04 . ...localhost.. 00 00 00 0A 00 0F 41 4A 50 5F 52 45 4D 4F 54 45 5F 50 4F 52 ..AJP_REMOTE_POR 54 00 00 05 34 39 34 38 32 00 0A 00 10 4A 4B 5F 4C 42 5F 41 T...49482JK_LB_A 43 54 49 56 41 54 49 4F 4E 00 00 03 41 43 54 00 FFCTIVATION...ACT.ÿ To me, this looks ok - as the request body is 0 (known in advance) AFAIK only the JK_AJP13_FORWARD_REQUEST packet should be sent to Tomcat. Note, that the Content-Length: 0 header is correctly included in the packet: A0 08 00 01 30 (0xA008 represents Content-Length). Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 8.0.3 hangs when ISAPI redirector sends an AJP request without request body
-Original Message- From: Konstantin Preißer [mailto:kpreis...@apache.org] Sent: Monday, March 3, 2014 5:38 PM When sending the following request to IIS: POST /TestWebapp/Servlet HTTP/1.1 Host: localhost Connection: keep-alive Content-Length: 0 Then the ISAPI redirector sends the following AJP packet to Tomcat: [...] To me, this looks ok - as the request body is 0 (known in advance) AFAIK only the JK_AJP13_FORWARD_REQUEST packet should be sent to Tomcat. Note, that the Content-Length: 0 header is correctly included in the packet: A0 08 00 01 30 (0xA008 represents Content-Length). I tested this now also with Tomcat 8.0.0-RC1 and 8.0.0-RC2, and found that the problem also happens with RC2 but not with RC1: With RC1, s.read() immediately returns so that the read byte count is 0, whereas with RC2, Tomcat hangs after sending the request. Unfortunately I was not able to find which revision introduced the change, as I was not able to build earlier Tomcat trunk SVN revisions - I always get the following error when running ant (this one was with r1518381): trydownload: BUILD FAILED C:\Users\Name\Desktop\Tomcat\tomcat\trunk\build.xml:2481: The following error occurred while executing this line: C:\Users\Name\Desktop\Tomcat\tomcat\trunk\build.xml:2685: the archive file.tar.gz doesn't exist Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Status of the current IIS ISAPI Redirector for Tomcat
Very interesting! Yes, managed code is the path to follow. First idea non-blocking IO (from C# client side): use the new async/await for the communication. But force to use the new .NET framework and Visual Studio. And await is a wait on the current threads: http://msdn.microsoft.com/en-us/library/hh750082.aspx Maybe, a node.js approach, with a callback: http://stackoverflow.com/questions/16894907/creating-asynchronous-methods-with-task-factory-and-callback and only .NET 4.0: http://msdn.microsoft.com/en-us/library/dd537612(v=vs.100).aspx I don't still see the value of await: it blocked the current thread. I guess it is better to use a callback Angel Java Lopez @ajlopez On Fri, Feb 14, 2014 at 9:26 PM, Bilal S bilal.so...@gmail.com wrote: Konstantin, On Fri, Jan 24, 2014 at 2:06 PM, Konstantin Preißer kpreis...@apache.org wrote: Hi all, for my Java Servlet web applications which run on Tomcat (currently 8.0.0-RC 10) on various Windows Server OSes (currently Windows Server 2012 R2), I use the ISAPI Redirector to forward requests from IIS to Tomcat over AJP. I use IIS as primary web server because I also host other websites that use different technologies like ASP.Net and PHP (and because IIS allows to run web applications as different processes as different user accounts, and because I can configure the SSL settings over IIS, and so on). The ISAPI Redirector has its job done well in the past and currently I'm still using it. Note that I'm only using it to forward requests from a single IIS instance to a single Tomcat instance, but not for load-balancing or other features. However, over the time I found some issues which seem to result from the changes that Win Server, IIS and other components have experienced over time, which I wanted to list here and see how these could be changed. A possibility that I see is to use an ASP.Net (C#) based redirector instead of an ISAPI based redirector as that will have a number of advantages - see below. == You raise good points. I have run into similar issues and thus created my own project outside the Apache foundation three years ago (BonCode). It is a C# based AJP connector. It can currently be used with Tomcat, JBOSS, Jetty. From support requests I am surmising that is currently bundled with software from a few manufacturers including: EMC, CSC, Siemens and others instead of ISAPI redirector. Thus, I do encourage the update of the current IIS connection mechanism to a more up-to-date method. Using a managed code mechanism is the way to go in my opinion. In the long run SPDY may also be of interest for the same purpose. The more choices the better. The following are differences already in existence with BonCode and in response to your extensive writing, only read on if you are curious:: 1. The ISAPI Redirector seems to be quite complicate to configure. You have to: 1) place the ISAPI redirector DLL in some arbitrary path (the docs suggest to place them in your Tomcat\bin directory) == not needed 2) create a virtual directory in your IIS web application which points to this path == not needed 3) change the handler settings for the virtual directory to allow to execute ISAPI dlls == not needed 4) add the ISAPI redirector DLL to the list of CGI and ISAPI restrictions in IIS == not needed 5) add the ISAPI redirector DLL to your web app as ISAPI filter == not needed 6) create some registry entries at HKLM\Software\Apache Software Foundation\Jakarta Isapi Redirector\1.0 to specify the path of the virtual directory, path to configuration files etc. == not needed 7) create configuration files (uriworkersmap.properties, worker.properties) and but them in some arbitrary path (the docs suggest to place them in your Tomcat\conf directory) == not needed, configurations are done via the IIS UI and/or an xml config file I see a few problems here. First, you have to place the ISAPI redirector DLL in some external arbitrary path. This can introduce additional maintenance issues as you always have to remember this when e.g. moving the server. Because the docs suggest to place them in your Tomcat\bin directory, you might delete that file by mistake when you delete your Tomcat installation and create a new one. The same is true for the config files - if you place them in your Tomcat directory, you might delete them when you change your Tomcat config. Normally, these files do not belong to Tomcat, but to the ISAPI redirector, so I would expect to place them somewhere in your IIS web application. E.g, ASP.Net web applications have a web.config file in their root directory for configuration, and a bin directory where .Net assemblies can be placed. If you were using an ASP.Net based redirector for example (implemented as a managed module), you can place the binary into the bin
RE: Status of the current IIS ISAPI Redirector for Tomcat
Hi Angel and Bilal, thank you for your replies. -Original Message- From: Angel Java Lopez [mailto:ajlopez2...@gmail.com] Sent: Saturday, February 15, 2014 11:59 AM To: Tomcat Users List Subject: Re: Status of the current IIS ISAPI Redirector for Tomcat Very interesting! Yes, managed code is the path to follow. First idea non-blocking IO (from C# client side): use the new async/await for the communication. But force to use the new .NET framework and Visual Studio. And await is a wait on the current threads: http://msdn.microsoft.com/en-us/library/hh750082.aspx Maybe, a node.js approach, with a callback: http://stackoverflow.com/questions/16894907/creating-asynchronous- methods-with-task-factory-and-callback and only .NET 4.0: http://msdn.microsoft.com/en-us/library/dd537612(v=vs.100).aspx I don't still see the value of await: it blocked the current thread. I guess it is better to use a callback A await on a Task in C# should internally return the current thread back to a threadpool, and use a callback on another thread to continue execution of the method when the Task is finished, so that threads are not blocked when waiting e.g. for an I/O operation to complete. For a full utilization of asynchronous I/O, one would not only have to use async read/write operations when forwarding the request to Tomcat, but also async flush the response body at IIS to the client (and async read the request body). Although the .Net HttpResponse also seem to have BeginFlush() and EndFlush() methods that apply the old-style async programming pattern, in the SPDY Redirector (see below) I'm using Task.Factory.FromAsync(...) to convert these Begin/End-Methods into one that returns a Task, so that it can be integrated into the existing Task-based async code. For async flush and read operations at IIS to work, one will need to create an async module (IHttpModule, but use context.AddOnBeginRequestAsync() methods to add event handlers) or an async handler (derived from HttpTaskAsyncHandler). This is the approach that I use on a draft of an SPDY redirector that can already be tested with Jetty (but not yet with Tomcat), see [1]. After switching from blocking I/O to async methods, the number of threads of the IIS apppool (w3wp.exe) was greatly reduced when having a slow output producer (servlet) on the Jetty side, and a fast client connecting to IIS (but should also work for the more likely scenario: A fast output producer (Jetty) and a slow client); as with blocking I/O, the IIS threads would spend most of their time with doing nothing, whereas with the async approach, they can do other things meanwhile. This approach suits the idea of a multiplexing SPDY as you can send multiple requests on a single SPDY connection, so it doesn't block resources like sockets or threads for the duration of an request. With SPDY, it should also be possible to forward Websocket connections which is AFAIK not possible with AJP. Angel Java Lopez @ajlopez On Fri, Feb 14, 2014 at 9:26 PM, Bilal S bilal.so...@gmail.com wrote: Konstantin, snip == You raise good points. I have run into similar issues and thus created my own project outside the Apache foundation three years ago (BonCode). It is a C# based AJP connector. It can currently be used with Tomcat, JBOSS, Jetty. From support requests I am surmising that is currently bundled with software from a few manufacturers including: EMC, CSC, Siemens and others instead of ISAPI redirector. Thus, I do encourage the update of the current IIS connection mechanism to a more up-to-date method. Using a managed code mechanism is the way to go in my opinion. In the long run SPDY may also be of interest for the same purpose. The more choices the better. The following are differences already in existence with BonCode and in response to your extensive writing, only read on if you are curious:: Thank you for you detailed response, this is very helpful. snip 6. As far as I can see, the ISAPI redirector uses blocking I/O when forwarding requests to Tomcat. This means when a slow client sends a request to IIS which gets forwarded to Tomcat, and Tomcat starts to send the response, in the IIS worker process at least 1 Thread will be dedicated to this request as long as it is not finished. This means if 500 slow clients concurrently send requests to IIS (which get forwarded), IIS has to create 500 threads in the w3wp.exe. This can be a problem in terms of scalability, if lots of clients send concurrent requests to your server. == Not most elegant but BonCode will time out the connection based on IIS AppPool setting and reuse. You can also do a similar thing on the Tomcat side. The nature of AJP does not allow multiplexing a connection, so it needs to be dedicated to a client. The recently released Servlet 3.1 spec allows to use non
RE: Status of the current IIS ISAPI Redirector for Tomcat
This is a TC Users list so I will redirect the conversation to how do we use SPD in a Tomcat implementation TO Wit: what you're asking is there support for SPDY Protocol in any version of TOMCAT? Since SPDY requires the use of SSL/TLS (with TLS extension NPN) Which version TC Container supports TLS/NPM? *gruss* Martin __ From: kpreis...@apache.org To: users@tomcat.apache.org Subject: RE: Status of the current IIS ISAPI Redirector for Tomcat Date: Sat, 15 Feb 2014 15:00:44 +0100 Hi Angel and Bilal, thank you for your replies. -Original Message- From: Angel Java Lopez [mailto:ajlopez2...@gmail.com] Sent: Saturday, February 15, 2014 11:59 AM To: Tomcat Users List Subject: Re: Status of the current IIS ISAPI Redirector for Tomcat Very interesting! Yes, managed code is the path to follow. First idea non-blocking IO (from C# client side): use the new async/await for the communication. But force to use the new .NET framework and Visual Studio. And await is a wait on the current threads: http://msdn.microsoft.com/en-us/library/hh750082.aspx Maybe, a node.js approach, with a callback: http://stackoverflow.com/questions/16894907/creating-asynchronous- methods-with-task-factory-and-callback and only .NET 4.0: http://msdn.microsoft.com/en-us/library/dd537612(v=vs.100).aspx I don't still see the value of await: it blocked the current thread. I guess it is better to use a callback A await on a Task in C# should internally return the current thread back to a threadpool, and use a callback on another thread to continue execution of the method when the Task is finished, so that threads are not blocked when waiting e.g. for an I/O operation to complete. For a full utilization of asynchronous I/O, one would not only have to use async read/write operations when forwarding the request to Tomcat, but also async flush the response body at IIS to the client (and async read the request body). Although the .Net HttpResponse also seem to have BeginFlush() and EndFlush() methods that apply the old-style async programming pattern, in the SPDY Redirector (see below) I'm using Task.Factory.FromAsync(...) to convert these Begin/End-Methods into one that returns a Task, so that it can be integrated into the existing Task-based async code. For async flush and read operations at IIS to work, one will need to create an async module (IHttpModule, but use context.AddOnBeginRequestAsync() methods to add event handlers) or an async handler (derived from HttpTaskAsyncHandler). This is the approach that I use on a draft of an SPDY redirector that can already be tested with Jetty (but not yet with Tomcat), see [1]. After switching from blocking I/O to async methods, the number of threads of the IIS apppool (w3wp.exe) was greatly reduced when having a slow output producer (servlet) on the Jetty side, and a fast client connecting to IIS (but should also work for the more likely scenario: A fast output producer (Jetty) and a slow client); as with blocking I/O, the IIS threads would spend most of their time with doing nothing, whereas with the async approach, they can do other things meanwhile. This approach suits the idea of a multiplexing SPDY as you can send multiple requests on a single SPDY connection, so it doesn't block resources like sockets or threads for the duration of an request. With SPDY, it should also be possible to forward Websocket connections which is AFAIK not possible with AJP. Angel Java Lopez @ajlopez On Fri, Feb 14, 2014 at 9:26 PM, Bilal S bilal.so...@gmail.com wrote: Konstantin, snip == You raise good points. I have run into similar issues and thus created my own project outside the Apache foundation three years ago (BonCode). It is a C# based AJP connector. It can currently be used with Tomcat, JBOSS, Jetty. From support requests I am surmising that is currently bundled with software from a few manufacturers including: EMC, CSC, Siemens and others instead of ISAPI redirector. Thus, I do encourage the update of the current IIS connection mechanism to a more up-to-date method. Using a managed code mechanism is the way to go in my opinion. In the long run SPDY may also be of interest for the same purpose. The more choices the better. The following are differences already in existence with BonCode and in response to your extensive writing, only read on if you are curious:: Thank you for you detailed response, this is very helpful. snip 6. As far as I can see, the ISAPI redirector uses blocking I/O when forwarding requests to Tomcat. This means when a slow client sends a request to IIS which gets forwarded to Tomcat, and Tomcat starts to send the response, in the IIS worker process at least
Re: Status of the current IIS ISAPI Redirector for Tomcat
Konstantin, On Fri, Jan 24, 2014 at 2:06 PM, Konstantin Preißer kpreis...@apache.orgwrote: Hi all, for my Java Servlet web applications which run on Tomcat (currently 8.0.0-RC 10) on various Windows Server OSes (currently Windows Server 2012 R2), I use the ISAPI Redirector to forward requests from IIS to Tomcat over AJP. I use IIS as primary web server because I also host other websites that use different technologies like ASP.Net and PHP (and because IIS allows to run web applications as different processes as different user accounts, and because I can configure the SSL settings over IIS, and so on). The ISAPI Redirector has its job done well in the past and currently I'm still using it. Note that I'm only using it to forward requests from a single IIS instance to a single Tomcat instance, but not for load-balancing or other features. However, over the time I found some issues which seem to result from the changes that Win Server, IIS and other components have experienced over time, which I wanted to list here and see how these could be changed. A possibility that I see is to use an ASP.Net (C#) based redirector instead of an ISAPI based redirector as that will have a number of advantages - see below. == You raise good points. I have run into similar issues and thus created my own project outside the Apache foundation three years ago (BonCode). It is a C# based AJP connector. It can currently be used with Tomcat, JBOSS, Jetty. From support requests I am surmising that is currently bundled with software from a few manufacturers including: EMC, CSC, Siemens and others instead of ISAPI redirector. Thus, I do encourage the update of the current IIS connection mechanism to a more up-to-date method. Using a managed code mechanism is the way to go in my opinion. In the long run SPDY may also be of interest for the same purpose. The more choices the better. The following are differences already in existence with BonCode and in response to your extensive writing, only read on if you are curious:: 1. The ISAPI Redirector seems to be quite complicate to configure. You have to: 1) place the ISAPI redirector DLL in some arbitrary path (the docs suggest to place them in your Tomcat\bin directory) == not needed 2) create a virtual directory in your IIS web application which points to this path == not needed 3) change the handler settings for the virtual directory to allow to execute ISAPI dlls == not needed 4) add the ISAPI redirector DLL to the list of CGI and ISAPI restrictions in IIS == not needed 5) add the ISAPI redirector DLL to your web app as ISAPI filter == not needed 6) create some registry entries at HKLM\Software\Apache Software Foundation\Jakarta Isapi Redirector\1.0 to specify the path of the virtual directory, path to configuration files etc. == not needed 7) create configuration files (uriworkersmap.properties, worker.properties) and but them in some arbitrary path (the docs suggest to place them in your Tomcat\conf directory) == not needed, configurations are done via the IIS UI and/or an xml config file I see a few problems here. First, you have to place the ISAPI redirector DLL in some external arbitrary path. This can introduce additional maintenance issues as you always have to remember this when e.g. moving the server. Because the docs suggest to place them in your Tomcat\bin directory, you might delete that file by mistake when you delete your Tomcat installation and create a new one. The same is true for the config files - if you place them in your Tomcat directory, you might delete them when you change your Tomcat config. Normally, these files do not belong to Tomcat, but to the ISAPI redirector, so I would expect to place them somewhere in your IIS web application. E.g, ASP.Net web applications have a web.config file in their root directory for configuration, and a bin directory where .Net assemblies can be placed. If you were using an ASP.Net based redirector for example (implemented as a managed module), you can place the binary into the bin directory of your IIS webapp and configure it by adding it to the web.config file. This would also mean that you don't have to create a virtual directory any more. I also got problems with the system-wide registry keys that you need to set up for the ISAPI redirector, as they don't allow separate configs for different IIS webapps. I once tried to create a isapi_redirect.properties with the configuration (instead of using the registry) like it is described on the Tomcat Connectors IIS reference page [1], but I didn't have success, so I reverted back to the registry settings. Note also that Microsoft has deprecated ISAPI filters and extensions in favor of native http modules [2]. == not needed 2. When using the ISAPI redirector with IIS 7, I got a few problems with response buffering - it seemed that IIS buffered the complete response body
Status of the current IIS ISAPI Redirector for Tomcat
Hi all, for my Java Servlet web applications which run on Tomcat (currently 8.0.0-RC 10) on various Windows Server OSes (currently Windows Server 2012 R2), I use the ISAPI Redirector to forward requests from IIS to Tomcat over AJP. I use IIS as primary web server because I also host other websites that use different technologies like ASP.Net and PHP (and because IIS allows to run web applications as different processes as different user accounts, and because I can configure the SSL settings over IIS, and so on). The ISAPI Redirector has its job done well in the past and currently I'm still using it. Note that I'm only using it to forward requests from a single IIS instance to a single Tomcat instance, but not for load-balancing or other features. However, over the time I found some issues which seem to result from the changes that Win Server, IIS and other components have experienced over time, which I wanted to list here and see how these could be changed. A possibility that I see is to use an ASP.Net (C#) based redirector instead of an ISAPI based redirector as that will have a number of advantages - see below. 1. The ISAPI Redirector seems to be quite complicate to configure. You have to: 1) place the ISAPI redirector DLL in some arbitrary path (the docs suggest to place them in your Tomcat\bin directory) 2) create a virtual directory in your IIS web application which points to this path 3) change the handler settings for the virtual directory to allow to execute ISAPI dlls 4) add the ISAPI redirector DLL to the list of CGI and ISAPI restrictions in IIS 5) add the ISAPI redirector DLL to your web app as ISAPI filter 6) create some registry entries at HKLM\Software\Apache Software Foundation\Jakarta Isapi Redirector\1.0 to specify the path of the virtual directory, path to configuration files etc. 7) create configuration files (uriworkersmap.properties, worker.properties) and but them in some arbitrary path (the docs suggest to place them in your Tomcat\conf directory) I see a few problems here. First, you have to place the ISAPI redirector DLL in some external arbitrary path. This can introduce additional maintenance issues as you always have to remember this when e.g. moving the server. Because the docs suggest to place them in your Tomcat\bin directory, you might delete that file by mistake when you delete your Tomcat installation and create a new one. The same is true for the config files - if you place them in your Tomcat directory, you might delete them when you change your Tomcat config. Normally, these files do not belong to Tomcat, but to the ISAPI redirector, so I would expect to place them somewhere in your IIS web application. E.g, ASP.Net web applications have a web.config file in their root directory for configuration, and a bin directory where .Net assemblies can be placed. If you were using an ASP.Net based redirector for example (implemented as a managed module), you can place the binary into the bin directory of your IIS webapp and configure it by adding it to the web.config file. This would also mean that you don't have to create a virtual directory any more. I also got problems with the system-wide registry keys that you need to set up for the ISAPI redirector, as they don't allow separate configs for different IIS webapps. I once tried to create a isapi_redirect.properties with the configuration (instead of using the registry) like it is described on the Tomcat Connectors IIS reference page [1], but I didn't have success, so I reverted back to the registry settings. Note also that Microsoft has deprecated ISAPI filters and extensions in favor of native http modules [2]. 2. When using the ISAPI redirector with IIS 7, I got a few problems with response buffering - it seemed that IIS buffered the complete response body before starting to send it to the client. However, when I tried this again on IIS 8.5 today, then IIS only buffered a few MB before sending it to the client, so I think this is not a problem any more. Note that you can manually specify the amount that IIS should buffer, by adding the following in web.config (in configuration , system.webServer): handlers remove name=ISAPI-dll / add name=ISAPI-dll path=*.dll verb=* modules=IsapiModule resourceType=File requireAccess=Execute allowPathInfo=true responseBufferLimit=1 / /handlers 3. Chunked encoding is disabled by default. Personally I think every web server should use chunked encoding if the client specifies connection: keep-alive and the content-length is unknown, so that the server doesn't have to close the connection to signal EOF. It seems that this is a bit difficult in an ISAPI extension as this feature was being considered experimental until a few years ago. However, for example if you code a managed HTTP module using C#, you can just write bytes to the response without having to think about chunked encoding
ISAPI Redirector
Hi im using ISAPI redirector for iis 7 on windows 2008 with tomcat 5.5 it works fine with one instance of tomcat. But I need to setupo something like this on uiworkermap.properties. subdomain.domain.com/*=worker4 because i need to setup differents environments of tomcat one for prod and another for qa and developing. I wonder if this is posible on Windows with iis. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ISAPI Redirector
From: Christopher Valerio cvale...@growthaccelerationpartners.com To: users@tomcat.apache.org Sent: Sunday, July 14, 2013 6:48 PM Subject: ISAPI Redirector Hi im using ISAPI redirector for iis 7 on windows 2008 with tomcat 5.5 it works fine with one instance of tomcat. But I need to setupo something like this on uiworkermap.properties. subdomain.domain.com/*=worker4 because i need to setup differents environments of tomcat one for prod and another for qa and developing. I wonder if this is posible on Windows with iis. I have no idea about Tomcat 5.5.x (it's no longer supported). However, the documentation here http://tomcat.apache.org/connectors-doc/reference/iis.html states the following: The ISAPI redirector can read it's configuration from a properties file instead of the registry. This has the advantage that you can use multiple ISAPI redirectors with independent configurations on the same server. The redirector will check for the properties file during initialisation, and use it in preference to the registry if present. Create a properties file in the same directory as the ISAPI redirector called isapi_redirect.properties i.e. with the same name as the ISAPI redirector DLL but with a .properties extension. A sample isapi_redirect.properties can be found under the conf directory. The property names and values in the properties file are the same as for the registry settings described above. For each Tomcat you'll have to change the shudown port and AJP/1.3 ports. However, according to the documentation above, it should work. I've not tried it - I'm in the process of writing an IIS 7.5 / Tomcat 7.x / ASP.NET integration document for $work. . . . . just my two cents. /mde/ PS - Upgrade, upgrade, upgrade. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different
On 24.04.2013 09:02, Rainer Jung wrote: On 24.04.2013 06:53, Beavers, Melinda K (Kay) wrote: We have installed the IIS-Tomcat redirector (isapi_redirect.dll) on an IIS 6 server so that http://iis.company.com/website/myfile.jsp will correctly redirect according to our 'isapi_redirect.properties', 'workers.properties', and 'uriworkermap.properties ' and serve the JSP page from http://tomcat.company.com/website/myfile.jsp . That appears to be working just fine. But we actually need to have a different IIS URL. What we are trying to figure out is if we can configure it so that http://iis.company.com/apps/cepv/website/myfile.jsp will redirect and serve the JSP content at http://tomcat.company.com/website/myfile.jsp. The path on the IIS server is has two extra levels (/apps/cepv) in the URL path and does not match the path on the tomcat server where the JSP content is. We have to have those two extra levels in the IIS URL path for other technical reasons and we cannot match or include those two extra levels on the tomcat side. We have tried the following but cannot get it to work. website.worker=website_ajp13 /apps/cepv/website/*.jsp=$(website.worker) Is there anything we can do to map this correctly? Have a look at https://tomcat.apache.org/connectors-doc/generic_howto/proxy.html#URL%20Rewriting starting from If you are using Microsoft IIS as a web server The OP reported via PM that it now works after upgrading from an outdated version to a recent one. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different
On 24.04.2013 06:53, Beavers, Melinda K (Kay) wrote: We have installed the IIS-Tomcat redirector (isapi_redirect.dll) on an IIS 6 server so that http://iis.company.com/website/myfile.jsp will correctly redirect according to our 'isapi_redirect.properties', 'workers.properties', and 'uriworkermap.properties ' and serve the JSP page from http://tomcat.company.com/website/myfile.jsp . That appears to be working just fine. But we actually need to have a different IIS URL. What we are trying to figure out is if we can configure it so that http://iis.company.com/apps/cepv/website/myfile.jsp will redirect and serve the JSP content at http://tomcat.company.com/website/myfile.jsp. The path on the IIS server is has two extra levels (/apps/cepv) in the URL path and does not match the path on the tomcat server where the JSP content is. We have to have those two extra levels in the IIS URL path for other technical reasons and we cannot match or include those two extra levels on the tomcat side. We have tried the following but cannot get it to work. website.worker=website_ajp13 /apps/cepv/website/*.jsp=$(website.worker) Is there anything we can do to map this correctly? Have a look at https://tomcat.apache.org/connectors-doc/generic_howto/proxy.html#URL%20Rewriting starting from If you are using Microsoft IIS as a web server Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different
Rainer, thank you for that link!! I have put this line in my isapi_redirect.properties file: rewrite_rule_file=C:\Avaya\TomcatFilter\rewrite.properties and put my rewrite.properties file in place with just a single line in it: /apps/cepv/website/=/website/ and reset IIS. It is not working but in the debug log I never see any reference to using the rewrite file. I never see entries like described below: During startup, you should see Using rewrite rule file YOURRULESFILE in the log file, and later Loaded rewrite rule file YOURRULESFILE Between those two, you should also see lines indicating, that the contents of the file got parsed. Do you know if there's some other step I'm missing or if it has to be a certain version in order to recognize the rewrite file? Regards, Katy -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Wednesday, April 24, 2013 2:03 AM To: users@tomcat.apache.org Subject: Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different On 24.04.2013 06:53, Beavers, Melinda K (Kay) wrote: We have installed the IIS-Tomcat redirector (isapi_redirect.dll) on an IIS 6 server so that http://iis.company.com/website/myfile.jsp will correctly redirect according to our 'isapi_redirect.properties', 'workers.properties', and 'uriworkermap.properties ' and serve the JSP page from http://tomcat.company.com/website/myfile.jsp . That appears to be working just fine. But we actually need to have a different IIS URL. What we are trying to figure out is if we can configure it so that http://iis.company.com/apps/cepv/website/myfile.jsp will redirect and serve the JSP content at http://tomcat.company.com/website/myfile.jsp. The path on the IIS server is has two extra levels (/apps/cepv) in the URL path and does not match the path on the tomcat server where the JSP content is. We have to have those two extra levels in the IIS URL path for other technical reasons and we cannot match or include those two extra levels on the tomcat side. We have tried the following but cannot get it to work. website.worker=website_ajp13 /apps/cepv/website/*.jsp=$(website.worker) Is there anything we can do to map this correctly? Have a look at https://tomcat.apache.org/connectors-doc/generic_howto/proxy.html#URL%20Rewriting starting from If you are using Microsoft IIS as a web server Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different
Beavers, Melinda K (Kay) wrote: Rainer, thank you for that link!! I have put this line in my isapi_redirect.properties file: rewrite_rule_file=C:\Avaya\TomcatFilter\rewrite.properties and put my rewrite.properties file in place with just a single line in it: /apps/cepv/website/=/website/ and reset IIS. It is not working but in the debug log I never see any reference to using the rewrite file. I never see entries like described below: During startup, you should see Using rewrite rule file YOURRULESFILE in the log file, and later Loaded rewrite rule file YOURRULESFILE Between those two, you should also see lines indicating, that the contents of the file got parsed. Do you know if there's some other step I'm missing or if it has to be a certain version in order to recognize the rewrite file? Regards, Katy -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Wednesday, April 24, 2013 2:03 AM To: users@tomcat.apache.org Subject: Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different On 24.04.2013 06:53, Beavers, Melinda K (Kay) wrote: We have installed the IIS-Tomcat redirector (isapi_redirect.dll) on an IIS 6 server so that http://iis.company.com/website/myfile.jsp will correctly redirect according to our 'isapi_redirect.properties', 'workers.properties', and 'uriworkermap.properties ' and serve the JSP page from http://tomcat.company.com/website/myfile.jsp . That appears to be working just fine. But we actually need to have a different IIS URL. What we are trying to figure out is if we can configure it so that http://iis.company.com/apps/cepv/website/myfile.jsp will redirect and serve the JSP content at http://tomcat.company.com/website/myfile.jsp. The path on the IIS server is has two extra levels (/apps/cepv) in the URL path and does not match the path on the tomcat server where the JSP content is. We have to have those two extra levels in the IIS URL path for other technical reasons and we cannot match or include those two extra levels on the tomcat side. We have tried the following but cannot get it to work. website.worker=website_ajp13 /apps/cepv/website/*.jsp=$(website.worker) Is there anything we can do to map this correctly? Have a look at https://tomcat.apache.org/connectors-doc/generic_howto/proxy.html#URL%20Rewriting starting from If you are using Microsoft IIS as a web server Melinda, in addition to what Rainer writes above, and if you determine later that you need more powerful URL-rewriting capabilities under IIS later, have a look at : http://www.helicontech.com/isapi_rewrite/ Also, on this list, try to not top-post your reponses, it makes it more difficult for everyone to follow the conversation (scrolling up and down etc..) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different
Hi Katy, On 24.04.2013 16:38, Beavers, Melinda K (Kay) wrote: Rainer, thank you for that link!! I have put this line in my isapi_redirect.properties file: rewrite_rule_file=C:\Avaya\TomcatFilter\rewrite.properties and put my rewrite.properties file in place with just a single line in it: /apps/cepv/website/=/website/ and reset IIS. It is not working but in the debug log I never see any reference to using the rewrite file. I never see entries like described below: During startup, you should see Using rewrite rule file YOURRULESFILE in the log file, and later Loaded rewrite rule file YOURRULESFILE Between those two, you should also see lines indicating, that the contents of the file got parsed. Do you know if there's some other step I'm missing or if it has to be a certain version in order to recognize the rewrite file? First: which version are you using? Then: I assume we already know that your entries to isapi_redirect.properties work in principle, i.e. that you can confirm that some of the entries did work, just not the rewrite_rule_file entry. Correct? Next I assume you could correctly set a log file using the log_file entry and that you can now set the log level to debug using log_level=debug. When you now start up, you should get a couple of log lines containing the word Using. Post at least them or even better all startup log messages, excluding any confidential stuff. Regards, Rainer -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Wednesday, April 24, 2013 2:03 AM To: users@tomcat.apache.org Subject: Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different On 24.04.2013 06:53, Beavers, Melinda K (Kay) wrote: We have installed the IIS-Tomcat redirector (isapi_redirect.dll) on an IIS 6 server so that http://iis.company.com/website/myfile.jsp will correctly redirect according to our 'isapi_redirect.properties', 'workers.properties', and 'uriworkermap.properties ' and serve the JSP page from http://tomcat.company.com/website/myfile.jsp . That appears to be working just fine. But we actually need to have a different IIS URL. What we are trying to figure out is if we can configure it so that http://iis.company.com/apps/cepv/website/myfile.jsp will redirect and serve the JSP content at http://tomcat.company.com/website/myfile.jsp. The path on the IIS server is has two extra levels (/apps/cepv) in the URL path and does not match the path on the tomcat server where the JSP content is. We have to have those two extra levels in the IIS URL path for other technical reasons and we cannot match or include those two extra levels on the tomcat side. We have tried the following but cannot get it to work. website.worker=website_ajp13 /apps/cepv/website/*.jsp=$(website.worker) Is there anything we can do to map this correctly? Have a look at https://tomcat.apache.org/connectors-doc/generic_howto/proxy.html#URL%20Rewriting starting from If you are using Microsoft IIS as a web server Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different
We have installed the IIS-Tomcat redirector (isapi_redirect.dll) on an IIS 6 server so that http://iis.company.com/website/myfile.jsp will correctly redirect according to our 'isapi_redirect.properties', 'workers.properties', and 'uriworkermap.properties ' and serve the JSP page from http://tomcat.company.com/website/myfile.jsp . That appears to be working just fine. But we actually need to have a different IIS URL. What we are trying to figure out is if we can configure it so that http://iis.company.com/apps/cepv/website/myfile.jsp will redirect and serve the JSP content at http://tomcat.company.com/website/myfile.jsp. The path on the IIS server is has two extra levels (/apps/cepv) in the URL path and does not match the path on the tomcat server where the JSP content is. We have to have those two extra levels in the IIS URL path for other technical reasons and we cannot match or include those two extra levels on the tomcat side. We have tried the following but cannot get it to work. website.worker=website_ajp13 /apps/cepv/website/*.jsp=$(website.worker) Is there anything we can do to map this correctly? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta ISAP Redirector
On 14.06.2012 03:03, DeMarco, Alex wrote: I have 4 servers all configured the same way.. Locally the call works fine yet remotely I get an iis 404 Maybe you get a redirect that isn't working remotely? Use a browser that allows to track traffic, like Firefox with the FireBug plugin and check the full conversation. Regards, Rainer -Original Message- From: DeMarco, Alex [mailto:alex.dema...@suny.edu] Sent: Wednesday, June 13, 2012 8:45 PM To: Tomcat Users List Subject: RE: Jakarta ISAP Redirector Yes I have looked in the log file and set it debug. There are no errors logged. My uriworkermap has this: /myapp=DTS_Submission /myapp/*=DTS_Submission My Workers file has: worker.list=DTS_Submission worker.DTS_Submission.type=ajp13 worker.DTS_Submission.host=xxx.xxx.xxx.xxx worker.DTS_Submission.port=3305 If I am locally on the box (with a local host entry that maps to the same IIS site on that box) it works fine. However, from my desktop I get a page could not be found... However, it says it can't find http://myurl:80/jakarta/isapi_redirect.dll I have double and triple checked my config. From my desktop this works: http://myurl/myapp/services/mywebservice?wsdl but this fails http:// myurl/myapp/services?wsdl but when on the local sever everything works. I see no errors in the log. It's like IIS is stopping the request?? - Alex -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Wednesday, June 13, 2012 2:18 PM To: Tomcat Users List Subject: Re: Jakarta ISAP Redirector DeMarco, Alex wrote: I hope this is the right place to post this question. It is the right place. We have the latest Jakarta Plugin installed with IIS 7.5. Do you know, does the plugin specifically block /services requests on wsdl's Short answer : no, it does not specifically block any request. In fact, it is the opposite : it only forwards requests to Tomcat, if the request URL matches some pre-defined values. See : http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html the section How does it work ?. (and for the word worker, understand a back-end tomcat). One more thing : the isapi_redirector can write a logfile. See item (3) in the section Configuring the ISAPI Redirector for details. The logfile will tell you when and why it is forwarding a request to Tomcat and when/why not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- kippdata informationstechnologie GmbH Tel: 0228 98549 -0 Bornheimer Str. 33aFax: 0228 98549 -50 53111 Bonn www.kippdata.de HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417 Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta ISAP Redirector
Top-posting (as I am doing here : writing every response at the top of the message), makes it difficult for others to follow the flow of the conversation. Better to put your responses under the question or paragraph to which they relate. See below. DeMarco, Alex wrote: I have 4 servers all configured the same way.. Locally the call works fine yet remotely I get an iis 404 - Alex -Original Message- From: DeMarco, Alex [mailto:alex.dema...@suny.edu] Sent: Wednesday, June 13, 2012 8:45 PM To: Tomcat Users List Subject: RE: Jakarta ISAP Redirector Yes I have looked in the log file and set it debug. There are no errors logged. My uriworkermap has this: /myapp=DTS_Submission /myapp/*=DTS_Submission My Workers file has: worker.list=DTS_Submission worker.DTS_Submission.type=ajp13 worker.DTS_Submission.host=xxx.xxx.xxx.xxx worker.DTS_Submission.port=3305 The above configuration looks fine, provided that the IP address xxx.xxx.xxx.xxx is really the IP address of the Tomcat host, as IIS sees it. If I am locally on the box (with a local host entry that maps to the same IIS site on that box) it works fine. However, from my desktop I get a page could not be found... However, it says it can't find http://myurl:80/jakarta/isapi_redirect.dll It would never find this resource, unless : - either you do have a subdirectory jakarta in your IIS document space - or you have a isapi_redirect mapping which maps this URL to Tomcat, and tomcat has a webapp named jakarta And even if it found it there, it would then return the dll to the browser. That is certainly not what you want. Do you understand the above paragraph, really ? It is important, because if you do not understand that, then it will be very difficult to help you here. And anyway, why are you giving this as an example ? it is totally irrelevant. In the uriworkermap that you list above, you are mapping URI's starting with /myapp. You are not mapping URI's starting with /jakarta or anything else, so why would you expect this to be relevant ? I have double and triple checked my config. From my desktop this works: your desktop where ? be precise, please. Try not to force us to guess at each step. http://myurl/myapp/services/mywebservice?wsdl By myurl you mean the hostname, yes ? (then say so, plase. The URL is the whole thing http://myurl/myapp/services/mywebservice?wsdl;.) but this fails http:// myurl/myapp/services?wsdl What is that space there ? if it is really there, then no wonder it fails. And /how/ does it fail ? it fails doesn't mean anything, technically speaking. but when on the local sever everything works. I see no errors in the log. It's like IIS is stopping the request?? Very carefully said : yes, it looks that way. Why, I have no idea. But at this point it does not look as if it has anything to do with the isapi_redirector. With the configuration which you show above, and as far as only isapi_redirector is concerned, all the URI's that (after the hostname part) start with /myapp, should be forwarded by IIS and isapi_redirector to Tomcat, and the isapi_redirector log should show that. It would be very strange if something at (or before) the IIS level was allowing URI's like http://myurl/myapp/services/mywebservice; to go through, but was blocking URI's like http://myurl/myapp/services;. But only you know what is in the configuration of that server, its firewall, etc.. Maybe services is something defined somewhere in IIS, and directed somewhere else (or forbidden) ? You need to design a test setup in which you can check this systematically. For example : Under the IIS wwwroot, create a sub-directory /myapp/, and put some document test.html there. Then with your browser, try to access http://yourhost/myapp/test.html. And note the result. Then create a sub-directory wwwroot/myapp/services/, put a document test2.html there, and try to access it, and note the result. etc.. Do this both from a browser on a separate workstation, and from a browser running on the IIS host itself. Then compare the results, and also look in the isapi_redirector logs. And then think. The answer is somewhere in the configuration of the browser, the network, the host, IIS, isapi_redirector or Tomcat. We do not have access to those things; but you do. You must make a list of what could be happening, and then design tests to rule out one or the other possibility. When you are left with only one, then that is the answer. And stop top-posting. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Jakarta ISAP Redirector
-Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Thursday, June 14, 2012 4:16 AM To: Tomcat Users List Subject: Re: Jakarta ISAP Redirector Top-posting (as I am doing here : writing every response at the top of the message), makes it difficult for others to follow the flow of the conversation. Better to put your responses under the question or paragraph to which they relate. See below. DeMarco, Alex wrote: I have 4 servers all configured the same way.. Locally the call works fine yet remotely I get an iis 404 - Alex -Original Message- From: DeMarco, Alex [mailto:alex.dema...@suny.edu] Sent: Wednesday, June 13, 2012 8:45 PM To: Tomcat Users List Subject: RE: Jakarta ISAP Redirector Yes I have looked in the log file and set it debug. There are no errors logged. My uriworkermap has this: /myapp=DTS_Submission /myapp/*=DTS_Submission My Workers file has: worker.list=DTS_Submission worker.DTS_Submission.type=ajp13 worker.DTS_Submission.host=xxx.xxx.xxx.xxx worker.DTS_Submission.port=3305 The above configuration looks fine, provided that the IP address xxx.xxx.xxx.xxx is really the IP address of the Tomcat host, as IIS sees it. If I am locally on the box (with a local host entry that maps to the same IIS site on that box) it works fine. However, from my desktop I get a page could not be found... However, it says it can't find http://myurl:80/jakarta/isapi_redirect.dll It would never find this resource, unless : - either you do have a subdirectory jakarta in your IIS document space - or you have a isapi_redirect mapping which maps this URL to Tomcat, and tomcat has a webapp named jakarta And even if it found it there, it would then return the dll to the browser. That is certainly not what you want. Do you understand the above paragraph, really ? It is important, because if you do not understand that, then it will be very difficult to help you here. And anyway, why are you giving this as an example ? it is totally irrelevant. In the uriworkermap that you list above, you are mapping URI's starting with /myapp. You are not mapping URI's starting with /jakarta or anything else, so why would you expect this to be relevant ? I have double and triple checked my config. From my desktop this works: your desktop where ? be precise, please. Try not to force us to guess at each step. http://myurl/myapp/services/mywebservice?wsdl By myurl you mean the hostname, yes ? (then say so, plase. The URL is the whole thing http://myurl/myapp/services/mywebservice?wsdl;.) but this fails http:// myurl/myapp/services?wsdl What is that space there ? if it is really there, then no wonder it fails. And /how/ does it fail ? it fails doesn't mean anything, technically speaking. but when on the local sever everything works. I see no errors in the log. It's like IIS is stopping the request?? Very carefully said : yes, it looks that way. Why, I have no idea. But at this point it does not look as if it has anything to do with the isapi_redirector. With the configuration which you show above, and as far as only isapi_redirector is concerned, all the URI's that (after the hostname part) start with /myapp, should be forwarded by IIS and isapi_redirector to Tomcat, and the isapi_redirector log should show that. It would be very strange if something at (or before) the IIS level was allowing URI's like http://myurl/myapp/services/mywebservice; to go through, but was blocking URI's like http://myurl/myapp/services;. But only you know what is in the configuration of that server, its firewall, etc.. Maybe services is something defined somewhere in IIS, and directed somewhere else (or forbidden) ? You need to design a test setup in which you can check this systematically. For example : Under the IIS wwwroot, create a sub-directory /myapp/, and put some document test.html there. Then with your browser, try to access http://yourhost/myapp/test.html. And note the result. Then create a sub-directory wwwroot/myapp/services/, put a document test2.html there, and try to access it, and note the result. etc.. Do this both from a browser on a separate workstation, and from a browser running on the IIS host itself. Then compare the results, and also look in the isapi_redirector logs. And then think. The answer is somewhere in the configuration of the browser, the network, the host, IIS, isapi_redirector or Tomcat. We do not have access to those things; but you do. You must make a list of what could be happening, and then design tests to rule out one or the other possibility. When you are left with only one, then that is the answer. And stop top-posting. OK Well thanks for the list etiquette lesson. I will setup a basic test with a clean website(removing all the extra stuff we have) and use a base configuration and work up from there. When I call the url via IE
Re: Jakarta ISAP Redirector
DeMarco, Alex wrote: ... OK Well thanks for the list etiquette lesson. Apart from the top-posting, it was not so much about list etiquette, as about expressing yourself precisely, so as to save some time to the people trying to help you. When you say my desktop, it is confusing, because you have a my desktop also when you are working directly on the webserver host. When you show a sample URL with a space in the middle and you say it doesn't work, we are left to wonder what doesn't work or why. Isolated, any one of these things can be overcome, but when you pile up 5 things like that in the same message, it is getting hard to figure out what is what. Basically, you want to be helped, and there are people here prepared to help. But if these people think that they'll have to spend 20 minutes first to ask you to correct typos or explain precisely what you mean by it fails, they will get discouraged and leave your message to be answered later, or by someone else. The result is that you get no answer, or get it later. So, be nice to yourself. ... When I call the url via IE directly on the webserver a log entry appears in the redirector log and the web service listing comes up correctly. Allright. That means that, when given a correct URL to fetch, IIS and Isapi_redirector and Tomcat do their job properly. By extrapolation, neither IIS nor Isapi_redirector nor Tomcat are refusing that URL with /myapp/services in it. Yet when I call the same URL from my (own workstation's) desktop no entry appears in the log and IIS returns a 404 as shown in firebug. By extrapolation again, it must be that when you do this from your own workstation, something happens to that URL, before it gets to IIS, that results in : - IIS + isapi_redirector not recognising that this URL matches one of the URL parts mentioned in the uriworkermap - so they do not forward it to Tomcat - in consequence, IIS is trying to serve it itself - and IIS does not find /myapp/services (or whatever it has become) in its own URL space (e.g. under wwwroot), so it returns a 404 Not Found. Now what happens to the URL, is for you to find out. Firebug is a good option, if you really check what is the complete dialog before you get the 404 error. It may be some re-direct, as mentioned by Rainer earlier. Check in Firebug if between the original request, and the 404, there is any 302 response coming back. If there is, then check what that 302 response says in its Location: header. Maybe for example it says http://localhost/;. That would work when you are on the webserver itself, but fail when you are on your workstation. (And it would fail with a 404 error if you also have IIS running on your workstation; if you don't have IIS running, then it should fail with some other error status.) In Firebug, there must be a way to copy a request/response sequence to the clipboard. If so, do that and paste it here. We might spot something you don't. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Jakarta ISAP Redirector
I hope this is the right place to post this question. We have the latest Jakarta Plugin installed with IIS 7.5. Do you know, does the plugin specifically block /services requests on wsdl's If I go here: http://myural/myapp/services I get a page not available However, if I am locally on the page the services listing does load. Also, if I go here from my desk: http://myural/myapp/services/someservicename?wsdl It works fine. In fact all the wsdl's work I just cannot display the services list remotely. Thanks in advance. - Alex
Re: Jakarta ISAP Redirector
DeMarco, Alex wrote: I hope this is the right place to post this question. It is the right place. We have the latest Jakarta Plugin installed with IIS 7.5. Do you know, does the plugin specifically block /services requests on wsdl's Short answer : no, it does not specifically block any request. In fact, it is the opposite : it only forwards requests to Tomcat, if the request URL matches some pre-defined values. See : http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html the section How does it work ?. (and for the word worker, understand a back-end tomcat). One more thing : the isapi_redirector can write a logfile. See item (3) in the section Configuring the ISAPI Redirector for details. The logfile will tell you when and why it is forwarding a request to Tomcat and when/why not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta ISAP Redirector
On 13 Jun 2012, at 18:18, DeMarco, Alex alex.dema...@suny.edu wrote: I hope this is the right place to post this question. We have the latest Jakarta Plugin installed with IIS 7.5. Do you know, does the plugin specifically block /services requests on wsdl's No, it doesn't. If I go here: http://myural/myapp/services I get a page not available Please post your config. p However, if I am locally on the page the services listing does load. Also, if I go here from my desk: http://myural/myapp/services/someservicename?wsdl It works fine. In fact all the wsdl's work I just cannot display the services list remotely. Thanks in advance. - Alex - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Jakarta ISAP Redirector
Yes I have looked in the log file and set it debug. There are no errors logged. My uriworkermap has this: /myapp=DTS_Submission /myapp/*=DTS_Submission My Workers file has: worker.list=DTS_Submission worker.DTS_Submission.type=ajp13 worker.DTS_Submission.host=xxx.xxx.xxx.xxx worker.DTS_Submission.port=3305 If I am locally on the box (with a local host entry that maps to the same IIS site on that box) it works fine. However, from my desktop I get a page could not be found... However, it says it can't find http://myurl:80/jakarta/isapi_redirect.dll I have double and triple checked my config. From my desktop this works: http://myurl/myapp/services/mywebservice?wsdl but this fails http:// myurl/myapp/services?wsdl but when on the local sever everything works. I see no errors in the log. It's like IIS is stopping the request?? - Alex -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Wednesday, June 13, 2012 2:18 PM To: Tomcat Users List Subject: Re: Jakarta ISAP Redirector DeMarco, Alex wrote: I hope this is the right place to post this question. It is the right place. We have the latest Jakarta Plugin installed with IIS 7.5. Do you know, does the plugin specifically block /services requests on wsdl's Short answer : no, it does not specifically block any request. In fact, it is the opposite : it only forwards requests to Tomcat, if the request URL matches some pre-defined values. See : http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html the section How does it work ?. (and for the word worker, understand a back-end tomcat). One more thing : the isapi_redirector can write a logfile. See item (3) in the section Configuring the ISAPI Redirector for details. The logfile will tell you when and why it is forwarding a request to Tomcat and when/why not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Jakarta ISAP Redirector
I have 4 servers all configured the same way.. Locally the call works fine yet remotely I get an iis 404 - Alex -Original Message- From: DeMarco, Alex [mailto:alex.dema...@suny.edu] Sent: Wednesday, June 13, 2012 8:45 PM To: Tomcat Users List Subject: RE: Jakarta ISAP Redirector Yes I have looked in the log file and set it debug. There are no errors logged. My uriworkermap has this: /myapp=DTS_Submission /myapp/*=DTS_Submission My Workers file has: worker.list=DTS_Submission worker.DTS_Submission.type=ajp13 worker.DTS_Submission.host=xxx.xxx.xxx.xxx worker.DTS_Submission.port=3305 If I am locally on the box (with a local host entry that maps to the same IIS site on that box) it works fine. However, from my desktop I get a page could not be found... However, it says it can't find http://myurl:80/jakarta/isapi_redirect.dll I have double and triple checked my config. From my desktop this works: http://myurl/myapp/services/mywebservice?wsdl but this fails http:// myurl/myapp/services?wsdl but when on the local sever everything works. I see no errors in the log. It's like IIS is stopping the request?? - Alex -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Wednesday, June 13, 2012 2:18 PM To: Tomcat Users List Subject: Re: Jakarta ISAP Redirector DeMarco, Alex wrote: I hope this is the right place to post this question. It is the right place. We have the latest Jakarta Plugin installed with IIS 7.5. Do you know, does the plugin specifically block /services requests on wsdl's Short answer : no, it does not specifically block any request. In fact, it is the opposite : it only forwards requests to Tomcat, if the request URL matches some pre-defined values. See : http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html the section How does it work ?. (and for the word worker, understand a back-end tomcat). One more thing : the isapi_redirector can write a logfile. See item (3) in the section Configuring the ISAPI Redirector for details. The logfile will tell you when and why it is forwarding a request to Tomcat and when/why not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2
On 18/05/2012 00:58, ann ramos wrote: Hi, I have set up our system to do SSO. The setup works fine because whenever the user access the system, they are automatically logged in to the system. Following are the steps that I used to set up Isapi: 1. Manually created the folders Apache Software Foundation\Jakarta Isapi Redirector. Then inside those folders I created a sub folder bin, conf and log. 2. I manually created the registry entries. The set up works because the system functions as SSO. The only thing is that my isapi_redirect.log is always empty even though I set the log_level to debug. I tried searching the internet but I'm not getting anywhere. I would appreciate any thoughts and ideas that you can share so I can resolve my problem. Thanks and regards. Peeves Small note, next time please start an entirely new thread - rather than replying to an existing one* and just editing the subject body. p * RE: Tomcat 4.0 Tomcat 6.0 AuthenticatorBase -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2
Sorry about that. So here's what I did. I created a webapps folder for our application in Tomcat. We're using IIS as the webserver, used the isapi redirector to make IIS and Tomcat interact. Followed the steps here: http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html So everything works fine. The user can access the application. I can see from the tomcat logs that our application is running. The only thing is my isapi log file is always empty. I never see any messages logged in there even though I set the log_level to debug. Regards. From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, 18 May 2012 5:18 PM Subject: Re: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2 ann ramos wrote: Hi, I have set up our system to do SSO. The setup works fine because whenever the user access the system, they are automatically logged in to the system. Following are the steps that I used to set up Isapi: 1. Manually created the folders Apache Software Foundation\Jakarta Isapi Redirector. Then inside those folders I created a sub folder bin, conf and log. 2. I manually created the registry entries. The set up works because the system functions as SSO. The only thing is that my isapi_redirect.log is always empty even though I set the log_level to debug. I tried searching the internet but I'm not getting anywhere. I would appreciate any thoughts and ideas that you can share so I can resolve my problem. Apart from your mention of Tomcat in the subject, it is not very clear so far if anything you're doing is accessing Tomcat through isapi_redirector (or even Tomcat at all). Can you be a bit more explicit about what you are doing ? And where the SSO part come into the picture here ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2
Silly question but does IIS have write permissions to the directory where you are writing the isapi log ? A -Original Message- From: ann ramos [mailto:ramos_mary...@yahoo.com] Sent: Monday, 21 May 2012 9:19 AM To: Tomcat Users List; Tomcat Users List Subject: Re: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2 Sorry about that. So here's what I did. I created a webapps folder for our application in Tomcat. We're using IIS as the webserver, used the isapi redirector to make IIS and Tomcat interact. Followed the steps here: http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html So everything works fine. The user can access the application. I can see from the tomcat logs that our application is running. The only thing is my isapi log file is always empty. I never see any messages logged in there even though I set the log_level to debug. Regards. From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, 18 May 2012 5:18 PM Subject: Re: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2 ann ramos wrote: Hi, I have set up our system to do SSO. The setup works fine because whenever the user access the system, they are automatically logged in to the system. Following are the steps that I used to set up Isapi: 1. Manually created the folders Apache Software Foundation\Jakarta Isapi Redirector. Then inside those folders I created a sub folder bin, conf and log. 2. I manually created the registry entries. The set up works because the system functions as SSO. The only thing is that my isapi_redirect.log is always empty even though I set the log_level to debug. I tried searching the internet but I'm not getting anywhere. I would appreciate any thoughts and ideas that you can share so I can resolve my problem. Apart from your mention of Tomcat in the subject, it is not very clear so far if anything you're doing is accessing Tomcat through isapi_redirector (or even Tomcat at all). Can you be a bit more explicit about what you are doing ? And where the SSO part come into the picture here ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2
Alex, you're a life-saver. I checked my set up and I noticed that SERVICE is not included in the list of users with read/write access. I added them and now my isapi log file is not empty anymore. Thanks heaps for your silly question. Thanks to everyone who has spent time looking at my problem. From: Alex Samad - Yieldbroker alex.sa...@yieldbroker.com To: Tomcat Users List users@tomcat.apache.org; ann ramos ramos_mary...@yahoo.com Sent: Monday, 21 May 2012 9:42 AM Subject: RE: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2 Silly question but does IIS have write permissions to the directory where you are writing the isapi log ? A -Original Message- From: ann ramos [mailto:ramos_mary...@yahoo.com] Sent: Monday, 21 May 2012 9:19 AM To: Tomcat Users List; Tomcat Users List Subject: Re: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2 Sorry about that. So here's what I did. I created a webapps folder for our application in Tomcat. We're using IIS as the webserver, used the isapi redirector to make IIS and Tomcat interact. Followed the steps here: http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html So everything works fine. The user can access the application. I can see from the tomcat logs that our application is running. The only thing is my isapi log file is always empty. I never see any messages logged in there even though I set the log_level to debug. Regards. From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, 18 May 2012 5:18 PM Subject: Re: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2 ann ramos wrote: Hi, I have set up our system to do SSO. The setup works fine because whenever the user access the system, they are automatically logged in to the system. Following are the steps that I used to set up Isapi: 1. Manually created the folders Apache Software Foundation\Jakarta Isapi Redirector. Then inside those folders I created a sub folder bin, conf and log. 2. I manually created the registry entries. The set up works because the system functions as SSO. The only thing is that my isapi_redirect.log is always empty even though I set the log_level to debug. I tried searching the internet but I'm not getting anywhere. I would appreciate any thoughts and ideas that you can share so I can resolve my problem. Apart from your mention of Tomcat in the subject, it is not very clear so far if anything you're doing is accessing Tomcat through isapi_redirector (or even Tomcat at all). Can you be a bit more explicit about what you are doing ? And where the SSO part come into the picture here ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2
Pretty sure if you look back in the mailing list logs, I asked the same question :) A -Original Message- From: ann ramos [mailto:ramos_mary...@yahoo.com] Sent: Monday, 21 May 2012 1:28 PM To: Tomcat Users List Subject: Re: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2 Alex, you're a life-saver. I checked my set up and I noticed that SERVICE is not included in the list of users with read/write access. I added them and now my isapi log file is not empty anymore. Thanks heaps for your silly question. Thanks to everyone who has spent time looking at my problem. From: Alex Samad - Yieldbroker alex.sa...@yieldbroker.com To: Tomcat Users List users@tomcat.apache.org; ann ramos ramos_mary...@yahoo.com Sent: Monday, 21 May 2012 9:42 AM Subject: RE: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2 Silly question but does IIS have write permissions to the directory where you are writing the isapi log ? A -Original Message- From: ann ramos [mailto:ramos_mary...@yahoo.com] Sent: Monday, 21 May 2012 9:19 AM To: Tomcat Users List; Tomcat Users List Subject: Re: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2 Sorry about that. So here's what I did. I created a webapps folder for our application in Tomcat. We're using IIS as the webserver, used the isapi redirector to make IIS and Tomcat interact. Followed the steps here: http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html So everything works fine. The user can access the application. I can see from the tomcat logs that our application is running. The only thing is my isapi log file is always empty. I never see any messages logged in there even though I set the log_level to debug. Regards. From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, 18 May 2012 5:18 PM Subject: Re: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2 ann ramos wrote: Hi, I have set up our system to do SSO. The setup works fine because whenever the user access the system, they are automatically logged in to the system. Following are the steps that I used to set up Isapi: 1. Manually created the folders Apache Software Foundation\Jakarta Isapi Redirector. Then inside those folders I created a sub folder bin, conf and log. 2. I manually created the registry entries. The set up works because the system functions as SSO. The only thing is that my isapi_redirect.log is always empty even though I set the log_level to debug. I tried searching the internet but I'm not getting anywhere. I would appreciate any thoughts and ideas that you can share so I can resolve my problem. Apart from your mention of Tomcat in the subject, it is not very clear so far if anything you're doing is accessing Tomcat through isapi_redirector (or even Tomcat at all). Can you be a bit more explicit about what you are doing ? And where the SSO part come into the picture here ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2
ann ramos wrote: Hi, I have set up our system to do SSO. The setup works fine because whenever the user access the system, they are automatically logged in to the system. Following are the steps that I used to set up Isapi: 1. Manually created the folders Apache Software Foundation\Jakarta Isapi Redirector. Then inside those folders I created a sub folder bin, conf and log. 2. I manually created the registry entries. The set up works because the system functions as SSO. The only thing is that my isapi_redirect.log is always empty even though I set the log_level to debug. I tried searching the internet but I'm not getting anywhere. I would appreciate any thoughts and ideas that you can share so I can resolve my problem. Apart from your mention of Tomcat in the subject, it is not very clear so far if anything you're doing is accessing Tomcat through isapi_redirector (or even Tomcat at all). Can you be a bit more explicit about what you are doing ? And where the SSO part come into the picture here ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Isapi redirector log file is always empty - IIS 7.5 - Tomcat 7.0.26 - Isapi 1.2.30 - Win2008 R2
Hi, I have set up our system to do SSO. The setup works fine because whenever the user access the system, they are automatically logged in to the system. Following are the steps that I used to set up Isapi: 1. Manually created the folders Apache Software Foundation\Jakarta Isapi Redirector. Then inside those folders I created a sub folder bin, conf and log. 2. I manually created the registry entries. The set up works because the system functions as SSO. The only thing is that my isapi_redirect.log is always empty even though I set the log_level to debug. I tried searching the internet but I'm not getting anywhere. I would appreciate any thoughts and ideas that you can share so I can resolve my problem. Thanks and regards. Peeves
Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
On 03/20/2012 06:55 AM, Alex Samad - Yieldbroker wrote: You should 1. Create a separate 'Unmanaged' application pool for isapi_redirect 2. Disable recycling for that pool 3. Have multiple vhost mapping inside uriworkermap.properties instead having multiple configuration files and instances for each vhost. 4. Use a single process for that pool. Okay I can see that Our original thinking was if we separate prd and uat, they could not affect each other. Sure that's probably the only reason to have multiple instances and pools. However this still does not require multiple worker processes or recycling. :) true, but I don't believe the above is true on IIS/Windows. The think I am unsure on is how the connector uses the shared memory If its index (?) by the name of the worker thread or loadbalancer name then there will be a problem. I have the same config in UAT and PRD.. and thus the same worker names and load balancer names You will need to have /jakarta inside different 'Site' and each site bound to its own AppPool. Shared memory is constructed from site name, so for example for 'Default Web Site' it becomes something like JK_LOCALHOST_1_... Suppose you have that separated already between production and staging. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
-Original Message- From: Mladen Turk [mailto:mt...@apache.org] Sent: Tuesday, 20 March 2012 5:57 PM To: users@tomcat.apache.org Subject: Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 On 03/20/2012 06:55 AM, Alex Samad - Yieldbroker wrote: You should 1. Create a separate 'Unmanaged' application pool for isapi_redirect 2. Disable recycling for that pool 3. Have multiple vhost mapping inside uriworkermap.properties instead having multiple configuration files and instances for each vhost. 4. Use a single process for that pool. Okay I can see that Our original thinking was if we separate prd and uat, they could not affect each other. Sure that's probably the only reason to have multiple instances and pools. However this still does not require multiple worker processes or recycling. Yep, I think the recycling and worker process was a hangover from the move from weblogic to tomcat (and iis 6.x) :) true, but I don't believe the above is true on IIS/Windows. The think I am unsure on is how the connector uses the shared memory If its index (?) by the name of the worker thread or loadbalancer name then there will be a problem. I have the same config in UAT and PRD.. and thus the same worker names and load balancer names You will need to have /jakarta inside different 'Site' and each site bound to its own AppPool. yep Shared memory is constructed from site name, so for example for 'Default Web Site' it becomes something like JK_LOCALHOST_1_... Suppose you have that separated already between production and staging. Yep So on the NLB / RP I have C:\ABC\ENV Each env has \wwwroot \apjconfig \other stuff Apjconfig has the dll and the configs Each environment has its own virtual site and each site has its own application pool Thanks very much for your help on this Alex Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
On 03/19/2012 12:00 AM, Alex Samad - Yieldbroker wrote: Hi Sorry it failed for me, started up, but I got some error messages [Mon Mar 19 09:43:13.970 2012] [2096:2984] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer This is caused by unable to allocate the buffer. Now, it seems either memory is exhausted or shared memory still wrong (I recon its later) [Mon Mar 19 09:49:52.489 2012] [5804:5836] [trace] jk_shm_open::jk_shm.c (158): enter [Mon Mar 19 09:49:52.489 2012] [5804:5836] [debug] jk_shm_open::jk_shm.c (305): Initialized shared memory Global\JK_DEV_YIELDBROKER_COM_2_JAKARTA_ISAPI_REDIRECT size=1856 free=1728 addr=0x1f [Mon Mar 19 09:49:52.489 2012] [5804:5836] [trace] jk_shm_open::jk_shm.c (311): exit [Mon Mar 19 09:49:52.504 2012] [5804:5836] [trace] jk_shm_open::jk_shm.c (158): enter [Mon Mar 19 09:49:52.504 2012] [5804:5836] [debug] jk_shm_open::jk_shm.c (166): Shared memory is already opened [Mon Mar 19 09:49:52.504 2012] [5804:5836] [trace] jk_shm_open::jk_shm.c (167): exit That's weird. jk_shm_open gets called twice from the same process/thread. Could you send me some more log data surrounding those two calls so I can figure out from where init_jk was called. Please use the newest build (#6) from http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.34/ Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
On 03/19/2012 12:00 AM, Alex Samad - Yieldbroker wrote: Hi [Mon Mar 19 09:43:53.266 2012] [2516:1892] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer Please use the newest build (#8) from http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.34/ There was a bug in shared memory sync caused by attaching new process while there was request pending In general caused by 'generation in future'. Now the shared memory is synced only if we are below the shared sequence. I have verified locally that it works now and no more those alloc failed errors (as well as none of the earlier one :) Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
Hi Thanks, looks like this one is the winner ! Alex -Original Message- From: Mladen Turk [mailto:mt...@apache.org] Sent: Tuesday, 20 March 2012 1:43 AM To: Tomcat Users List Cc: Alex Samad - Yieldbroker Subject: Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 On 03/19/2012 12:00 AM, Alex Samad - Yieldbroker wrote: Hi [Mon Mar 19 09:43:53.266 2012] [2516:1892] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer Please use the newest build (#8) from http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.34/ There was a bug in shared memory sync caused by attaching new process while there was request pending In general caused by 'generation in future'. Now the shared memory is synced only if we are below the shared sequence. I have verified locally that it works now and no more those alloc failed errors (as well as none of the earlier one :) Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
Hi Mladen Q) can I presume that this new version will not interfere with an old version 1.2.32 ? as the mutex name used in this new one 1.2.34 wasn't used in 1.2.32 ? Alex -Original Message- From: Alex Samad - Yieldbroker [mailto:alex.sa...@yieldbroker.com] Sent: Tuesday, 20 March 2012 11:13 AM To: Tomcat Users List Subject: RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 Hi Thanks, looks like this one is the winner ! Alex -Original Message- From: Mladen Turk [mailto:mt...@apache.org] Sent: Tuesday, 20 March 2012 1:43 AM To: Tomcat Users List Cc: Alex Samad - Yieldbroker Subject: Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 On 03/19/2012 12:00 AM, Alex Samad - Yieldbroker wrote: Hi [Mon Mar 19 09:43:53.266 2012] [2516:1892] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer Please use the newest build (#8) from http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.34/ There was a bug in shared memory sync caused by attaching new process while there was request pending In general caused by 'generation in future'. Now the shared memory is synced only if we are below the shared sequence. I have verified locally that it works now and no more those alloc failed errors (as well as none of the earlier one :) Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org B CB [ X ܚX KK[XZ[ \ \ ][ X ܚX P X ] \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ \ \ Z[ X ] \X K ܙ B
RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
-Original Message- From: Alex Samad - Yieldbroker [mailto:alex.sa...@yieldbroker.com] [snip] Hi Mladen Q) can I presume that this new version will not interfere with an old version 1.2.32 ? as the mutex name used in this new one 1.2.34 wasn't used in 1.2.32 ? This has me thinking and think I have found another bug. :) Our setup is IIS 7.5 setup as a Reverse proxy. We run PRD, UAT through here. Trying to treat this an infrastructure box. We have 2 in a NLB setup For each environment I have a separate web server and directory setup so C:\ABC\ Prod\ Ajpconfig\ UAT\ Ajpconfig\ In each environment I have a ajpconfig directory where I put my dll and I keep all my config files for just that environment. The idea was that I could have different version of the tomcat connector thus test stuff out in UAT and then move on to PRD. BUT there is no way to set the name space used in the tomcat connector in relation to the Shared Memory or to semaphore. So Global\\JK_ISAPI_REDIRECT_MUTEX is used by all tomcat connectors (the ones in prod and the ones in UAT) And I would presume the Shared Memory would also be shared between the 2 ? Quote from the doco ! The ISAPI redirector can read it's configuration from a properties file instead of the registry. This has the advantage that you can use multiple ISAPI redirectors with independent configurations on the same server. The redirector will check for the properties file during initialisation, and use it in preference to the registry if present. You can't do this with the IIS connector and with multiple processes (web gardens)! Could I make a bug/feature request to add something like Shm_namespace To the isapi_redirect.properties file and have this value post fixed to the shared memory name and the semaphore handle... Doesn't make sense if configured via the registry I have create a bugzilla for this https://issues.apache.org/bugzilla/show_bug.cgi?id=52947 basically outlining what I have here. The one thing I am not sure of is how much of a problem that is... The config files for uat and prd have different tomcat destinations, but the load balancer and worker names are the same !! The pathing is different though The previous bug which I think this version fixes is https://issues.apache.org/bugzilla/show_bug.cgi?id=52659 which I guess can be closed Thanks Alex -Original Message- From: Alex Samad - Yieldbroker [mailto:alex.sa...@yieldbroker.com] [snip] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
On 03/20/2012 02:01 AM, Alex Samad - Yieldbroker wrote: This has me thinking and think I have found another bug. :) Our setup is IIS 7.5 setup as a Reverse proxy. We run PRD, UAT through here. Trying to treat this an infrastructure box. We have 2 in a NLB setup For each environment I have a separate web server and directory setup so C:\ABC\ Prod\ Ajpconfig\ UAT\ Ajpconfig\ In each environment I have a ajpconfig directory where I put my dll and I keep all my config files for just that environment. The idea was that I could have different version of the tomcat connector thus test stuff out in UAT and then move on to PRD. BUT there is no way to set the name space used in the tomcat connector in relation to the Shared Memory or to semaphore. So Global\\JK_ISAPI_REDIRECT_MUTEX is used by all tomcat connectors (the ones in prod and the ones in UAT) Yes, but thats used only inside jk_init and locks for 1ms during new worker process creation while the isapi_redirect gets loaded to memory. Like explained in BZ52659 you have things conceptually wrong. isapi_redirect is proxy, it does its own connection pool management, recycling, virtual host mapping handling etc. You should 1. Create a separate 'Unmanaged' application pool for isapi_redirect 2. Disable recycling for that pool 3. Have multiple vhost mapping inside uriworkermap.properties instead having multiple configuration files and instances for each vhost. 4. Use a single process for that pool. You can eventually have two separate pools (one for testing and other for production) And I would presume the Shared Memory would also be shared between the 2 ? Quote from the doco ! The ISAPI redirector can read it's configuration from a properties file instead of the registry. This has the advantage that you can use multiple ISAPI redirectors with independent configurations on the same server. The redirector will check for the properties file during initialisation, and use it in preference to the registry if present. If something is possible it doesn't mean you should use it in production and in all cases. You can't do this with the IIS connector and with multiple processes (web gardens)! Again, you should think 'differently' Entire IIS worker process recycling is meant for handling crappy .NET applications with memory and resource leaks. isapi_redirect is proxy, nothing else, nothing more. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
-Original Message- From: Mladen Turk [mailto:mt...@apache.org] Sent: Tuesday, 20 March 2012 4:09 PM To: users@tomcat.apache.org Subject: Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 On 03/20/2012 02:01 AM, Alex Samad - Yieldbroker wrote: This has me thinking and think I have found another bug. :) Our setup is IIS 7.5 setup as a Reverse proxy. We run PRD, UAT through here. Trying to treat this an infrastructure box. We have 2 in a NLB setup For each environment I have a separate web server and directory setup so C:\ABC\ Prod\ Ajpconfig\ UAT\ Ajpconfig\ In each environment I have a ajpconfig directory where I put my dll and I keep all my config files for just that environment. The idea was that I could have different version of the tomcat connector thus test stuff out in UAT and then move on to PRD. BUT there is no way to set the name space used in the tomcat connector in relation to the Shared Memory or to semaphore. So Global\\JK_ISAPI_REDIRECT_MUTEX is used by all tomcat connectors (the ones in prod and the ones in UAT) Yes, but thats used only inside jk_init and locks for 1ms during new worker process creation while the isapi_redirect gets loaded to memory. Like explained in BZ52659 you have things conceptually wrong. isapi_redirect is proxy, it does its own connection pool management, recycling, virtual host mapping handling etc. I'm a linux guy stuck in a MS world :) You should 1. Create a separate 'Unmanaged' application pool for isapi_redirect 2. Disable recycling for that pool 3. Have multiple vhost mapping inside uriworkermap.properties instead having multiple configuration files and instances for each vhost. 4. Use a single process for that pool. Okay I can see that Our original thinking was if we separate prd and uat, they could not affect each other. Say for example right now where I want to test the new connector I have tested on dev, but the spec of the machine is not the same as the prod/uat setup I can't have separating logging all the prd/uat/sim will go into 1 set of files Apart for the separation of prod and testing Minor. You can eventually have two separate pools (one for testing and other for production) And I would presume the Shared Memory would also be shared between the 2 ? Quote from the doco ! The ISAPI redirector can read it's configuration from a properties file instead of the registry. This has the advantage that you can use multiple ISAPI redirectors with independent configurations on the same server. The redirector will check for the properties file during initialisation, and use it in preference to the registry if present. If something is possible it doesn't mean you should use it in production and in all cases. :) true, but I don't believe the above is true on IIS/Windows. The think I am unsure on is how the connector uses the shared memory If its index (?) by the name of the worker thread or loadbalancer name then there will be a problem. I have the same config in UAT and PRD.. and thus the same worker names and load balancer names If its worker name and dest server ip (this I believe to be more likely) then it should be okay... You can't do this with the IIS connector and with multiple processes (web gardens)! Again, you should think 'differently' Entire IIS worker process recycling is meant for handling crappy .NET applications with memory and resource leaks. isapi_redirect is proxy, nothing else, nothing more. Yep understand, it was out tool for invoking this bug, as it also happened upon reboot of the server or restart of IIS Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
On 03/16/2012 04:27 PM, Konstantin Preißer wrote: Hi all, I have a system with Windows Server 2008 32 bit, IIS 7.0, Java 1.7.0_03, Tomcat 7.0.26 and the ISAPI redirector. Guys, Please try the binaries from: http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.34/ They contain two fixes: 1. Make sure we fallback to heap memory in case shared cannot be created 2. Fix shared memory create/open arguments The point is that is that we should have correct [error] log entries in case shared memory open fails. If it fails you should have [warn] line, load balancer will not function properly across multiple processes (will inside each of the process) but it shouldn't crash. I'd appreciate if you can check that ASAP cause we have regression in httpd implementation so new version will be out in couple of days. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
Hello Mladen, -Original Message- From: Mladen Turk [mailto:mt...@apache.org] Sent: Sunday, March 18, 2012 8:46 AM To: users@tomcat.apache.org Cc: verlag.preis...@t-online.de; alex.sa...@yieldbroker.com Subject: Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 Guys, Please try the binaries from: http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.34/ They contain two fixes: 1. Make sure we fallback to heap memory in case shared cannot be created 2. Fix shared memory create/open arguments The point is that is that we should have correct [error] log entries in case shared memory open fails. If it fails you should have [warn] line, load balancer will not function properly across multiple processes (will inside each of the process) but it shouldn't crash. Thank you very much. I tried the new version, and now when the Application Pool is recycled, the logs show these: [Sun Mar 18 12:10:36.324 2012] [4144:6216] [error] jk_shm_open::jk_shm.c (220): Failed to map shared memory JK_TTWEBINFO_DYNDNS_ORG_8_JAKARTA2_ISAPI_REDIRECT with errno=87 [Sun Mar 18 12:10:36.337 2012] [4144:6216] [error] init_jk::jk_isapi_plugin.c (2801): Initializing shm:(null) errno=87. Load balancer will not work properly! But w3wp.exe doesn't crash anymore, so I think it is fixed. (I'm wondering now why mapping the shared memory fails..) Thanks, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
On 03/18/2012 12:16 PM, Konstantin Preißer wrote: Hello Mladen, Thank you very much. I tried the new version, and now when the Application Pool is recycled, the logs show these: [Sun Mar 18 12:10:36.324 2012] [4144:6216] [error] jk_shm_open::jk_shm.c (220): Failed to map shared memory JK_TTWEBINFO_DYNDNS_ORG_8_JAKARTA2_ISAPI_REDIRECT with errno=87 [Sun Mar 18 12:10:36.337 2012] [4144:6216] [error] init_jk::jk_isapi_plugin.c (2801): Initializing shm:(null) errno=87. Load balancer will not work properly! But w3wp.exe doesn't crash anymore, so I think it is fixed. (I'm wondering now why mapping the shared memory fails..) Thanks for looking at this promptly! Could you try with the new builds http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.34/ (isapi_redirect_1.2.34_2-dev_winXX.zip) I added Global\\ prefix to shared memory name so that it can be shared from multiple processes. Also check if the errno changed from 87 (ERROR_INVALID_PARAMETER) Thanks -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
On 03/18/2012 02:34 PM, Mladen Turk wrote: On 03/18/2012 12:16 PM, Konstantin Preißer wrote: Hello Mladen, Thank you very much. I tried the new version, and now when the Application Pool is recycled, the logs show these: [Sun Mar 18 12:10:36.324 2012] [4144:6216] [error] jk_shm_open::jk_shm.c (220): Failed to map shared memory JK_TTWEBINFO_DYNDNS_ORG_8_JAKARTA2_ISAPI_REDIRECT with errno=87 [Sun Mar 18 12:10:36.337 2012] [4144:6216] [error] init_jk::jk_isapi_plugin.c (2801): Initializing shm:(null) errno=87. Load balancer will not work properly! But w3wp.exe doesn't crash anymore, so I think it is fixed. (I'm wondering now why mapping the shared memory fails..) Thanks for looking at this promptly! Could you try with the new builds http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.34/ (isapi_redirect_1.2.34_2-dev_winXX.zip) Forget about that one. I'll create a new one in 20 minutes Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
On 03/18/2012 02:40 PM, Mladen Turk wrote: On 03/18/2012 02:34 PM, Mladen Turk wrote: On 03/18/2012 12:16 PM, Konstantin Preißer wrote: Hello Mladen, Thank you very much. I tried the new version, and now when the Application Pool is recycled, the logs show these: [Sun Mar 18 12:10:36.324 2012] [4144:6216] [error] jk_shm_open::jk_shm.c (220): Failed to map shared memory JK_TTWEBINFO_DYNDNS_ORG_8_JAKARTA2_ISAPI_REDIRECT with errno=87 [Sun Mar 18 12:10:36.337 2012] [4144:6216] [error] init_jk::jk_isapi_plugin.c (2801): Initializing shm:(null) errno=87. Load balancer will not work properly! But w3wp.exe doesn't crash anymore, so I think it is fixed. (I'm wondering now why mapping the shared memory fails..) Thanks for looking at this promptly! Could you try with the new builds http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.34/ (isapi_redirect_1.2.34_2-dev_winXX.zip) Please use isapi_redirect_1.2.34_3-dev_winXX.zip instead. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
Hi Mladen, -Original Message- From: Mladen Turk [mailto:mt...@apache.org] Sent: Sunday, March 18, 2012 2:54 PM To: Tomcat Users List Subject: Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 Please use isapi_redirect_1.2.34_3-dev_winXX.zip instead. Thank you. I tried with isapi_redirect_1.2.34_3-dev_win32.zip, but unfortunately it seems that it causes w3wp.exe to crash again :( Logs: [Sun Mar 18 15:05:48.648 2012] [7588:5124] [error] ajp_worker_factory::jk_ajp_common.c (3006): allocating ajp worker record from shared memory [Sun Mar 18 15:05:48.661 2012] [7588:5124] [error] wc_create_worker::jk_worker.c (150): factory for ajp13 failed for worker1 [Sun Mar 18 15:05:48.669 2012] [7588:5124] [error] build_worker_map::jk_worker.c (261): failed to create worker worker1 [Sun Mar 18 15:05:48.677 2012] [7588:5124] [error] extension_fix::jk_uri_worker_map.c (554): Could not find worker with name 'worker1' in uri map post processing. Thanks, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
On 03/18/2012 03:11 PM, Konstantin Preißer wrote: Hi Mladen, -Original Message- From: Mladen Turk [mailto:mt...@apache.org] Sent: Sunday, March 18, 2012 2:54 PM To: Tomcat Users List Subject: Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 Please use isapi_redirect_1.2.34_3-dev_winXX.zip instead. Thank you. I tried with isapi_redirect_1.2.34_3-dev_win32.zip, but unfortunately it seems that it causes w3wp.exe to crash again :( Could you please try the isapi_redirect_1.2.34_5-dev_win32.zip If this one crashes we'll have to add some override to shared memory so we can fallback to heap one and bypass memory corruption which seems to occur at IIS worker recycle. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
On 03/18/2012 08:30 PM, Alex Samad - Yieldbroker wrote: Hi Guys (Konstantin, Mladen), goo d work, sorry caught me on a Sunday, else I would have chipped in. Just wondering (thinking a bit left field), but question was asked of me. Any reason to have a shm across processes. So that worker state is replicated across processes. Eg, if connection to one backend is broken each process will have to discover that by itself. Shared memory allows that if one worker process discovers that a backend is down other won't have to go trough the lengthy process of discovering that. Also loadbalancer load factors are calculated across all processes not just for the current one. So, the benefits are real. However unlike with httpd, IIS does not offer parent/child concept so we don't have the shared memory 'controller'. The ultimate solution would be to start a separate controller process, but that's probably something for the future. Even if the current set of patches work, I'm more convinced we should have a directive to disable shared memory usage, and think I'm going to add that option for 1.2.34 anyhow. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
[snip] Just wondering (thinking a bit left field), but question was asked of me. Any reason to have a shm across processes. So that worker state is replicated across processes. Eg, if connection to one backend is broken each process will have to discover that by itself. Shared memory allows that if one worker process discovers that a backend is down other won't have to go trough the lengthy process of discovering that. Also loadbalancer load factors are calculated across all processes not just for the current one. So, the benefits are real. Not deny that, just thinking out aloud, also been asking myself if there is any reason to run a 4 process web garden. The only benefit I can see is that if 1 process dies there will be other process to continue processing. 1 process + threads v's X processes + threads However unlike with httpd, IIS does not offer parent/child concept so we don't have the shared memory 'controller'. The ultimate solution would be to start a separate controller process, but that's probably something for the future. Even if the current set of patches work, I'm more convinced we should have a directive to disable shared memory usage, and think I'm going to add that option for 1.2.34 anyhow. So would that effectively do what I was suggesting above ? Thanks Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
-Original-Nachricht- Von: Mladen Turk mt...@apache.org An: users@tomcat.apache.org Betreff: Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 Datum: Sun, 18 Mar 2012 18:39:15 +0100 Could you please try the isapi_redirect_1.2.34_5-dev_win32.zip If this one crashes we'll have to add some override to shared memory so we can fallback to heap one and bypass memory corruption which seems to occur at IIS worker recycle. Hi Mladen, thank you, I tried isapi_redirect_1.2.34_5-dev_win32.zip and so far no crashes, and also no warnings/errors in the ISAPI log. It seems the issue is fixed now. Thanks, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
On 03/18/2012 09:34 PM, verlag.preis...@t-online.de wrote: -Original-Nachricht- Von: Mladen Turkmt...@apache.org An: users@tomcat.apache.org Betreff: Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 Datum: Sun, 18 Mar 2012 18:39:15 +0100 Could you please try the isapi_redirect_1.2.34_5-dev_win32.zip If this one crashes we'll have to add some override to shared memory so we can fallback to heap one and bypass memory corruption which seems to occur at IIS worker recycle. Hi Mladen, thank you, I tried isapi_redirect_1.2.34_5-dev_win32.zip and so far no crashes, and also no warnings/errors in the ISAPI log. It seems the issue is fixed now. Cool. Thanks again for testing those. We'll release 1.2.34 by the end of this week probably. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
Hi Sorry it failed for me, started up, but I got some error messages I have 4 processes setup for non-overlapping recycle Log 1 Log 2 [Mon Mar 19 09:43:13.970 2012] [2096:2984] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer [Mon Mar 19 09:43:13.986 2012] [2096:2984] [error] HttpExtensionProc::jk_isapi_plugin.c (2325): service() failed with http error 500 [Mon Mar 19 09:43:14.079 2012] [2096:2984] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer [Mon Mar 19 09:43:14.079 2012] [2096:2984] [error] HttpExtensionProc::jk_isapi_plugin.c (2325): service() failed with http error 500 [Mon Mar 19 09:43:53.453 2012] [2096:2288] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer [Mon Mar 19 09:43:53.453 2012] [2096:2288] [error] HttpExtensionProc::jk_isapi_plugin.c (2325): service() failed with http error 500 Log3 [Mon Mar 19 09:43:53.359 2012] [3388:2244] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer [Mon Mar 19 09:43:53.359 2012] [3388:2244] [error] HttpExtensionProc::jk_isapi_plugin.c (2325): service() failed with http error 500 [Mon Mar 19 09:43:53.391 2012] [3388:2276] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer [Mon Mar 19 09:43:53.391 2012] [3388:2276] [error] HttpExtensionProc::jk_isapi_plugin.c (2325): service() failed with http error 500 [Mon Mar 19 09:43:53.484 2012] [3388:2244] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer [Mon Mar 19 09:43:53.484 2012] [3388:2244] [error] HttpExtensionProc::jk_isapi_plugin.c (2325): service() failed with http error 500 Log4 [Mon Mar 19 09:43:53.266 2012] [2516:1892] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer [Mon Mar 19 09:43:53.313 2012] [2516:1892] [error] HttpExtensionProc::jk_isapi_plugin.c (2325): service() failed with http error 500 [Mon Mar 19 09:43:53.359 2012] [2516:2776] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer [Mon Mar 19 09:43:53.359 2012] [2516:2776] [error] HttpExtensionProc::jk_isapi_plugin.c (2325): service() failed with http error 500 [Mon Mar 19 09:43:53.500 2012] [2516:2776] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer [Mon Mar 19 09:43:53.547 2012] [2516:2776] [error] HttpExtensionProc::jk_isapi_plugin.c (2325): service() failed with http error 500 I started IIS, used my client app to connect.. that worked well, only 4 connects, then started my stress test, with 500 users. Basically 500 users connecting to IIS. Failed with these errors. Using performance monitor I can see that the number of ISAPI Extension requests is increasing I turned on trace ( I can send you the files if you needed) and it seemed to work okay (I wonder if the serialisation into logging has something to do with it ! Found these [Mon Mar 19 09:49:52.489 2012] [5804:5836] [trace] jk_shm_open::jk_shm.c (158): enter [Mon Mar 19 09:49:52.489 2012] [5804:5836] [debug] jk_shm_open::jk_shm.c (305): Initialized shared memory Global\JK_DEV_YIELDBROKER_COM_2_JAKARTA_ISAPI_REDIRECT size=1856 free=1728 addr=0x1f [Mon Mar 19 09:49:52.489 2012] [5804:5836] [trace] jk_shm_open::jk_shm.c (311): exit [Mon Mar 19 09:49:52.504 2012] [5804:5836] [trace] jk_shm_open::jk_shm.c (158): enter [Mon Mar 19 09:49:52.504 2012] [5804:5836] [debug] jk_shm_open::jk_shm.c (166): Shared memory is already opened [Mon Mar 19 09:49:52.504 2012] [5804:5836] [trace] jk_shm_open::jk_shm.c (167): exit [Mon Mar 19 09:49:52.504 2012] [5804:5836] [trace] wc_open::jk_worker.c (50): enter [Mon Mar 19 09:49:52.504 2012] [5804:5836] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.maintain' - '60' I still have a lot of stale ISAPA extension request's I have tried to restart IIS, whilst my client is trying to talk over 500 connections, with failed request tracking on I get 500/200 ? Notification 128 Internal Server Error Only 1 of the 4 logs files has this is there [Mon Mar 19 09:58:27.878 2012] [2620:4636] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer [Mon Mar 19 09:58:27.894 2012] [2620:4636] [error] HttpExtensionProc::jk_isapi_plugin.c (2325): service() failed with http error 500 [Mon Mar 19 09:58:27.910 2012] [2620:4636] [error] service::jk_lb_worker.c (1172): Failed allocating AJP message buffer [Mon Mar 19 09:58:27.910 2012] [2620:4636] [error] HttpExtensionProc::jk_isapi_plugin.c (2325): service() failed with http error 500 Thanks Alex -Original Message- From: Mladen Turk [mailto:mt...@apache.org] Sent: Monday, 19 March 2012 8:34 AM To: users@tomcat.apache.org Subject: Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 On 03/18/2012 09:34 PM, verlag.preis...@t-online.de wrote: -Original-Nachricht- Von: Mladen Turkmt...@apache.org An: users@tomcat.apache.org Betreff: Re: IIS
IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
Hi all, I have a system with Windows Server 2008 32 bit, IIS 7.0, Java 1.7.0_03, Tomcat 7.0.26 and the ISAPI redirector. Since I updated the ISAPI redirector from 1.2.32 to 1.2.33, it seems that each time when IIS tries to recycle its application pool, the IIS worker process (w3wp.exe) crashes in isapi_redirect.dll. In the event log, an Application Error of w3wp.exe is logged (here is an English translation): Faulty application w3wp.exe, Version 7.0.6002.18005, time stamp 0x49e023cf, faulty module isapi_redirect.dll, Version 1.2.33.0, time stamp 0x4f59be7d, exception code 0xc005, error offset 0x0002bb16, process ID 0x10f0, application start time 01cd0336e5b7824a. (The process ID does not match the one of w3wp.exe before the crash, nor the one after the crash, so it seems a bit like when the new w3wp.exe is launched after recycle, it crashes and immediately another w3wp.exe is started). In the ISAPI log, following lines appear when w3wp.exe crashes: [Fri Mar 16 06:37:38.402 2012] [4336:6828] [error] ajp_worker_factory::jk_ajp_common.c (3006): allocating ajp worker record from shared memory [Fri Mar 16 06:37:38.417 2012] [4336:6828] [error] wc_create_worker::jk_worker.c (150): factory for ajp13 failed for worker1 [Fri Mar 16 06:37:38.426 2012] [4336:6828] [error] build_worker_map::jk_worker.c (261): failed to create worker worker1 [Fri Mar 16 06:37:38.434 2012] [4336:6828] [error] extension_fix::jk_uri_worker_map.c (554): Could not find worker with name 'worker1' in uri map post processing. Any idea what these lines could mean / that caused them? Note that it seems that after the crash (when a new w3wp.exe is created), pages are served fine again (though I do not know what happens with request that are made exactly in the time when IIS resets the app pool). The crashes and these log lines didn't appear in ISAPI 1.2.32. I think I read somewhere in the thread Issues with the tomcat connector (On W2k8 + IIS7.5) about some change in the ISAPI connector which has to do with shared memory, but I'm not sure. Thanks! Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
Any idea what these lines could mean / that caused them? Note that it seems that after the crash (when a new w3wp.exe is created), pages are served fine again (though I do not know what happens with request that are made exactly in the time when IIS resets the app pool). The crashes and these log lines didn't appear in ISAPI 1.2.32. Sorry, forgot to post my configuration: uriworkersmap.properties: /*=worker1 workers.properties: # Define 1 real worker using ajp13 worker.list=worker1 # Set properties for worker1 (ajp13) worker.worker1.type=ajp13 worker.worker1.host=localhost worker.worker1.port=8019 Thanks, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
-Original Message- From: Konstantin Preißer [mailto:verlag.preis...@t-online.de] Sent: Saturday, 17 March 2012 2:31 AM To: 'Tomcat Users List' Subject: RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 Any idea what these lines could mean / that caused them? Note that it seems that after the crash (when a new w3wp.exe is created), pages are served fine again (though I do not know what happens with request that are made exactly in the time when IIS resets the app pool). The crashes and these log lines didn't appear in ISAPI 1.2.32. Hi 1.2.32 was doing that for me.. 1.2.33 was meant to fix it, but I can't get 1.2.33 to load. Do you use overlapping recycle and a web garden ? Alex Sorry, forgot to post my configuration: uriworkersmap.properties: /*=worker1 workers.properties: # Define 1 real worker using ajp13 worker.list=worker1 # Set properties for worker1 (ajp13) worker.worker1.type=ajp13 worker.worker1.host=localhost worker.worker1.port=8019 Thanks, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
Hi Alex, -Original Message- From: Alex Samad - Yieldbroker [mailto:alex.sa...@yieldbroker.com] Sent: Friday, March 16, 2012 5:23 PM To: Tomcat Users List Subject: RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 Hi 1.2.32 was doing that for me.. 1.2.33 was meant to fix it, but I can't get 1.2.33 to load. Do you use overlapping recycle and a web garden ? Alex Thanks for your reply. I don't think I'm using a web garden - I just have one application pool for all virtual hosts which use the ISAPI redirector, and that application pool consists of a maximum of 1 worker process (the default IIS values). It is set to be recycled every 1740 minutes, and disallowOverlappingRotation for that pool is set to false - I guess that means I'm using overlapping recycle (a new w3wp.exe is started which takes new requests, and after all old requests are finished, the old w3wp.exe will be stopped). Thanks, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
[snip] Hi 1.2.32 was doing that for me.. 1.2.33 was meant to fix it, but I can't get 1.2.33 to load. Do you use overlapping recycle and a web garden ? Alex Thanks for your reply. I don't think I'm using a web garden - I just have one application pool for all virtual hosts which use the ISAPI redirector, and that application pool consists of a maximum of 1 worker process (the default IIS values). It is set to be recycled every 1740 minutes, and disallowOverlappingRotation for that pool is set to false - I guess that means I'm using overlapping recycle (a new w3wp.exe is started which takes new requests, and after all old requests are finished, the old w3wp.exe will be stopped). The 1 processor thread is the key. The problem I summarised with 1.2.32 is that the shared memory is not protected by a OS semaphore, but an in process semaphore... 1.2.33 was mean to address this by changing from an inprocess semaphore to a OS semaphore. I am surprised you have 1.2.33 loading and working, every time I try to load it crashes out on me. Only quick solution I can think is that you move back to 1.2.32 :) You might want to trial the system under load. I found that if you had about 500 connections all try and reconnect at the same time with overlapping recycling it would corrupt the sharememory it was a bit of a silent killer for us. Thanks, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, July 26, 2011 6:15 PM To: Tomcat Users List Subject: Re: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32 Konstantin, Such a class would definitely be useful to post on the Wiki. Hi Christopher, Some days ago I made an entry in the Tomcat Wiki with such a OutputStream decorator class: http://wiki.apache.org/tomcat/FAQ/KnownIssues#ImageIOIssues I see that you changed the flush() method in the decorator class to pass flush() calls to the underlying stream as long as the stream is set to be active. The reason that I didn't make this call-through was because it seems that flush() is the only method called by the ImageIO (when the Image Writer is garbage collected), and by preventing any pass-through of flush(), no errors can occur. When flush() of the decorator class passes its call to the original stream as long as it's active, there may be a race condition between the request processing thread of the Servlet and the GC thread which collects the Image Writer, which possibly (but highly unlikely) could cause a flush() call (from GC thread) on the already closed stream, even if the isActive flag is volatile (please correct me if I'm wrong - I'm not a expert in how GC is working). Also, it seems that ImageIO is calling flush() a few times while writing an image, and I wanted to avoid the unnecessary flush() calls. ;-) Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 8/23/2011 4:02 PM, Konstantin Preißer wrote: I see that you changed the flush() method in the decorator class to pass flush() calls to the underlying stream as long as the stream is set to be active. The reason that I didn't make this call-through was because it seems that flush() is the only method called by the ImageIO (when the Image Writer is garbage collected), and by preventing any pass-through of flush(), no errors can occur. When flush() of the decorator class passes its call to the original stream as long as it's active, there may be a race condition between the request processing thread of the Servlet and the GC thread which collects the Image Writer, which possibly (but highly unlikely) could cause a flush() call (from GC thread) on the already closed stream, even if the isActive flag is volatile (please correct me if I'm wrong - I'm not a expert in how GC is working). I added the flush() pass-through in case you actually wanted to flush the stream. It seems reasonable that you might want to flush the buffer at some point, and turning flush() into a no-op didn't seem like a good idea. I would expect the image writer to be available for GC after the request was processed, but I guess the request could have operations after the ImageIO is actually done and you're right: the GC could kick-in virtually at any time. If you use your wrapper class as a fire-and-forget kind of thing while maintaining the original reference to the OutputStream, I suppose you still have complete control over flushing that underlying stream. Also, it seems that ImageIO is calling flush() a few times while writing an image, and I wanted to avoid the unnecessary flush() calls. ;-) That's a different story :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5UEXkACgkQ9CaO5/Lv0PCiNQCgu1foU5uwo63iExja+Wf+WPys 8iIAoJRaIucq9losxjKp0kkhUs6ycZYj =HDoE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, July 26, 2011 6:15 PM To: Tomcat Users List Subject: Re: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32 You should also null-out the reference to Tomcat's output stream. This would allow you to leak your own decorator objects but not interfere with Tomcat's ability to do it's own object management. Such a class would definitely be useful to post on the Wiki. Hi Christopher, thanks for your reply (and sorry for the delay). What would be the best place to post such a class (plus the information about the ImageIO) on the Tomcat Wiki / is there any guide how to write articles there? Thanks! Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 7/13/2011 6:53 PM, eurotrans-Verlag wrote: Thanks. In the meantime, I also came to that conclusion and replaced all instances of ImageIO.write(img, PNG, response.getOutputStream()) in my servlets/webapps with something like ByteArrayOutputStream bout = new ByteArrayOutputStream(); ImageIO.write(img, PNG, bout); bout.writeTo(response.getOutputStream()); so that the ImageIO never sees the real OutputStream, and it seems to work fine (no more IllegalStateExceptions or wrong message format errors in the isapi log when using AJP-APR). Wow, I'm surprised that had an effect. Or, rather, I'm surprised that ImageIO doesn't have decent object reference management. Is that a good practice (using ByteArrayOutputStream, then copy it to the response) to dynamically generate Images and serve them to the clients? There is a downside: you need a bunch of temporary memory available to perform these image manipulations. ImageIO uses a lots of memory already, and now you are going to have to buffer the entire output image before the first byte is written back to the client. That means no streaming whatsoever, which might strain your resources. You might want to look at your heap size, average image size, and estimated user load to determine if you want to do something like put a hard limit on the number of image transformations that can be performed simultaneously. Otherwise, you risk OOME. Also, is there any hint to this on the Tomcat documentation/wiki? Because I don't think it would be unusual to dynamically generate images and serve them to clients using the ImageIO, and I think it could be a bit frustrating to find the actual problem if one doesn't know this. Tomcat obviously can't document all foreign API problems out there, but it might be worth mentioning this one on the Wiki somewhere. Feel free to create a wiki account and create a new page for these kinds of things. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4u5yMACgkQ9CaO5/Lv0PDMGQCfSLZ1BpdK7GVqd5wh+ZjYzFTA H50AoIzjIoX6r72h4k1/VMLLqBjNPSI8 =V6o8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 7/14/2011 8:41 AM, eurotrans-Verlag wrote: An alternative that I could imagine, would be to create a class (that has a boolean flag) which extends OutputStream, and decorates another OutputStream that is given to the class in the constructor (that would be the OutputStream from the servlet's response). This class would pass all calls to it to the other OutputStream (as long as the flag is true), and as soon as close() or another special method is called, it sets the flag to false, which causes all other methods to do nothing (or throw an IOException). That way, Tomcat's OutputStream would also be protected from future calls from the ImageIO. You should also null-out the reference to Tomcat's output stream. This would allow you to leak your own decorator objects but not interfere with Tomcat's ability to do it's own object management. Such a class would definitely be useful to post on the Wiki. However, it seems also a bit strange to me that Tomcat is recycling OutputStreams, because in my understanding, once an OutputStream is closed, it should be impossible to do any further write() calls to it. True, but Tomcat tries to avoid as much memory churn as possible, and re-uses objects whenever possible. You can change this behavior with configuration if you want. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4u6AQACgkQ9CaO5/Lv0PD6cACfW4BS55+FtwpK3ZonNjOuvfPV v+MAn3iCTpTSI+FOBkgdI9UOZD4YvsM6 =oazD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
Hi all,
An alternative that I could imagine, would be to create a class (that has
a
boolean flag) which extends OutputStream, and decorates another
OutputStream
that is given to the class in the constructor (that would be the
OutputStream from the servlet's response). This class would pass all calls
to it to the other OutputStream (as long as the flag is true), and as soon
as close() or another special method is called, it sets the flag to false,
which causes all other methods to do nothing (or throw an IOException).
That
way, Tomcat's OutputStream would also be protected from future calls
from the ImageIO.
I now use a OutputStream decorator like this when calling ImageIO.write():
public class ImageIOBetterOutputStream extends OutputStream {
private OutputStream out; // the actual stream
private volatile boolean isActive = true;
public ImageIOBetterOutputStream (OutputStream out) {
this.out = out;
}
@Override
public void close() throws IOException {
if (isActive) {
isActive = false; // deactivate
try {
out.close();
} finally {
out = null;
}
}
}
@Override
public void flush() throws IOException {
// do nothing
}
@Override
public void write(byte[] b, int off, int len) throws IOException {
if (isActive) {
out.write(b, off, len);
}
}
[...] (overwrite the other methods the same way)
}
That way, I don't have to use a ByteArrayOutputStream to buffer the contents
in memory, and Tomcat's OutputStream is also protected from future calls to
flush() from the ImageIO (I just have to make sure that the call to close()
is inside a finally-block). (If flush() is the only method that the ImageIO
calls after an IOException, it probably would be enough to overwrite flush()
only). Since I'm using this class as OutputStream for the ImageIO, there
also haven't been any more errors.
I agree that this behavior of the ImageIO is very strange (flushing the
OutputStream when the ImageWriter gets garbage-collected, if an
IOException
was thrown when the IIO previously tried to write to the stream).
However, it seems also a bit strange to me that Tomcat is recycling
OutputStreams,
because in my understanding, once an OutputStream is closed, it should
be impossible to do any further write() calls to it.
May I ask, what is the particular reason for Tomcat to recycle
OutputStreams?
Does anyone have a clue about this? I can understand recycling objects like
the Request/Response objects (e.g. if they contain lots of fields), but at
the moment I don't have an idea why it would be useful to recycle
OutputStream objects.
Also, is there any hint to this on the Tomcat documentation/wiki? Because
I
don't think it would be unusual to dynamically generate images and
serve them to clients using the ImageIO, and I think it could be a bit
frustrating to find the actual problem if one doesn't know this.
I couldn't find any hints about this in the Tomcat documentation/wiki, but I
think it should be mentioned somewhere. Of course, the behavior of the
ImageIO is strange, but Tomcat's recycling of OutputStreams enable the
errors when using the ImageIO.
If it is desired, maybe I could contribute something to this topic for
docs/wiki?
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
eurotrans-Verlag wrote: Hi Rainer, -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Thursday, July 14, 2011 12:17 AM At least there was trouble about Java2D for several users in the past. One such issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=41772 http://nerd.dk/blogs/bug-tomcat-or-java2d but you might find more. Regards, Rainer Thanks. In the meantime, I also came to that conclusion and replaced all instances of ImageIO.write(img, PNG, response.getOutputStream()) in my servlets/webapps with something like ByteArrayOutputStream bout = new ByteArrayOutputStream(); ImageIO.write(img, PNG, bout); bout.writeTo(response.getOutputStream()); so that the ImageIO never sees the real OutputStream, and it seems to work fine (no more IllegalStateExceptions or wrong message format errors in the isapi log when using AJP-APR). Is that a good practice (using ByteArrayOutputStream, then copy it to the response) to dynamically generate Images and serve them to the clients? Also, is there any hint to this on the Tomcat documentation/wiki? Because I don't think it would be unusual to dynamically generate images and serve them to clients using the ImageIO, and I think it could be a bit frustrating to find the actual problem if one doesn't know this. As a comment purely from a general programming point of view, not a Java/Tomcat programming point of view : I am not familiar with the ByteArrayOutputStream, but from your usage of it above it seems to be a buffer in memory to which one can write, and with a special writeTo method which must be an efficient way to copy its contents to another stream. If so, whether it is good practice or not would depend entirely on your particular circumstances : the size of the images you are handling this way, the number of simultaneous requests which you are handling, how much memory you have to play with, and how fast your CPU is. It is sometimes surprising to make the calculation. By writing an image first to a memory buffer, you use up the additional memory of that buffer, which is equal to the output size of your image, plus the overhead of the ByteArrayOutputStream structure. So let's use some totally arbitrary parameters, just for the sake of an example : - let's say that ByteArrayOutputStream has 50% overhead. So to store 250 KB of data, in reality uses up 375 KB of RAM - you serve up to 100 basic browser page requests at a time (that is, the base html pages which include the images) - each such page contains 4 (links to) images - each image is on average 250 KB in size (a small jpeg) - the browsers themselves, when finding image links in a page, will issue up to 4 simultaneous requests for those images (the last time I looked, quite a long time ago, browsers only requested 2 things in parallel, but they might have improved since) So you could in theory have 400 simultaneous requests, for 400 images, each 250 KB in size. Thus your Tomcat server (supposing it can handle 400 threads at a time) would be creating 400 instances of ByteArrayOutputStream, and - first filling them up until they reach 250 KB of data - then copying this data back onto the Response output stream - then discarding the ByteArrayOutputStream So, compared to using the Response output stream directly, you would now use an additional (375 KB X 400) = 150,000 KB = about 150 MB additional Heap space That seems reasonable to me. But of course it would be a problem if you are currently running Tomcat with a 128 MB heap. Or if your images, instead of being 250 KB on average, would be 250 MB. Or if filling up - and reading back - the ByteArrayOutputStream was very inefficient and used up all your CPU time. On the other hand, the alternative is to have broken responses, so it may be better to add some RAM to the system. Note: the above calculation is probably quite questionable. But it provides a quick estimate, that may be roughly within a factor 10 of reality. I use this often at the beginning of a project, to at least get an idea whether something seems reasonable/feasible, or is totally off-kilter. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
Hi André, -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Thursday, July 14, 2011 1:00 PM To: Tomcat Users List Subject: Re: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32 As a comment purely from a general programming point of view, not a Java/Tomcat programming point of view : I am not familiar with the ByteArrayOutputStream, but from your usage of it above it seems to be a buffer in memory to which one can write, and with a special writeTo method which must be an efficient way to copy its contents to another stream. If so, whether it is good practice or not would depend entirely on your particular circumstances : the size of the images you are handling this way, the number of simultaneous requests which you are handling, how much memory you have to play with, and how fast your CPU is. It is sometimes surprising to make the calculation. (...) So, compared to using the Response output stream directly, you would now use an additional (375 KB X 400) = 150,000 KB = about 150 MB additional Heap space That seems reasonable to me. But of course it would be a problem if you are currently running Tomcat with a 128 MB heap. Or if your images, instead of being 250 KB on average, would be 250 MB. Or if filling up - and reading back - the ByteArrayOutputStream was very inefficient and used up all your CPU time. On the other hand, the alternative is to have broken responses, so it may be better to add some RAM to the system. Thanks for your long response. Your assumption about ByteArrayOutputStream is correct: It buffers the contents written to it in a byte array, which automatically grows if its capacity is exceeded, by factor 2. However I think the memory is not a big issue here, because the data that is written to the ByteArrayOutputStream is the compressed version of an image that is already in RAM, and that is usually much bigger than the compressed form. For example, when I have a BufferedImage of 800x600 pixel and 24 bit per pixel (TYPE_INT_RGB), it consumes 800*600*3 bytes = 1,37 MiB in memory. The size of the compressed form varies from file type (JPEG, PNG, ...) and the contents of the image, but if I would save it as JPEG for example, it will only take about 200 KiB, which is much less than the uncompressed form in the memory. An alternative that I could imagine, would be to create a class (that has a boolean flag) which extends OutputStream, and decorates another OutputStream that is given to the class in the constructor (that would be the OutputStream from the servlet's response). This class would pass all calls to it to the other OutputStream (as long as the flag is true), and as soon as close() or another special method is called, it sets the flag to false, which causes all other methods to do nothing (or throw an IOException). That way, Tomcat's OutputStream would also be protected from future calls from the ImageIO. I agree that this behavior of the ImageIO is very strange (flushing the OutputStream when the ImageWriter gets garbage-collected, if an IOException was thrown when the IIO previously tried to write to the stream). However, it seems also a bit strange to me that Tomcat is recycling OutputStreams, because in my understanding, once an OutputStream is closed, it should be impossible to do any further write() calls to it. May I ask, what is the particular reason for Tomcat to recycle OutputStreams? Thanks! Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
On 13.07.2011 00:36, eurotrans-Verlag wrote: Hmm, could it be that the Java ImageIO is re-using OutputStreams after calling ImageIO.write(img, PNG, out), so that I'm getting such a IllegalStateException? (I think I read somewhere that Tomcat is recycling OutputStream objects) Maybe that could also explain the AJP errors I got. At least there was trouble about Java2D for several users in the past. One such issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=41772 http://nerd.dk/blogs/bug-tomcat-or-java2d but you might find more. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
Hi Rainer, -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Thursday, July 14, 2011 12:17 AM At least there was trouble about Java2D for several users in the past. One such issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=41772 http://nerd.dk/blogs/bug-tomcat-or-java2d but you might find more. Regards, Rainer Thanks. In the meantime, I also came to that conclusion and replaced all instances of ImageIO.write(img, PNG, response.getOutputStream()) in my servlets/webapps with something like ByteArrayOutputStream bout = new ByteArrayOutputStream(); ImageIO.write(img, PNG, bout); bout.writeTo(response.getOutputStream()); so that the ImageIO never sees the real OutputStream, and it seems to work fine (no more IllegalStateExceptions or wrong message format errors in the isapi log when using AJP-APR). Is that a good practice (using ByteArrayOutputStream, then copy it to the response) to dynamically generate Images and serve them to the clients? Also, is there any hint to this on the Tomcat documentation/wiki? Because I don't think it would be unusual to dynamically generate images and serve them to clients using the ImageIO, and I think it could be a bit frustrating to find the actual problem if one doesn't know this. Thanks! Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
However, when I switch to AJP BIO, it seems that the errors go away. Although I now switched to AJP-BIO (by deleting/renaming tcnative-1.dll), today morning I got an error again in the ISAPI log: [Tue Jul 12 06:04:49.812 2011] [4124:2444] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (1296): wrong message format 0xdaed from 127.0.0.1:8019 [Tue Jul 12 06:04:49.825 2011] [4124:2444] [error] ajp_get_reply::jk_ajp_common.c (2148): (worker1) Tomcat is down or network problems. Part of the response has already been sent to the client This is how the AJP connector is configured in Tomcat: Connector port=8019 protocol=AJP/1.3 redirectPort=8743 URIEncoding=UTF-8 maxThreads=1024 / Any idea what could cause this errors? I don't know it that matters, but with one webapp, I'm using COM4J to access COM objects on the Windows system (but I want to get rid of it in the future). Thanks, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
eurotrans-Verlag wrote: However, when I switch to AJP BIO, it seems that the errors go away. Although I now switched to AJP-BIO (by deleting/renaming tcnative-1.dll), today morning I got an error again in the ISAPI log: [Tue Jul 12 06:04:49.812 2011] [4124:2444] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (1296): wrong message format 0xdaed from 127.0.0.1:8019 [Tue Jul 12 06:04:49.825 2011] [4124:2444] [error] ajp_get_reply::jk_ajp_common.c (2148): (worker1) Tomcat is down or network problems. Part of the response has already been sent to the client This is how the AJP connector is configured in Tomcat: Connector port=8019 protocol=AJP/1.3 redirectPort=8743 URIEncoding=UTF-8 maxThreads=1024 / Any idea what could cause this errors? I don't know it that matters, but with one webapp, I'm using COM4J to access COM objects on the Windows system (but I want to get rid of it in the future). Can you take a part of this setup out of the equation ? For example, at the moment you have browser - IIS - isapi_redir. - AJP Connector:8019 - Tomcat+webapp Could you eliminate the IIS + Isapi_redir part, having Tomcat listen on port 80/HTTP, like this : browser - HTTP Connector:80 - Tomcat+webapp ? or like this, by using Apache httpd instead of IIS : browser - Apache - mod_jk - AJP Connector:8019 - Tomcat+webapp This may help pinpointing where the problem is, since you mentioned earlier that you can reproduce the problem by pressing F5 in Firefox. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
Hi André, -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Tuesday, July 12, 2011 9:25 PM Can you take a part of this setup out of the equation ? For example, at the moment you have browser - IIS - isapi_redir. - AJP Connector:8019 - Tomcat+webapp Could you eliminate the IIS + Isapi_redir part, having Tomcat listen on port 80/HTTP, like this : browser - HTTP Connector:80 - Tomcat+webapp ? or like this, by using Apache httpd instead of IIS : browser - Apache - mod_jk - AJP Connector:8019 - Tomcat+webapp This may help pinpointing where the problem is, since you mentioned earlier that you can reproduce the problem by pressing F5 in Firefox. Unfortunately, I can't replace IIS with Apache or direct Tomcat HTTP connector, as that webapp is on a public server where also other websites are hosted, using IIS. But perhaps I can see if I can reproduce the problem in a virtual machine. Please note that I could only reproduce the problems that occurred before switching from AJP-APR to AJP-BIO. There I could reproduce them by pressing and holding F5 in Firefox for some seconds, but after I switched to AJP-BIO, that didn't worked. The error message I wrote in the last mail did I see when I read the isapi logs today. Today I also got another strange exception in Tomcat (I don't know if it has anything to do with the AJP errors): 13.07.2011 00:13:51 org.apache.catalina.core.StandardWrapperValve invoke SCHWERWIEGEND: Servlet.service() for servlet [hauptSeite.HauptServlet] in context with path [] threw exception java.lang.IllegalStateException: Cannot create a session after the response has been committed at org.apache.catalina.connector.Request.doGetSession(Request.java:2734) at org.apache.catalina.connector.Request.getSession(Request.java:2244) at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:89 9) at common.Common2.getSession(Common2.java:102) at hauptSeite.HauptServlet.doThings(HauptServlet.java:136) at hauptSeite.HauptServlet.doGet(HauptServlet.java:98) at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:240) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:164) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:462) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164 ) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100 ) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :118) at org.apache.catalina.valves.CrawlerSessionManagerValve.invoke(CrawlerSessionM anagerValve.java:172) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:403) at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:292) at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.j ava:143) at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.j ava:129) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java: 309) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja va:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9 08) at java.lang.Thread.run(Thread.java:662) This appeared some minutes ago. I also have seen this Exception some times on JSP pages, but not on a normal Servlet (for JSP pages, the stack trace contained at org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java: 65) and that was before any custom JSP code). This above error is from a WebApp that I use for hosting images. The stack trace seems to indicate that a response has been committed before a session is created, however I absolutely never send any response before creating a session in that Servlet (I call response.getWriter() or response.getOutputStream several lines after I call request.getSession(true) ). Hmm, could it be that the Java ImageIO is re-using OutputStreams after calling ImageIO.write(img, PNG, out), so that I'm getting such a IllegalStateException? (I think I read somewhere that Tomcat is recycling OutputStream objects) Maybe that could also explain the AJP errors I got. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail:
AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
Hi all, I have a system with Windows Server 2008 (32 bit), Sun/Oracle JDK 1.6.0_26 and Im using Tomcat 7.0.16 with Tomcat Native 1.1.20, and IIS 7.0 with ISAPI Redirector 1.2.32. For AJP, I use the AJP-APR connector. Sometimes, when many requests are sent to a webapp in short time, some requests fail, and the ISAPI log (log_level=error) says: [Sun Jul 10 21:35:55.061 2011] [580:5032] [error] ajp_get_reply::jk_ajp_common.c (2187): (worker1) Tomcat already send headers [Sun Jul 10 21:35:55.071 2011] [580:5032] [error] ajp_service::jk_ajp_common.c (2600): (worker1) sending request to tomcat failed (unrecoverable), (attempt=1) [Sun Jul 10 21:35:55.080 2011] [580:5032] [error] HttpExtensionProc::jk_isapi_plugin.c (2261): service() failed with http error 502 [Sun Jul 10 21:35:55.087 2011] [580:4776] [error] ajp_get_reply::jk_ajp_common.c (2187): (worker1) Tomcat already send headers [Sun Jul 10 21:35:55.097 2011] [580:4776] [error] ajp_service::jk_ajp_common.c (2600): (worker1) sending request to tomcat failed (unrecoverable), (attempt=1) [Sun Jul 10 21:35:55.104 2011] [580:4776] [error] HttpExtensionProc::jk_isapi_plugin.c (2261): service() failed with http error 502 [Sun Jul 10 21:37:20.662 2011] [5696:3220] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (1296): wrong message format 0x3000 from 127.0.0.1:8019 [Sun Jul 10 21:37:20.679 2011] [5696:3220] [error] ajp_get_reply::jk_ajp_common.c (2118): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) [Sun Jul 10 21:42:56.105 2011] [580:5032] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (1296): wrong message format 0x3000 from 127.0.0.1:8019 [Sun Jul 10 21:42:56.135 2011] [580:5032] [error] ajp_get_reply::jk_ajp_common.c (2118): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) [Sun Jul 10 21:42:56.149 2011] [580:3100] [error] ajp_get_reply::jk_ajp_common.c (2187): (worker1) Tomcat already send headers [Sun Jul 10 21:42:56.160 2011] [580:3100] [error] ajp_service::jk_ajp_common.c (2600): (worker1) sending request to tomcat failed (unrecoverable), (attempt=1) [Sun Jul 10 21:42:56.168 2011] [580:3100] [error] HttpExtensionProc::jk_isapi_plugin.c (2261): service() failed with http error 502 [Sun Jul 10 21:45:49.849 2011] [580:4532] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (1296): wrong message format 0x3000 from 127.0.0.1:8019 [Sun Jul 10 21:45:49.867 2011] [580:4532] [error] ajp_get_reply::jk_ajp_common.c (2118): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) However I didn't see any errors in the Tomcat logs. I could reproduce the errors by pressing F5 in Firefox several seconds, so that FF makes a lot of requests in a short time. However, when I switch to AJP BIO, it seems that the errors go away. Please note that I'm also using the Java ImageIO to produce and serve images with some servlets. I think somewhere I read that using the ImageIO with APR connectors could cause problems. Is this correct? If yes, does that mean that I have to stick with the AJP BIO (or NIO?) connector, instead of AJP APR; or does anybody know why there are these errors? Thanks. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
It looks like this is a regression in 1.2.31 - the socket shutdown code that drained the response message from the AJP socket before closing it was mis-counting the bytes read, causing a CPU busy loop until it hit a 30 second cap on lingering byte reads. I've committed a fix for 1.2.32 and also capped the amount of data that the socket shutdown will read to 32k, and the total time to drain the socket to 2s. cheers tim On Mon, May 16, 2011 at 1:09 PM, verlag.preis...@t-online.de verlag.preis...@t-online.de wrote: Hi Tim, This sounds like https://issues.apache.org/bugzilla/show_bug.cgi?id=50839 If you can capture a TRACE level log form the Tomcat Connector (configure in isapi_redirect.properties) and attach it to the bug, I'll take a look. cheers tim Thanks! I will attach a Trace level log from the Redirector there. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 5/14/2011 4:01 PM, André Warnier wrote: eurotrans-Verlag wrote: However I would expect write() to always throw an IOException when the connection to the client is aborted, Remember, there are 2 separate connections : the connection of the client to IIS+isapi_redirector, and the connection from IIS+isapi_redirector to Tomcat+servlet. The servlet will only throw an I/O exception if that second connection is closed. +1 If the ISAPI redirector works anything like mod_jk, then the connection is expected to be persistent. That means the redirector might end up reading a lot of data and throwing it into the bit bucket. If ISAPI redirector connections are /not/ intended to be persistent, then the redirector should be terminating the connection with Tomcat as soon as possible. You should only have to wait for a buffer to fill-up before an error is detected, which shouldn't be long at all. If reading and discarding the data sends the CPU high, there might be a bug in there... maybe a buffer that is too small or a loop that either doesn't do enough work in it's body (a tight loop) or is doing too much useless work (like re-calculating a value that might be constant during the loop). I have no idea. We need Mladen or Rainer here.. I think so. I've looked at the mod_jk code before for certain things and while it's fairly straightforward, it is certainly extensive. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3RUuIACgkQ9CaO5/Lv0PBPJQCgqcGo1rvFpjCOjzcMx17GS2cm C2YAn0BETp2I6HK7fJrLLx0BBvMdvFwg =vUDE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
This sounds like https://issues.apache.org/bugzilla/show_bug.cgi?id=50839
If you can capture a TRACE level log form the Tomcat Connector
(configure in isapi_redirect.properties) and attach it to the bug,
I'll take a look.
cheers
tim
On Sun, May 15, 2011 at 1:20 AM, eurotrans-Verlag
verlag.preis...@t-online.de wrote:
Hello everybody,
I stumbled upon a strange problem with the ISAPI Redirector 1.2.31 on
Windows Server 2008 SP2 (32 bit) with IIS 7.0. The problem is, that when a
Servlet is generating lots of data (e.g. 200 MB) and a user downloads it
over the Isapi Redirector/IIS7, and cancels the download, the IIS Worker
process (w3wp.exe) will have 100% CPU usage for about 30 seconds. However if
the download is completed normally (not canceled), everything is fine and
the CPU usage will not go up that far.
The exact Components used are:
Windows Server 2008 SP2 (32 bit) with IIS 7.0,
Sun JDK 1.6.0_25,
Tomcat 7.0.14,
ISAPI Redirector 1.2.31.
I could reproduce the problem with a clean install of these components.
To reproduce:
1. Install Tomcat and the ISAPI Redirector on a Windows Server 2008 SP2 IIS
7.0 system, as described in the Tomcat Connectors Documentation
(The problem occurs with both settings of enable_chunked_encoding, true
and false).
2. Create a Servlet or JSP that produces some huge amount of random data,
for example:
@WebServlet(/DownloadServlet)
public class DownloadServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
response.setContentType(application/x-msdownload);
OutputStream out = response.getOutputStream();
Random r = new Random();
byte[] content = new byte[1024];
for (int i = 0; i content.length; i++)
content[i] = (byte) (r.nextFloat() * 256);
for (int i = 0; i 20; i++)
out.write(content);
out.close();
}
}
3. Request the Servlet or JSP through the IIS port with a browser. After
some seconds, cancel the download.
4. One thread of the IIS Worker Process (w3wp.exe) will have 100% CPU usage
for some time (about 30 seconds), before it normalizes to 0%.
Note that is does not happen every time. Sometimes you will have to repeat
starting and canceling the download until the problem occurs.
5. In the ISAPI log, following lines are logged (log_level=info):
[Sat May 14 14:48:55.654 2011] [3508:3560] [error]
isapi_write_client::jk_isapi_plugin.c (1210): WriteClient failed with 995
(0x03e3)
[Sat May 14 14:48:55.654 2011] [3508:3560] [info]
ajp_process_callback::jk_ajp_common.c (1885): Writing to client aborted or
client network problems
[Sat May 14 14:48:55.654 2011] [3508:3560] [info]
ajp_service::jk_ajp_common.c (2543): (worker1) sending request to tomcat
failed (unrecoverable), because of client write error (attempt=1)
[Sat May 14 14:48:55.669 2011] [3508:3560] [info]
HttpExtensionProc::jk_isapi_plugin.c (2217): service() failed because client
aborted connection
These lines are logged immediately after the client cancels the connection
(not after the CPU usage of w3wp.exe goes down).
The worker process continues normally after the CPU usage went down.
However, if one would do this repeatedly, it could enable DoS attacks,
couldn't it?
What would cause these excessive CPU usages of the IIS worker process when
the user cancels the download?
Thanks for your help.
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
Hi Tim, This sounds like https://issues.apache.org/bugzilla/show_bug.cgi?id=50839 If you can capture a TRACE level log form the Tomcat Connector (configure in isapi_redirect.properties) and attach it to the bug, I'll take a look. cheers tim Thanks! I will attach a Trace level log from the Redirector there. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
Hello everybody,
I stumbled upon a strange problem with the ISAPI Redirector 1.2.31 on
Windows Server 2008 SP2 (32 bit) with IIS 7.0. The problem is, that when a
Servlet is generating lots of data (e.g. 200 MB) and a user downloads it
over the Isapi Redirector/IIS7, and cancels the download, the IIS Worker
process (w3wp.exe) will have 100% CPU usage for about 30 seconds. However if
the download is completed normally (not canceled), everything is fine and
the CPU usage will not go up that far.
The exact Components used are:
Windows Server 2008 SP2 (32 bit) with IIS 7.0,
Sun JDK 1.6.0_25,
Tomcat 7.0.14,
ISAPI Redirector 1.2.31.
I could reproduce the problem with a clean install of these components.
To reproduce:
1. Install Tomcat and the ISAPI Redirector on a Windows Server 2008 SP2 IIS
7.0 system, as described in the Tomcat Connectors Documentation
(The problem occurs with both settings of enable_chunked_encoding, true
and false).
2. Create a Servlet or JSP that produces some huge amount of random data,
for example:
@WebServlet(/DownloadServlet)
public class DownloadServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
response.setContentType(application/x-msdownload);
OutputStream out = response.getOutputStream();
Random r = new Random();
byte[] content = new byte[1024];
for (int i = 0; i content.length; i++)
content[i] = (byte) (r.nextFloat() * 256);
for (int i = 0; i 20; i++)
out.write(content);
out.close();
}
}
3. Request the Servlet or JSP through the IIS port with a browser. After
some seconds, cancel the download.
4. One thread of the IIS Worker Process (w3wp.exe) will have 100% CPU usage
for some time (about 30 seconds), before it normalizes to 0%.
Note that is does not happen every time. Sometimes you will have to repeat
starting and canceling the download until the problem occurs.
5. In the ISAPI log, following lines are logged (log_level=info):
[Sat May 14 14:48:55.654 2011] [3508:3560] [error]
isapi_write_client::jk_isapi_plugin.c (1210): WriteClient failed with 995
(0x03e3)
[Sat May 14 14:48:55.654 2011] [3508:3560] [info]
ajp_process_callback::jk_ajp_common.c (1885): Writing to client aborted or
client network problems
[Sat May 14 14:48:55.654 2011] [3508:3560] [info]
ajp_service::jk_ajp_common.c (2543): (worker1) sending request to tomcat
failed (unrecoverable), because of client write error (attempt=1)
[Sat May 14 14:48:55.669 2011] [3508:3560] [info]
HttpExtensionProc::jk_isapi_plugin.c (2217): service() failed because client
aborted connection
These lines are logged immediately after the client cancels the connection
(not after the CPU usage of w3wp.exe goes down).
The worker process continues normally after the CPU usage went down.
However, if one would do this repeatedly, it could enable DoS attacks,
couldn't it?
What would cause these excessive CPU usages of the IIS worker process when
the user cancels the download?
Thanks for your help.
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
eurotrans-Verlag wrote:
Hello everybody,
I stumbled upon a strange problem with the ISAPI Redirector 1.2.31 on
Windows Server 2008 SP2 (32 bit) with IIS 7.0. The problem is, that when a
Servlet is generating lots of data (e.g. 200 MB) and a user downloads it
over the Isapi Redirector/IIS7, and cancels the download, the IIS Worker
process (w3wp.exe) will have 100% CPU usage for about 30 seconds. However if
the download is completed normally (not canceled), everything is fine and
the CPU usage will not go up that far.
The exact Components used are:
Windows Server 2008 SP2 (32 bit) with IIS 7.0,
Sun JDK 1.6.0_25,
Tomcat 7.0.14,
ISAPI Redirector 1.2.31.
I could reproduce the problem with a clean install of these components.
To reproduce:
1. Install Tomcat and the ISAPI Redirector on a Windows Server 2008 SP2 IIS
7.0 system, as described in the Tomcat Connectors Documentation
(The problem occurs with both settings of enable_chunked_encoding, true
and false).
2. Create a Servlet or JSP that produces some huge amount of random data,
for example:
@WebServlet(/DownloadServlet)
public class DownloadServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
response.setContentType(application/x-msdownload);
OutputStream out = response.getOutputStream();
Random r = new Random();
byte[] content = new byte[1024];
for (int i = 0; i content.length; i++)
content[i] = (byte) (r.nextFloat() * 256);
for (int i = 0; i 20; i++)
out.write(content);
out.close();
}
}
3. Request the Servlet or JSP through the IIS port with a browser. After
some seconds, cancel the download.
4. One thread of the IIS Worker Process (w3wp.exe) will have 100% CPU usage
for some time (about 30 seconds), before it normalizes to 0%.
Note that is does not happen every time. Sometimes you will have to repeat
starting and canceling the download until the problem occurs.
5. In the ISAPI log, following lines are logged (log_level=info):
[Sat May 14 14:48:55.654 2011] [3508:3560] [error]
isapi_write_client::jk_isapi_plugin.c (1210): WriteClient failed with 995
(0x03e3)
[Sat May 14 14:48:55.654 2011] [3508:3560] [info]
ajp_process_callback::jk_ajp_common.c (1885): Writing to client aborted or
client network problems
[Sat May 14 14:48:55.654 2011] [3508:3560] [info]
ajp_service::jk_ajp_common.c (2543): (worker1) sending request to tomcat
failed (unrecoverable), because of client write error (attempt=1)
[Sat May 14 14:48:55.669 2011] [3508:3560] [info]
HttpExtensionProc::jk_isapi_plugin.c (2217): service() failed because client
aborted connection
These lines are logged immediately after the client cancels the connection
(not after the CPU usage of w3wp.exe goes down).
The worker process continues normally after the CPU usage went down.
However, if one would do this repeatedly, it could enable DoS attacks,
couldn't it?
What would cause these excessive CPU usages of the IIS worker process when
the user cancels the download?
A guess :
IIS and the isapi_redirector are one process, and Tomcat and the servlet are another
process. The isapi_redirector makes a connection to Tomcat, sends the request over it.
The servlet starts running and producing output, quite a lot and quite fast, over that
connection.
The isapi_redirector reads the servlet output, and writes it to the client
connection.
Now the client closes the connection, and isapi_redirector finds a closed socket the next
time it tries to write to the client. It writes this error to the logfile, and stops
trying to send output to the client (well, it cannot anymore, the socket is closed).
But in the meantime the servlet keeps producing output and sending it to
isapi_redirector.
So either isapi_redirector has a way to stop the servlet and discarding any servlet output
still pending, or else it is forced to read and discard whatever the servlet is still
sending, until the servlet decides to stop by itself.
Maybe the 100% CPU usage is happening while isapi_redirector is reading and discarding
whatever remains of the servlet output ? Since there is no client connection anymore to
slow things down, this is bound to be rather fast and cpu-intensive.
To figure out if this is what's happening, you could do some logging at the servlet end,
to see if it keeps sending data even when the client has canceled, or if it itself gets
some stop indication from the isapi_redirector (also a closed socket e.g.).
Or else Mladen or Rainer could tell us if I'm totally off-base here.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
Hi André, thanks for your reply. To figure out if this is what's happening, you could do some logging at the servlet end, to see if it keeps sending data even when the client has canceled, or if it itself gets some stop indication from the isapi_redirector (also a closed socket e.g.). Or else Mladen or Rainer could tell us if I'm totally off-base here. I added some logging to the Servlet to see what it is actually doing (logging the start and end of the doGet() method and every time 2 MB are written, and I also put the write loop in a try-catch clause to catch IOException). You are right: When I start the download, the servlet writes the bytes slowly (due to the speed of the Connection) to the output. However, when I then cancel the download, it writes the remaining bytes very fast, probably causing the high CPU usage of the ISAPI redirector. But in some cases, the result is another: After I canceled the download, the write() method throws an IOException: ClientAbortException: java.io.IOException: Failed to send AJP message and the remaining bytes are not written, so the CPU usage does not go up to 100% (That's probably the other case I mentioned before, that sometimes the CPU usage doesn't go up). However I would expect write() to always throw an IOException when the connection to the client is aborted, but it seems that in most cases, the IOException is not thrown, thus causing the servlet to write the remaining bytes very fast to the ISAPI redirector and probably causing the high CPU load. Do you or anybody have an idea why sometimes the IOException is not thrown when the Client aborts the Connection? Cheers Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
eurotrans-Verlag wrote: Hi André, thanks for your reply. To figure out if this is what's happening, you could do some logging at the servlet end, to see if it keeps sending data even when the client has canceled, or if it itself gets some stop indication from the isapi_redirector (also a closed socket e.g.). Or else Mladen or Rainer could tell us if I'm totally off-base here. I added some logging to the Servlet to see what it is actually doing (logging the start and end of the doGet() method and every time 2 MB are written, and I also put the write loop in a try-catch clause to catch IOException). You are right: When I start the download, the servlet writes the bytes slowly (due to the speed of the Connection) to the output. However, when I then cancel the download, it writes the remaining bytes very fast, probably causing the high CPU usage of the ISAPI redirector. But in some cases, the result is another: After I canceled the download, the write() method throws an IOException: ClientAbortException: java.io.IOException: Failed to send AJP message and the remaining bytes are not written, so the CPU usage does not go up to 100% (That's probably the other case I mentioned before, that sometimes the CPU usage doesn't go up). However I would expect write() to always throw an IOException when the connection to the client is aborted, Remember, there are 2 separate connections : the connection of the client to IIS+isapi_redirector, and the connection from IIS+isapi_redirector to Tomcat+servlet. The servlet will only throw an I/O exception if that second connection is closed. So it all depends on whether the isapi_redirector closes the connection to Tomcat also, when the client has closed its connection to IIS. but it seems that in most cases, the IOException is not thrown, thus causing the servlet to write the remaining bytes very fast to the ISAPI redirector and probably causing the high CPU load. Do you or anybody have an idea why sometimes the IOException is not thrown when the Client aborts the Connection? I have no idea. We need Mladen or Rainer here.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: ISAPI Redirector Work-Flow
Another question, in particular about this: It's not a redirect. The request data is converted to the AJP13 binary protocol which is received by an AJP connector in Tomcat. How is the request data passed? It is a Remore Procedure Call, an IP port connection, or something else? ___ «¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤» ___ Rick Curry Common Services - Software Development E2 - 066, MS 5210 972-431-9178 (Voice) 972-585-7585 (Pager) To send a (short) Text Message to my Pager: 9725857...@page.metrocall.com -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Monday, November 01, 2010 5:40 PM To: Tomcat Users List Subject: Re: ISAPI Redirector Work-Flow On 01/11/2010 21:48, Richard G Curry wrote: I am trying to understand how the ISAPI Redirector functions at an overview level but deeper than this: The request comes into IIS where the ISAPI Redirector filter sends the servlet and JSP requests to the Tomcat server. I know the redirector works with AJP13 to redirect requests to the Tomcat container. What I want to know is HOW that is done. Is it a redirected HTTP request, a 301 redirect or is it a port-to-port connection between the AJP13 processor and the defined instance in the workers.properties file? It's not a redirect. The request data is converted to the AJP13 binary protocol which is received by an AJP connector in Tomcat. As this properties file defines the host name of the server holding the Tomcat instance, this can be on a different server than the IIS server, correct? Yes. Then does AJP13 'connect' directly to the defined server (localhost in all the examples I have seen) and the defined port (8009 in the same examples)? The connector opens multiple connections to the Tomcat server. If you know of a diagram that shows how this works, please share the link to that resouce. I don't sorry. p The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient, you are hereby notified that your access is unauthorized, and any review, dissemination, distribution or copying of this message including any attachments is strictly prohibited. If you are not the intended recipient, please contact the sender and delete the material from any computer. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: ISAPI Redirector Work-Flow
From: Richard G Curry [mailto:rgcu...@jcpenney.com] Subject: RE: ISAPI Redirector Work-Flow How is the request data passed? It is a Remore Procedure Call, an IP port connection, or something else? AJP is analogous to HTTP, in that it passes requests and responses over a TCP/IP connection, but in a much more compact form than HTTP. That's why the Connector element for an AJP connection has address and port attributes. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: ISAPI Redirector Work-Flow
That is what I thought and I thank you for your confirmation of this. I appreciate your time and support. ___ «¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤» ___ Rick Curry Common Services - Software Development E2 - 066, MS 5210 972-431-9178 (Voice) 972-585-7585 (Pager) To send a (short) Text Message to my Pager: 9725857...@page.metrocall.com -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, November 02, 2010 8:47 AM To: Tomcat Users List Subject: RE: ISAPI Redirector Work-Flow From: Richard G Curry [mailto:rgcu...@jcpenney.com] Subject: RE: ISAPI Redirector Work-Flow How is the request data passed? It is a Remore Procedure Call, an IP port connection, or something else? AJP is analogous to HTTP, in that it passes requests and responses over a TCP/IP connection, but in a much more compact form than HTTP. That's why the Connector element for an AJP connection has address and port attributes. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient, you are hereby notified that your access is unauthorized, and any review, dissemination, distribution or copying of this message including any attachments is strictly prohibited. If you are not the intended recipient, please contact the sender and delete the material from any computer. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
ISAPI Redirector Work-Flow
I am trying to understand how the ISAPI Redirector functions at an overview level but deeper than this: The request comes into IIS where the ISAPI Redirector filter sends the servlet and JSP requests to the Tomcat server. I know the redirector works with AJP13 to redirect requests to the Tomcat container. What I want to know is HOW that is done. Is it a redirected HTTP request, a 301 redirect or is it a port-to-port connection between the AJP13 processor and the defined instance in the workers.properties file? As this properties file defines the host name of the server holding the Tomcat instance, this can be on a different server than the IIS server, correct? Then does AJP13 'connect' directly to the defined server (localhost in all the examples I have seen) and the defined port (8009 in the same examples)? If you know of a diagram that shows how this works, please share the link to that resouce. /prefont face=monospacesize=-3brThe information transmitted is intended only for the person or entity to which it is addressed and brmay contain confidential and/or privileged material. If the reader of this message is not the intendedbrrecipient, you are hereby notified that your access is unauthorized, and any review, dissemination,brdistribution or copying of this message including any attachments is strictly prohibited. If you are notbrthe intended recipient, please contact the sender and delete the material from any computer.brpre
Re: ISAPI Redirector Work-Flow
On 01/11/2010 21:48, Richard G Curry wrote: I am trying to understand how the ISAPI Redirector functions at an overview level but deeper than this: The request comes into IIS where the ISAPI Redirector filter sends the servlet and JSP requests to the Tomcat server. I know the redirector works with AJP13 to redirect requests to the Tomcat container. What I want to know is HOW that is done. Is it a redirected HTTP request, a 301 redirect or is it a port-to-port connection between the AJP13 processor and the defined instance in the workers.properties file? It's not a redirect. The request data is converted to the AJP13 binary protocol which is received by an AJP connector in Tomcat. As this properties file defines the host name of the server holding the Tomcat instance, this can be on a different server than the IIS server, correct? Yes. Then does AJP13 'connect' directly to the defined server (localhost in all the examples I have seen) and the defined port (8009 in the same examples)? The connector opens multiple connections to the Tomcat server. If you know of a diagram that shows how this works, please share the link to that resouce. I don't sorry. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: ISAPI Redirector Work-Flow
Thank you for this, I appreciate your time. ___ «¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤» ___ Rick Curry Common Services - Software Development E2 - 066, MS 5210 972-431-9178 (Voice) 972-585-7585 (Pager) To send a (short) Text Message to my Pager: 9725857...@page.metrocall.com -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Monday, November 01, 2010 5:40 PM To: Tomcat Users List Subject: Re: ISAPI Redirector Work-Flow On 01/11/2010 21:48, Richard G Curry wrote: I am trying to understand how the ISAPI Redirector functions at an overview level but deeper than this: The request comes into IIS where the ISAPI Redirector filter sends the servlet and JSP requests to the Tomcat server. I know the redirector works with AJP13 to redirect requests to the Tomcat container. What I want to know is HOW that is done. Is it a redirected HTTP request, a 301 redirect or is it a port-to-port connection between the AJP13 processor and the defined instance in the workers.properties file? It's not a redirect. The request data is converted to the AJP13 binary protocol which is received by an AJP connector in Tomcat. As this properties file defines the host name of the server holding the Tomcat instance, this can be on a different server than the IIS server, correct? Yes. Then does AJP13 'connect' directly to the defined server (localhost in all the examples I have seen) and the defined port (8009 in the same examples)? The connector opens multiple connections to the Tomcat server. If you know of a diagram that shows how this works, please share the link to that resouce. I don't sorry. p The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient, you are hereby notified that your access is unauthorized, and any review, dissemination, distribution or copying of this message including any attachments is strictly prohibited. If you are not the intended recipient, please contact the sender and delete the material from any computer. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat ISAPI Redirector for IIS
check the fitler vs extension here is one post http://androidyou.blogspot.com/2010/08/could-not-get-worker-for-name-ajp13.html doepain wrote: No matter what I try where I go I just keep hitting a wall with this ISAPI redirector for IIS/Tomcat. I have been trying to get this to work since 9:00 AM est, and I am losing steam. I tried supplying any useful information for trouble shooting below Error: HTTP Status 404 - /jakarta/isapi_redirect.dll type Status report message /jakarta/isapi_redirect.dll description The requested resource (/jakarta/isapi_redirect.dll) is not available. Apache Tomcat/5.0.16 uriworkermap.properties File: # uriworker.properties - # # This file provides sample mappings for example # ajp13w worker defined in workermap.properties.minimal /jsp-examples/*=ajp13w /servlet-examples/*=ajp13w # Now filter out all .jpeg files inside that context # For no mapping the url has to start with exclamation (!) #!/servlet-examples/*.jpeg=ajp13w Workers.Properties.Minimal: # workers.properties.minimal - # This file provides minimal jk configuration properties needed to # connect to Tomcat. # The workers that jk should create and work with # Defining a worker named ajp13w and of type ajp13 # Note that the name and the type do not have to match. #worker.list=ajp13w worker.ajp13w.type=ajp13 worker.ajp13w.host=localhost worker.ajp13w.port=8009 Jakarta Isapi Redirector Install path: C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector\conf Tomcat Install Path: C:\Program Files\Apache Software Foundation\Tomcat 5.0 Tomcat Status is Started. IIS V6.0 Settings The jakarta Web Service Extension is Installed, and Allowed. The ISAPI Filter for jakarta in installed, and its Status is Online Priority High Host: Windows Server 2003 SP2 ISAPI-Redirector Log output: [Mon Feb 18 13:11:38 2008] [error] HttpExtensionProc::jk_isapi_plugin.c (944): could not get a worker for name ajp13 [Mon Feb 18 13:11:39 2008] [error] HttpExtensionProc::jk_isapi_plugin.c (944): could not get a worker for name ajp13 [Mon Feb 18 13:21:47 2008] [error] ajp_connection_tcp_send_message::jk_ajp_common.c (902): sendfull returned -3 with errno=54 [Mon Feb 18 13:21:47 2008] [error] ajp_send_request::jk_ajp_common.c (1158): Error sending request try another pooled connection [Mon Feb 18 13:21:48 2008] [info] jk_open_socket::jk_connect.c (183): connect() failed errno = 61 [Mon Feb 18 13:21:48 2008] [info] ajp_connect_to_endpoint::jk_ajp_common.c (862): Failed connecting to tomcat. Tomcat is probably not started or is listening on the wrong host/port (127.0.0.1:8009). Failed errno = 61 [Mon Feb 18 13:21:48 2008] [info] ajp_send_request::jk_ajp_common.c (1186): Error connecting to the Tomcat process. [Mon Feb 18 13:21:48 2008] [info] ajp_service::jk_ajp_common.c (1665): Sending request to tomcat failed, recoverable operation attempt=0 [Mon Feb 18 13:21:48 2008] [info] ajp_done::jk_ajp_common.c (1947): could not find empty cache slot from 1 for worker ajp13. Rise worker cachesize [Mon Feb 18 13:43:40 2008] [error] ajp_connection_tcp_send_message::jk_ajp_common.c (902): sendfull returned -3 with errno=54 [Mon Feb 18 13:43:40 2008] [error] ajp_send_request::jk_ajp_common.c (1158): Error sending request try another pooled connection [Mon Feb 18 13:43:41 2008] [info] jk_open_socket::jk_connect.c (183): connect() failed errno = 61 [Mon Feb 18 13:43:41 2008] [info] ajp_connect_to_endpoint::jk_ajp_common.c (862): Failed connecting to tomcat. Tomcat is probably not started or is listening on the wrong host/port (127.0.0.1:8009). Failed errno = 61 [Mon Feb 18 13:43:41 2008] [info] ajp_send_request::jk_ajp_common.c (1186): Error connecting to the Tomcat process. [Mon Feb 18 13:43:41 2008] [info] ajp_service::jk_ajp_common.c (1665): Sending request to tomcat failed, recoverable operation attempt=0 [Mon Feb 18 13:43:42 2008] [info] jk_open_socket::jk_connect.c (183): connect() failed errno = 61 [Mon Feb 18 13:43:42 2008] [info] ajp_connect_to_endpoint::jk_ajp_common.c (862): Failed connecting to tomcat. Tomcat is probably not started or is listening on the wrong host/port (127.0.0.1:8009). Failed errno = 61 [Mon Feb 18 13:43:42 2008] [info] ajp_send_request::jk_ajp_common.c (1186): Error connecting to the Tomcat process. [Mon Feb 18 13:43:42 2008] [info] ajp_service::jk_ajp_common.c (1665): Sending request to tomcat failed, recoverable operation attempt=1 [Mon Feb 18 13:43:43 2008] [info] jk_open_socket::jk_connect.c (183): connect() failed errno = 61 [Mon Feb 18 13:43:43 2008] [info] ajp_connect_to_endpoint::jk_ajp_common.c (862): Failed connecting to tomcat. Tomcat is probably not started or is listening on the wrong host/port (127.0.0.1:8009). Failed errno = 61 [Mon Feb 18 13:43:43 2008] [info] ajp_send_request::jk_ajp_common.c (1186): Error connecting to the Tomcat process
