Re: isapi_redirect 1.2.30
Thanks for letting us know your solution. On 08.04.2010 02:50, Jordan Michaels wrote: Just after I sent this it occurred to me that I could map the / without it being global (IE: /=ajp13 instead of /*=ajp13), and things would work like I want them to. So I tried that, and guess what, things work great now. ;) If only I had done that several days ago! Lesson learned: non-mapped URI's don't pass cookie information. Thanks! Warm regards, Jordan Michaels Vivio Technologies http://www.viviotech.net/ Open BlueDragon Steering Committee Railo Community Distributions Jordan Michaels wrote: Alright, Unfortunately there's no way (that I have found) to get IIS to actually log what it's passing off to the connector, but in my testing I do think I discovered what the key factor is. Whenever I get this line: [debug] HttpFilterProc::jk_isapi_plugin.c (1932): [/myfile] is a servlet url - should redirect to ajpfilter Things go great. The header information contains the proper cookie line, and everything works like it should. However, whenever I see this in the logs: [debug] HttpFilterProc::jk_isapi_plugin.c (2055): [/] is not a servlet url (This is because I have IIS configured with a default document and a script map, thus no file name is actually present in the URL) The cookie header is NOT present in the request that the connector passes off to Tomcat. This is when life sucks. I can add a /*=ajp13 to the uriworkermap, and have it work because then the connector has the this is a servlet url in the logs, but without that global mapping, no cookie information is passed along. I'm not sure if this is something that can be controlled via the connector, but seeing as it is something that works fine when it's a servlet URL, it seems like something that SHOULD work when it's NOT a servlet URL. Does this make any sense? Should I file a bug report? Thank you for your help! Warm regards, Jordan Michaels Vivio Technologies http://www.viviotech.net/ Open BlueDragon Steering Committee Railo Community Distributions Rainer Jung wrote: On 05.04.2010 18:35, Jordan Michaels wrote: Okay, I will try that. I have the properties log level currently set to debug. I'll try trace and see if it can provide more information there (I didn't realize trace had more information then debug). Trace adds log lines for entering and leaving functions (not so interesting for you) but also switches from logging only the first couple of bytes in each raw AJP packet to dumping the full packet contents to the log file. It is a raw packet dump though, but since the cookie headers are strings, they can be recognized in the packet dump relatively easily. Try with a request which does send the cookie first, so you know what to look after. 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: isapi_redirect 1.2.30
Alright, Unfortunately there's no way (that I have found) to get IIS to actually log what it's passing off to the connector, but in my testing I do think I discovered what the key factor is. Whenever I get this line: [debug] HttpFilterProc::jk_isapi_plugin.c (1932): [/myfile] is a servlet url - should redirect to ajpfilter Things go great. The header information contains the proper cookie line, and everything works like it should. However, whenever I see this in the logs: [debug] HttpFilterProc::jk_isapi_plugin.c (2055): [/] is not a servlet url (This is because I have IIS configured with a default document and a script map, thus no file name is actually present in the URL) The cookie header is NOT present in the request that the connector passes off to Tomcat. This is when life sucks. I can add a /*=ajp13 to the uriworkermap, and have it work because then the connector has the this is a servlet url in the logs, but without that global mapping, no cookie information is passed along. I'm not sure if this is something that can be controlled via the connector, but seeing as it is something that works fine when it's a servlet URL, it seems like something that SHOULD work when it's NOT a servlet URL. Does this make any sense? Should I file a bug report? Thank you for your help! Warm regards, Jordan Michaels Vivio Technologies http://www.viviotech.net/ Open BlueDragon Steering Committee Railo Community Distributions Rainer Jung wrote: On 05.04.2010 18:35, Jordan Michaels wrote: Okay, I will try that. I have the properties log level currently set to debug. I'll try trace and see if it can provide more information there (I didn't realize trace had more information then debug). Trace adds log lines for entering and leaving functions (not so interesting for you) but also switches from logging only the first couple of bytes in each raw AJP packet to dumping the full packet contents to the log file. It is a raw packet dump though, but since the cookie headers are strings, they can be recognized in the packet dump relatively easily. Try with a request which does send the cookie first, so you know what to look after. 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: isapi_redirect 1.2.30
Just after I sent this it occurred to me that I could map the / without it being global (IE: /=ajp13 instead of /*=ajp13), and things would work like I want them to. So I tried that, and guess what, things work great now. ;) If only I had done that several days ago! Lesson learned: non-mapped URI's don't pass cookie information. Thanks! Warm regards, Jordan Michaels Vivio Technologies http://www.viviotech.net/ Open BlueDragon Steering Committee Railo Community Distributions Jordan Michaels wrote: Alright, Unfortunately there's no way (that I have found) to get IIS to actually log what it's passing off to the connector, but in my testing I do think I discovered what the key factor is. Whenever I get this line: [debug] HttpFilterProc::jk_isapi_plugin.c (1932): [/myfile] is a servlet url - should redirect to ajpfilter Things go great. The header information contains the proper cookie line, and everything works like it should. However, whenever I see this in the logs: [debug] HttpFilterProc::jk_isapi_plugin.c (2055): [/] is not a servlet url (This is because I have IIS configured with a default document and a script map, thus no file name is actually present in the URL) The cookie header is NOT present in the request that the connector passes off to Tomcat. This is when life sucks. I can add a /*=ajp13 to the uriworkermap, and have it work because then the connector has the this is a servlet url in the logs, but without that global mapping, no cookie information is passed along. I'm not sure if this is something that can be controlled via the connector, but seeing as it is something that works fine when it's a servlet URL, it seems like something that SHOULD work when it's NOT a servlet URL. Does this make any sense? Should I file a bug report? Thank you for your help! Warm regards, Jordan Michaels Vivio Technologies http://www.viviotech.net/ Open BlueDragon Steering Committee Railo Community Distributions Rainer Jung wrote: On 05.04.2010 18:35, Jordan Michaels wrote: Okay, I will try that. I have the properties log level currently set to debug. I'll try trace and see if it can provide more information there (I didn't realize trace had more information then debug). Trace adds log lines for entering and leaving functions (not so interesting for you) but also switches from logging only the first couple of bytes in each raw AJP packet to dumping the full packet contents to the log file. It is a raw packet dump though, but since the cookie headers are strings, they can be recognized in the packet dump relatively easily. Try with a request which does send the cookie first, so you know what to look after. 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isapi_redirect 1.2.30
On 05.04.2010 18:35, Jordan Michaels wrote: Okay, I will try that. I have the properties log level currently set to debug. I'll try trace and see if it can provide more information there (I didn't realize trace had more information then debug). Trace adds log lines for entering and leaving functions (not so interesting for you) but also switches from logging only the first couple of bytes in each raw AJP packet to dumping the full packet contents to the log file. It is a raw packet dump though, but since the cookie headers are strings, they can be recognized in the packet dump relatively easily. Try with a request which does send the cookie first, so you know what to look after. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isapi_redirect 1.2.30
Okay, I will try that. I have the properties log level currently set to debug. I'll try trace and see if it can provide more information there (I didn't realize trace had more information then debug). Yeah, I don't understand it either. It's important to note that this *only* happens when using the Default Document (no actual file name in the URL). As long as a filename is present in the URL, cookie headers are passed off perfectly. So... I'm just trying to see where the cookie header actually gets lost. I've tried both ways I know of for getting a tomcat-processed file set as a default document in IIS7 - a script map and a custom module mapping, and both methods have this problem. Thank you for your help! Warm regards, Jordan Michaels Vivio Technologies http://www.viviotech.net/ Open BlueDragon Steering Committee Railo Community Distributions Rainer Jung wrote: On 03.04.2010 01:03, Jordan Michaels wrote: Hello! I'm attempting to debug a cookie problem with the IIS7, using a default document, and the Tomcat connector. I can see where firefox is sending cookie information in the request headers to IIS, and I can see where the isapi_connector is passing the request off to Tomcat *without* cookie information, but is there any way to see what IIS is passing to the isapi_redirect DLL? Knowing what's being passed to the connector would tell me if it's an IIS7 problem or a connector problem. Thanks for any help you can offer! Best you can do is setting the log_level to trace. That will produce a lot of output. It won't show you what the plugin gets from IIS, but what we send to Tomcat from the point of view of the plugin. I can't see how we would change anything about cookies, because cookies for the plugin are just HTTP headers and as such are logged when forwarded to Tomcat. Except for the JSESSIONID cookie which in addition gets inspected for load balancing stickyness decisions. 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: isapi_redirect 1.2.30
On 03.04.2010 01:03, Jordan Michaels wrote: Hello! I'm attempting to debug a cookie problem with the IIS7, using a default document, and the Tomcat connector. I can see where firefox is sending cookie information in the request headers to IIS, and I can see where the isapi_connector is passing the request off to Tomcat *without* cookie information, but is there any way to see what IIS is passing to the isapi_redirect DLL? Knowing what's being passed to the connector would tell me if it's an IIS7 problem or a connector problem. Thanks for any help you can offer! Best you can do is setting the log_level to trace. That will produce a lot of output. It won't show you what the plugin gets from IIS, but what we send to Tomcat from the point of view of the plugin. I can't see how we would change anything about cookies, because cookies for the plugin are just HTTP headers and as such are logged when forwarded to Tomcat. Except for the JSESSIONID cookie which in addition gets inspected for load balancing stickyness decisions. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
isapi_redirect 1.2.30
Hello! I'm attempting to debug a cookie problem with the IIS7, using a default document, and the Tomcat connector. I can see where firefox is sending cookie information in the request headers to IIS, and I can see where the isapi_connector is passing the request off to Tomcat *without* cookie information, but is there any way to see what IIS is passing to the isapi_redirect DLL? Knowing what's being passed to the connector would tell me if it's an IIS7 problem or a connector problem. Thanks for any help you can offer! -JM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: isapi_redirect-1.2.30 - problem with dynamic images.
Pid Sorry I probably should have looked at this before sending my previous mail. The attached is the extracted HTML code corresponding to the images in question - I have sampled from both the 'bad' - windows 7 machine and the 'good' Server 2008 machine. There are clear differences. DB -Original Message- From: Pid [mailto:p...@pidster.com] Sent: 04 March 2010 23:26 To: Tomcat Users List Subject: Re: isapi_redirect-1.2.30 - problem with dynamic images. On 04/03/2010 21:59, David Bolsover wrote: I'm having a problem with the latest isapi_redirect-1.2.30. The problem is one of rendering some images generated dynamically (sequences of images loaded from database) using the RichFacesa4j:mediaOutput supported bya4j:poll tags to trigger image change and reload every 10 seconds. Platform: Windows 7 (32bit) IIS 7.5, x86 redirector. Images fail to render. Platform: Server 2008 (64bit) IIS 7.0 amd64 redirector. Images render correctly. When served directly from Tomcat on either platform, the images render correctly. My client for this project is also seeing the render problem when served from a Server 2008, 64bit IIS 7.0 amd64 machine. In each case, the .war loaded to Tomcat is identical. Have any other users seen similar problems? Is there an error log, an exception or some other meaningful data? What is a client seeing, in terms of bytes/data sent? p Any suggestions as to resolution? Regards, DB available since 3.0.0 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org bad - windows 7 32bit img id=j_id_jsp_1541835357_13:media style=width: 250px; height: 200px; src=/Yosemite/faces/a4j/s/3_3_1.GAorg.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk?timestamp=Fri%20Mar%2005%2009%3A48%3A58%20GMT%202010/ good server 2008 64bit img id=j_id_jsp_1823679267_13:media style=width: 250px; height: 200px; src=/Yosemite/faces/a4j/s/3_3_1.GAorg.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk;jsessionid=71C6F4DAD0D21C16873AAC8A7CC57502?timestamp=Fri%20Mar%2005%2009%3A54%3A02%20GMT%202010 complete=complete/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isapi_redirect-1.2.30 - problem with dynamic images.
On 03/05/2010 10:47 AM, David Bolsover wrote: Hi Pid I don't know if significant, but I have once seen a message generated by the 1.2.30.dll - something along the lines of the 'the server is busy'... I see you have connection errors to Tomcat. You should resolve those at the first place. Either set lower isapi connection pool or increase maxThreads on Tomcat. Also I'd suggest limiting the number of IIS workers to number of CPU's your box is having. Note that like with Httpd worker mpm, the amount of potential connections from IIS to tomcat would be (connection pool size * number of workers) Default connection pool size is 250, and nuber of workers is 5 IIRC, so that gives 1250 connections to tomcat. Set connection_pool_size = 25 and then try. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: isapi_redirect-1.2.30 - problem with dynamic images.
Hi Mladen I've tried setting connection_pool_size=25 but no help. I've also taken a look at the HTML actually being rendered - clearly different between W7 / S2K8 - see attached. DB -Original Message- From: Mladen Turk [mailto:mt...@apache.org] Sent: 05 March 2010 11:53 To: Tomcat Users List Subject: Re: isapi_redirect-1.2.30 - problem with dynamic images. On 03/05/2010 10:47 AM, David Bolsover wrote: Hi Pid I don't know if significant, but I have once seen a message generated by the 1.2.30.dll - something along the lines of the 'the server is busy'... I see you have connection errors to Tomcat. You should resolve those at the first place. Either set lower isapi connection pool or increase maxThreads on Tomcat. Also I'd suggest limiting the number of IIS workers to number of CPU's your box is having. Note that like with Httpd worker mpm, the amount of potential connections from IIS to tomcat would be (connection pool size * number of workers) Default connection pool size is 250, and nuber of workers is 5 IIRC, so that gives 1250 connections to tomcat. Set connection_pool_size = 25 and then try. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org bad - windows 7 32bit img id=j_id_jsp_1541835357_13:media style=width: 250px; height: 200px; src=/Yosemite/faces/a4j/s/3_3_1.GAorg.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk?timestamp=Fri%20Mar%2005%2009%3A48%3A58%20GMT%202010/ good server 2008 64bit img id=j_id_jsp_1823679267_13:media style=width: 250px; height: 200px; src=/Yosemite/faces/a4j/s/3_3_1.GAorg.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk;jsessionid=71C6F4DAD0D21C16873AAC8A7CC57502?timestamp=Fri%20Mar%2005%2009%3A54%3A02%20GMT%202010 complete=complete/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isapi_redirect-1.2.30 - problem with dynamic images.
On 05/03/2010 10:02, David Bolsover wrote: Pid Sorry I probably should have looked at this before sending my previous mail. The attached is the extracted HTML code corresponding to the images in question - I have sampled from both the 'bad' - windows 7 machine and the 'good' Server 2008 machine. There are clear differences. The list often strips attachments, best to post text inline. (In this case it worked). The second has a ;jsessionid=000 parameter in the URL (which isn't that surprising) and the tag has an attribute 'complete=complete'. The former might indicate something, (or it might not), the latter you may know more about. What happens if you request the image directly, with and without a session id parameter? As Mladen said, you should also address the connection errors. p DB -Original Message- From: Pid [mailto:p...@pidster.com] Sent: 04 March 2010 23:26 To: Tomcat Users List Subject: Re: isapi_redirect-1.2.30 - problem with dynamic images. On 04/03/2010 21:59, David Bolsover wrote: I'm having a problem with the latest isapi_redirect-1.2.30. The problem is one of rendering some images generated dynamically (sequences of images loaded from database) using the RichFacesa4j:mediaOutput supported bya4j:poll tags to trigger image change and reload every 10 seconds. Platform: Windows 7 (32bit) IIS 7.5, x86 redirector. Images fail to render. Platform: Server 2008 (64bit) IIS 7.0 amd64 redirector. Images render correctly. When served directly from Tomcat on either platform, the images render correctly. My client for this project is also seeing the render problem when served from a Server 2008, 64bit IIS 7.0 amd64 machine. In each case, the .war loaded to Tomcat is identical. Have any other users seen similar problems? Is there an error log, an exception or some other meaningful data? What is a client seeing, in terms of bytes/data sent? p Any suggestions as to resolution? Regards, DB available since 3.0.0 - 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_redirect-1.2.30 - problem with dynamic images.
David Bolsover wrote: Hi Mladen I've tried setting connection_pool_size=25 but no help. I've also taken a look at the HTML actually being rendered - clearly different between W7 / S2K8 - see attached. That is a puzzling factor. The link is embedded in a html page returned by Tomcat. To my knowledge, the connector itself does not modify the /content/ of a request or a response in any way, it just passes it through. So the difference should be due to the back-end Tomcat, not the connector. Or am I missing something ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isapi_redirect-1.2.30 - problem with dynamic images.
On 05/03/2010 12:56, Pid wrote: On 05/03/2010 10:02, David Bolsover wrote: Pid Sorry I probably should have looked at this before sending my previous mail. The attached is the extracted HTML code corresponding to the images in question - I have sampled from both the 'bad' - windows 7 machine and the 'good' Server 2008 machine. There are clear differences. The list often strips attachments, best to post text inline. (In this case it worked). I refer to: bad - windows 7 32bit img id=j_id_jsp_1541835357_13:media style=width: 250px; height: 200px; src=/Yosemite/faces/a4j/s/3_3_1.GAorg.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk?timestamp=Fri%20Mar%2005%2009%3A48%3A58%20GMT%202010/ good server 2008 64bit img id=j_id_jsp_1823679267_13:media style=width: 250px; height: 200px; src=/Yosemite/faces/a4j/s/3_3_1.GAorg.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk;jsessionid=71C6F4DAD0D21C16873AAC8A7CC57502?timestamp=Fri%20Mar%2005%2009%3A54%3A02%20GMT%202010 complete=complete/ The second has a ;jsessionid=000 parameter in the URL (which isn't that surprising) and the tag has an attribute 'complete=complete'. The former might indicate something, (or it might not), the latter you may know more about. What happens if you request the image directly, with and without a session id parameter? As Mladen said, you should also address the connection errors. p DB -Original Message- From: Pid [mailto:p...@pidster.com] Sent: 04 March 2010 23:26 To: Tomcat Users List Subject: Re: isapi_redirect-1.2.30 - problem with dynamic images. On 04/03/2010 21:59, David Bolsover wrote: I'm having a problem with the latest isapi_redirect-1.2.30. The problem is one of rendering some images generated dynamically (sequences of images loaded from database) using the RichFacesa4j:mediaOutput supported bya4j:poll tags to trigger image change and reload every 10 seconds. Platform: Windows 7 (32bit) IIS 7.5, x86 redirector. Images fail to render. Platform: Server 2008 (64bit) IIS 7.0 amd64 redirector. Images render correctly. When served directly from Tomcat on either platform, the images render correctly. My client for this project is also seeing the render problem when served from a Server 2008, 64bit IIS 7.0 amd64 machine. In each case, the .war loaded to Tomcat is identical. Have any other users seen similar problems? Is there an error log, an exception or some other meaningful data? What is a client seeing, in terms of bytes/data sent? p Any suggestions as to resolution? Regards, DB available since 3.0.0 - 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_redirect-1.2.30 - problem with dynamic images.
On 05.03.2010 15:04, Pid wrote: On 05/03/2010 12:56, Pid wrote: On 05/03/2010 10:02, David Bolsover wrote: Pid bad - windows 7 32bit img id=j_id_jsp_1541835357_13:media style=width: 250px; height: 200px; src=/Yosemite/faces/a4j/s/3_3_1.GAorg.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk?timestamp=Fri%20Mar%2005%2009%3A48%3A58%20GMT%202010/ good server 2008 64bit img id=j_id_jsp_1823679267_13:media style=width: 250px; height: 200px; src=/Yosemite/faces/a4j/s/3_3_1.GAorg.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk;jsessionid=71C6F4DAD0D21C16873AAC8A7CC57502?timestamp=Fri%20Mar%2005%2009%3A54%3A02%20GMT%202010 complete=complete/ The provided isapi.log doesn't contain any of the two image requests. There is no request in it which contains UserResource as part of its URL. The second has a ;jsessionid=000 parameter in the URL (which isn't that surprising) and the tag has an attribute 'complete=complete'. The former might indicate something, (or it might not), the latter you may know more about. What happens if you request the image directly, with and without a session id parameter? As Mladen said, you should also address the connection errors. Not sure. The error is only once directly after startup, so I guess the OP simply hadn't started Tomcat when he tried the first request. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: isapi_redirect-1.2.30 - problem with dynamic images.
I'm not sure I'm any further along with this... If I take this first URL (from Tomcat port 8080) and paste into my browser address bar, I get the expected image. http://localhost:8080/Yosemite/faces/a4j/s/3_3_3.CR1org.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk;jsessionid=1EE788D6C88C67E5E28CC67DA2402866?timestamp=Fri%20Mar%2005%2015%3A47%3A44%20GMT%202010 If I take this second user (from IIS via redirector 1.2.30 to tomcat), I do not get an image. http://localhost/Yosemite/faces/a4j/s/3_3_3.CR1org.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk?timestamp=Fri%20Mar%2005%2015%3A47%3A55%20GMT%202010 So it looks like the redirector (or IIS) is stripping out the jsessionid - why? I thought that the redirector should simply pass through the tomcat response - or have I got it wrong? Would the connection errors seen in isapi.log explain this? I have this particular problem on W7 32bit but not on Server 2k8 64bit implementations of the redirector. DB - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isapi_redirect-1.2.30 - problem with dynamic images.
David Bolsover wrote: I'm not sure I'm any further along with this... If I take this first URL (from Tomcat port 8080) and paste into my browser address bar, I get the expected image. http://localhost:8080/Yosemite/faces/a4j/s/3_3_3.CR1org.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk;jsessionid=1EE788D6C88C67E5E28CC67DA2402866?timestamp=Fri%20Mar%2005%2015%3A47%3A44%20GMT%202010 If I take this second user (from IIS via redirector 1.2.30 to tomcat), I do not get an image. http://localhost/Yosemite/faces/a4j/s/3_3_3.CR1org.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk?timestamp=Fri%20Mar%2005%2015%3A47%3A55%20GMT%202010 So it looks like the redirector (or IIS) is stripping out the jsessionid - why? I thought that the redirector should simply pass through the tomcat response - or have I got it wrong? And I think you are right, it should. Would the connection errors seen in isapi.log explain this? I have this particular problem on W7 32bit but not on Server 2k8 64bit implementations of the redirector. If I compare your second link with the first, there is a difference which is not only the :8080 part in the hostname. (I mean that the first link /already contains/ the jsessionid attribute, while the second one does not.) So, if you copy the second link above, and /only/ add :8080 to the hostname, and paste that in the URL bar of the browser, do you get an image or not ? I believe that the problem is not that with the first link you get an image and with the second one you do not. The problem is : - why in the first case do you get a whole html document response from the server which, among other things, contains an img link which contains a jsessionid attribute ? - and why in the second case do you get a whole html document response which, among other things, contains an img link without such a jsessionid attribute ? The problem is already there before you even click on the image link. The problem is in the page that /contains/ the link. The connector certainly does not mess with the html /content/ of the server response page. The fact that you are getting two different response pages, means eithet - that the request that /obtains/ this response page is already different - or that the server which generates this response page is different That is where the problem is. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: isapi_redirect-1.2.30 - problem with dynamic images.
Hi Andre I think the point is that the redirector IS messing with the page content. The ONLY difference between these two extracts is that one was served directly by tomcat the second via IIS /redirector to tomcat. Both of these extracts are from the problem W7 machine. I did not even close the browser session between the two - just removed 8080 from the page URL. DB -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 05 March 2010 16:28 To: Tomcat Users List Subject: Re: isapi_redirect-1.2.30 - problem with dynamic images. David Bolsover wrote: I'm not sure I'm any further along with this... If I take this first URL (from Tomcat port 8080) and paste into my browser address bar, I get the expected image. http://localhost:8080/Yosemite/faces/a4j/s/3_3_3.CR1org.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk;jsessionid=1EE788D6C88C67E5E28CC67DA2402866?timestamp=Fri%20Mar%2005%2015%3A47%3A44%20GMT%202010 If I take this second user (from IIS via redirector 1.2.30 to tomcat), I do not get an image. http://localhost/Yosemite/faces/a4j/s/3_3_3.CR1org.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk?timestamp=Fri%20Mar%2005%2015%3A47%3A55%20GMT%202010 So it looks like the redirector (or IIS) is stripping out the jsessionid - why? I thought that the redirector should simply pass through the tomcat response - or have I got it wrong? And I think you are right, it should. Would the connection errors seen in isapi.log explain this? I have this particular problem on W7 32bit but not on Server 2k8 64bit implementations of the redirector. If I compare your second link with the first, there is a difference which is not only the :8080 part in the hostname. (I mean that the first link /already contains/ the jsessionid attribute, while the second one does not.) So, if you copy the second link above, and /only/ add :8080 to the hostname, and paste that in the URL bar of the browser, do you get an image or not ? I believe that the problem is not that with the first link you get an image and with the second one you do not. The problem is : - why in the first case do you get a whole html document response from the server which, among other things, contains an img link which contains a jsessionid attribute ? - and why in the second case do you get a whole html document response which, among other things, contains an img link without such a jsessionid attribute ? The problem is already there before you even click on the image link. The problem is in the page that /contains/ the link. The connector certainly does not mess with the html /content/ of the server response page. The fact that you are getting two different response pages, means eithet - that the request that /obtains/ this response page is already different - or that the server which generates this response page is different That is where the problem is. - 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_redirect-1.2.30 - problem with dynamic images.
On 05.03.2010 17:28, André Warnier wrote: David Bolsover wrote: I'm not sure I'm any further along with this... If I take this first URL (from Tomcat port 8080) and paste into my browser address bar, I get the expected image. http://localhost:8080/Yosemite/faces/a4j/s/3_3_3.CR1org.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk;jsessionid=1EE788D6C88C67E5E28CC67DA2402866?timestamp=Fri%20Mar%2005%2015%3A47%3A44%20GMT%202010 If I take this second user (from IIS via redirector 1.2.30 to tomcat), I do not get an image. http://localhost/Yosemite/faces/a4j/s/3_3_3.CR1org.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk?timestamp=Fri%20Mar%2005%2015%3A47%3A55%20GMT%202010 So it looks like the redirector (or IIS) is stripping out the jsessionid - why? I thought that the redirector should simply pass through the tomcat response - or have I got it wrong? And I think you are right, it should. And it does. There is no code changing the contents. Would the connection errors seen in isapi.log explain this? I don't think so. As I said, there was only one error for the first request after IIS start. I guess the OP hadn't started Tomcat at that time. I have this particular problem on W7 32bit but not on Server 2k8 64bit implementations of the redirector. If I compare your second link with the first, there is a difference which is not only the :8080 part in the hostname. (I mean that the first link /already contains/ the jsessionid attribute, while the second one does not.) So, if you copy the second link above, and /only/ add :8080 to the hostname, and paste that in the URL bar of the browser, do you get an image or not ? I believe that the problem is not that with the first link you get an image and with the second one you do not. The problem is : - why in the first case do you get a whole html document response from the server which, among other things, contains an img link which contains a jsessionid attribute ? I guess, in the case with ;jsessionid there was not yet a JSESSIONID cookie set and send with the request and thus the URL encoding added the id to the URL, in the second case the request already included the cookie and thus jsessionid was not encoded. All similar img links one can see in the provided isapi log do *not* contain ;jsessionid. - and why in the second case do you get a whole html document response which, among other things, contains an img link without such a jsessionid attribute ? The problem is already there before you even click on the image link. The problem is in the page that /contains/ the link. The connector certainly does not mess with the html /content/ of the server response page. The fact that you are getting two different response pages, means eithet - that the request that /obtains/ this response page is already different - or that the server which generates this response page is different That is where the problem is. I wouldn't focus too much on the ;jsessionid difference by itself. There is also the complete difference. Futhermore the provided iapi log diesn't contain a single request for this image resource, so when it did work, I guess it had been cached by something. It looks like the whole test is not really clean, starting each time without cookies, with cleaned caches etc. to make the two situation comparable and to actually capture everything in the log. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands,
Re: isapi_redirect-1.2.30 - problem with dynamic images.
On 05/03/2010 17:03, David Bolsover wrote: Hi Andre I think the point is that the redirector IS messing with the page content. The ONLY difference between these two extracts is that one was served directly by tomcat the second via IIS /redirector to tomcat. Both of these extracts are from the problem W7 machine. I did not even close the browser session between the two - just removed 8080 from the page URL. OK, so hopefully this isn't a massive red herring: A test image (with/without jsessionid in the URL in both cases?) works over HTTP, but not over the ISAPI redirector. What do the Tomcat log IIS reports say during the single failed request? If you use LiveHttpHeaders/Firebug/ToolOfChoice to examine the headers and the response during the broken request, what do you see? Can you add logging to your application? p -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 05 March 2010 16:28 To: Tomcat Users List Subject: Re: isapi_redirect-1.2.30 - problem with dynamic images. David Bolsover wrote: I'm not sure I'm any further along with this... If I take this first URL (from Tomcat port 8080) and paste into my browser address bar, I get the expected image. http://localhost:8080/Yosemite/faces/a4j/s/3_3_3.CR1org.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk;jsessionid=1EE788D6C88C67E5E28CC67DA2402866?timestamp=Fri%20Mar%2005%2015%3A47%3A44%20GMT%202010 If I take this second user (from IIS via redirector 1.2.30 to tomcat), I do not get an image. http://localhost/Yosemite/faces/a4j/s/3_3_3.CR1org.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk?timestamp=Fri%20Mar%2005%2015%3A47%3A55%20GMT%202010 So it looks like the redirector (or IIS) is stripping out the jsessionid - why? I thought that the redirector should simply pass through the tomcat response - or have I got it wrong? And I think you are right, it should. Would the connection errors seen in isapi.log explain this? I have this particular problem on W7 32bit but not on Server 2k8 64bit implementations of the redirector. If I compare your second link with the first, there is a difference which is not only the :8080 part in the hostname. (I mean that the first link /already contains/ the jsessionid attribute, while the second one does not.) So, if you copy the second link above, and /only/ add :8080 to the hostname, and paste that in the URL bar of the browser, do you get an image or not ? I believe that the problem is not that with the first link you get an image and with the second one you do not. The problem is : - why in the first case do you get a whole html document response from the server which, among other things, contains animg link which contains a jsessionid attribute ? - and why in the second case do you get a whole html document response which, among other things, contains animg link without such a jsessionid attribute ? The problem is already there before you even click on the image link. The problem is in the page that /contains/ the link. The connector certainly does not mess with the html /content/ of the server response page. The fact that you are getting two different response pages, means eithet - that the request that /obtains/ this response page is already different - or that the server which generates this response page is different That is where the problem is. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isapi_redirect-1.2.30 - problem with dynamic images.
On 05.03.2010 17:28, André Warnier wrote: David Bolsover wrote: I'm not sure I'm any further along with this... If I take this first URL (from Tomcat port 8080) and paste into my browser address bar, I get the expected image. http://localhost:8080/Yosemite/faces/a4j/s/3_3_3.CR1org.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk;jsessionid=1EE788D6C88C67E5E28CC67DA2402866?timestamp=Fri%20Mar%2005%2015%3A47%3A44%20GMT%202010 If I take this second user (from IIS via redirector 1.2.30 to tomcat), I do not get an image. http://localhost/Yosemite/faces/a4j/s/3_3_3.CR1org.ajax4jsf.resource.UserResource/n/n/-1487394660/DATA/eAGNkk1rFEEQhitLgh9RCEYQQUE0mES0B2VzUomuiTGyyaJL!ARDzUztbg8z0213z-7IojcRFEXwKih48KIXPfkXAnrIwV8giIgXEbzaMzvoukiwb9VUv2899farbzCiFRwSqskwwLQc6AZTpEWiPGIrmtTFophYUXwODUJ2xme-lmC4Cts9RWjojIgNxcbAjmqAbXRCjJtOzQ3IM8ersIlSya3mTbgDQ1XYHAmfNzj5RT3SxjChvEilneVgJpGyBnqkmSciKWKrzerGGp0ToU-qjm1SV9fennzy9P1SCUpV2OKFqPUyRvT3DHWjeNy0M2zV9o2faxROBk5l0Ip7rZ5Vh1yUkhlshtxlS2Rawp9PpR1ccxH36gqPfSt42kdphEoUjF!PiVlGzArixx-uPBvT02EJIJV2WaX!siqkB30LK7uXqTwjiV6LWIBakmIUsvNaDj6ZHe3ix13q4Tbrr2B3b522dbDvjbP24NPP8qNsTkvyu-8P9Iu79-vfr62fyEk6F6DmyMQNuecw5lyerxxZXD7rBFo2nA6FNiladYV!i2U3U8dmDpfL0!smD3QXKCa75TnhJZENskIYM4k8NrcnLdX-Pqp!zLgYyfDe89l3N17-qGU8WXijnQnYs5EuDLcF9wfTKf7C6!VLn7!s7S70pbMzQ2dcsFpiZGJsI2FkYCy!7ktWyjSV0sDQ0V8!SyDk?timestamp=Fri%20Mar%2005%2015%3A47%3A55%20GMT%202010 So it looks like the redirector (or IIS) is stripping out the jsessionid - why? I thought that the redirector should simply pass through the tomcat response - or have I got it wrong? And I think you are right, it should. And it does. There is no code changing the contents. Would the connection errors seen in isapi.log explain this? I don't think so. As I said, there was only one error for the first request after IIS start. I guess the OP hadn't started Tomcat at that time. I have this particular problem on W7 32bit but not on Server 2k8 64bit implementations of the redirector. If I compare your second link with the first, there is a difference which is not only the :8080 part in the hostname. (I mean that the first link /already contains/ the jsessionid attribute, while the second one does not.) So, if you copy the second link above, and /only/ add :8080 to the hostname, and paste that in the URL bar of the browser, do you get an image or not ? I believe that the problem is not that with the first link you get an image and with the second one you do not. The problem is : - why in the first case do you get a whole html document response from the server which, among other things, contains an img link which contains a jsessionid attribute ? I guess, in the case with ;jsessionid there was not yet a JSESSIONID cookie set and send with the request and thus the URL encoding added the id to the URL, in the second case the request already included the cookie and thus jsessionid was not encoded. All similar img links one can see in the provided isapi log do *not* contain ;jsessionid. - and why in the second case do you get a whole html document response which, among other things, contains an img link without such a jsessionid attribute ? The problem is already there before you even click on the image link. The problem is in the page that /contains/ the link. The connector certainly does not mess with the html /content/ of the server response page. The fact that you are getting two different response pages, means eithet - that the request that /obtains/ this response page is already different - or that the server which generates this response page is different That is where the problem is. I wouldn't focus too much on the ;jsessionid difference by itself. There is also the complete difference. Futhermore the provided iapi log diesn't contain a single request for this image resource, so when it did work, I guess it had been cached by something. It looks like the whole test is not really clean, starting each time without cookies, with cleaned caches etc. to make the two situation comparable and to actually capture everything in the log. Regards, Rainer P.S.: The complete list of requests captured in the isapi log was: 09:29:06.824 [7800:4152] GET /Yosemite/ 09:29:30.529 [7800:4152] GET /Yosemite/ 09:29:53.393
isapi_redirect-1.2.30 - problem with dynamic images.
I'm having a problem with the latest isapi_redirect-1.2.30. The problem is one of rendering some images generated dynamically (sequences of images loaded from database) using the RichFaces a4j:mediaOutput supported by a4j:poll tags to trigger image change and reload every 10 seconds. Platform: Windows 7 (32bit) IIS 7.5, x86 redirector. Images fail to render. Platform: Server 2008 (64bit) IIS 7.0 amd64 redirector. Images render correctly. When served directly from Tomcat on either platform, the images render correctly. My client for this project is also seeing the render problem when served from a Server 2008, 64bit IIS 7.0 amd64 machine. In each case, the .war loaded to Tomcat is identical. Have any other users seen similar problems? Any suggestions as to resolution? Regards, DB available since 3.0.0
Re: isapi_redirect-1.2.30 - problem with dynamic images.
On 04/03/2010 21:59, David Bolsover wrote: I'm having a problem with the latest isapi_redirect-1.2.30. The problem is one of rendering some images generated dynamically (sequences of images loaded from database) using the RichFacesa4j:mediaOutput supported bya4j:poll tags to trigger image change and reload every 10 seconds. Platform: Windows 7 (32bit) IIS 7.5, x86 redirector. Images fail to render. Platform: Server 2008 (64bit) IIS 7.0 amd64 redirector. Images render correctly. When served directly from Tomcat on either platform, the images render correctly. My client for this project is also seeing the render problem when served from a Server 2008, 64bit IIS 7.0 amd64 machine. In each case, the .war loaded to Tomcat is identical. Have any other users seen similar problems? Is there an error log, an exception or some other meaningful data? What is a client seeing, in terms of bytes/data sent? p Any suggestions as to resolution? Regards, DB available since 3.0.0 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
