Re: redirecting people to maintenance mode
On 21/08/2012 17:00, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel, On 8/21/12 6:25 AM, Miguel González Castaños wrote: Dear all, I have a Tomcat web server. From time to time, I need to do some maintenance and want people not to interact with the Tomcat server while I'm doing it. The key thing here is that the Tomcat server is up and running. This is what I want to achieve: - I want all people to be redirected from 80/443 port at server1 to a different URL http://server2/maintenance.html except my IP address (so I can check Tomcat myself). - If possible, I want this to be transparent to the user, so they get a http redirect showing the server1 in the client's browser, not server2 (but this is not that important). I assume I can use iptables to redirect people to a different web server, but how can I know that I need to redirect them to the maintenance.html if that server is serving other web pages too? I don't know if you want to add this kind of complication to your environment, but this is pretty much what mod_jk was built for: distributing requests to one or more back-end Tomcat servers. With mod_jk's management interface, you can take (load-balanced) workers out of a pool, upgrade them, then add them back to the pool. Before you add them back, you can always access them directly if you have set up an HTTP Connector and you can feel free to use any technique (iptables, bind to 127.0.0.1, etc.) to prevent direct access to the HTTP port from normal users. The use of Apache httpd out in front of your app server(s) also means that you can detect error conditions in the Tomcat instance (like it's crashed or whatever) and give a semi-nice error message instead of a connection failure. This is one of those situations where using Apache httpd out in front of Tomcat makes some sense: not for performance, but for availability. See Mladen's article with explains some of the why, what and how of setting up a mod_jk-based cluster: http://people.apache.org/~mturk/docs/article/ftwai.html It makes sense. I will give it a thought. Unfortunately until we migrate to a bigger server, I'm not sure the overhead of Apache is too much. Although I know Apache is faster for static content. Many thanks for your thoughts Miguel - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tribes ManagedChannel
Hi, Is it possible to programmatically add a new ChannelListener to a ManagedChannel after the channel has been started? -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com, *Member; Apache Software Foundation; **http://www.apache.org/*http://www.apache.org/ * * *email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919 blog: **http://blog.afkham.org* http://blog.afkham.org* twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez * linked-in: **http://lk.linkedin.com/in/afkhamazeez* * * *Lean . Enterprise . Middleware* * *
Re: Problem with uploading large files
Sir, despite trying configuring in access log valves if the same error message persists then there must be some bug. It beautifully uploads from a Linux to a windows and Linux machine to linux machine(for over 10GB file size) but using windows machine as a client it just doesn't upload files above 4GB. There is no network problem as this is being done over LAN. Also I found this in the Apache website: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310476sorter/field=issuekeysorter/order=DESC check out the error Processing of multipart/form-data request failed. Stream ended unexpectedly org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly On Tue, Aug 21, 2012 at 8:35 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sahana, On 8/21/12 9:49 AM, Sahana Voleti wrote: I have tried all the techniques that we have discussed and yet I get the following error: org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing o f multipart/form-data request failed. Stream ended unexpectedly org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly Is there any other solution for this? The problem is that you aren't helping us figure out what the original problem is. This problem could occur due to a number of reasons, among them: 1. Client is sending the wrong content-length. You can verify this by checking the content-length HTTP header in the request using AccessLogValve (which has already been described) or other techniques (like writing your own Filter and fetching the value yourself). 2. Client is crashing before all bytes can be uploaded. You will have to observe the client during the connection to see if it is acting strangely. 3. There is a problem with network hardware -- some hiccup occurs and kills the connection. Does the error happen every time you try? If so, this is unlikely to be the problem. If it happens randomly, network problems may be the source of the issue. 4. A bug in commons-upload (which is very unlikely). I suspect you will simply respond saying yes, but how do I fix it? so I won't waste any more of my time asking questions you will never answer. - -=chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAzo74ACgkQ9CaO5/Lv0PB2PwCePd+tdOhDbrzZwRYyawgRB3yc FKMAn0wpuYDyo4V509Q4/3WLhKAgnfth =gFWW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with uploading large files
Bug, yes, but it sounds to me like the bug is more likely on the client end, since the common component of the failing test is the windows client; the server side seems to be fine on both Windows and Linux. Have you tried different browsers on the windows machine yet? On 8/22/2012 10:16 AM, Sahana Voleti wrote: Sir, despite trying configuring in access log valves if the same error message persists then there must be some bug. It beautifully uploads from a Linux to a windows and Linux machine to linux machine(for over 10GB file size) but using windows machine as a client it just doesn't upload files above 4GB. There is no network problem as this is being done over LAN. Also I found this in the Apache website: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310476sorter/field=issuekeysorter/order=DESC check out the error Processing of multipart/form-data request failed. Stream ended unexpectedly org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly On Tue, Aug 21, 2012 at 8:35 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sahana, On 8/21/12 9:49 AM, Sahana Voleti wrote: I have tried all the techniques that we have discussed and yet I get the following error: org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing o f multipart/form-data request failed. Stream ended unexpectedly org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly Is there any other solution for this? The problem is that you aren't helping us figure out what the original problem is. This problem could occur due to a number of reasons, among them: 1. Client is sending the wrong content-length. You can verify this by checking the content-length HTTP header in the request using AccessLogValve (which has already been described) or other techniques (like writing your own Filter and fetching the value yourself). 2. Client is crashing before all bytes can be uploaded. You will have to observe the client during the connection to see if it is acting strangely. 3. There is a problem with network hardware -- some hiccup occurs and kills the connection. Does the error happen every time you try? If so, this is unlikely to be the problem. If it happens randomly, network problems may be the source of the issue. 4. A bug in commons-upload (which is very unlikely). I suspect you will simply respond saying yes, but how do I fix it? so I won't waste any more of my time asking questions you will never answer. - -=chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAzo74ACgkQ9CaO5/Lv0PB2PwCePd+tdOhDbrzZwRYyawgRB3yc FKMAn0wpuYDyo4V509Q4/3WLhKAgnfth =gFWW -END PGP SIGNATURE- - 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: Problem with uploading large files
Yes. I have tried with Chrome and Opera David. Firefox n Explorer just fail instantly after looking at the file size over 2GB. On Wed, Aug 22, 2012 at 7:58 PM, David kerber dcker...@verizon.net wrote: Bug, yes, but it sounds to me like the bug is more likely on the client end, since the common component of the failing test is the windows client; the server side seems to be fine on both Windows and Linux. Have you tried different browsers on the windows machine yet? On 8/22/2012 10:16 AM, Sahana Voleti wrote: Sir, despite trying configuring in access log valves if the same error message persists then there must be some bug. It beautifully uploads from a Linux to a windows and Linux machine to linux machine(for over 10GB file size) but using windows machine as a client it just doesn't upload files above 4GB. There is no network problem as this is being done over LAN. Also I found this in the Apache website: https://issues.apache.org/**jira/secure/IssueNavigator.** jspa?reset=truepid=12310476**sorter/field=issuekeysorter/**order=DESChttps://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310476sorter/field=issuekeysorter/order=DESC check out the error Processing of multipart/form-data request failed. Stream ended unexpectedly org.apache.commons.fileupload.**FileUploadBase$** IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly On Tue, Aug 21, 2012 at 8:35 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sahana, On 8/21/12 9:49 AM, Sahana Voleti wrote: I have tried all the techniques that we have discussed and yet I get the following error: org.apache.commons.fileupload.**FileUploadBase$**IOFileUploadException: Processing o f multipart/form-data request failed. Stream ended unexpectedly org.apache.commons.fileupload.**FileUploadBase$**IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly Is there any other solution for this? The problem is that you aren't helping us figure out what the original problem is. This problem could occur due to a number of reasons, among them: 1. Client is sending the wrong content-length. You can verify this by checking the content-length HTTP header in the request using AccessLogValve (which has already been described) or other techniques (like writing your own Filter and fetching the value yourself). 2. Client is crashing before all bytes can be uploaded. You will have to observe the client during the connection to see if it is acting strangely. 3. There is a problem with network hardware -- some hiccup occurs and kills the connection. Does the error happen every time you try? If so, this is unlikely to be the problem. If it happens randomly, network problems may be the source of the issue. 4. A bug in commons-upload (which is very unlikely). I suspect you will simply respond saying yes, but how do I fix it? so I won't waste any more of my time asking questions you will never answer. - -=chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAzo74ACgkQ9CaO5/**Lv0PB2PwCePd+**tdOhDbrzZwRYyawgRB3yc FKMAn0wpuYDyo4V509Q4/**3WLhKAgnfth =gFWW -END PGP SIGNATURE- --**--** - To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with uploading large files
2012/8/22 Sahana Voleti sahanasithmas...@gmail.com: Sir, despite trying configuring in access log valves if the same error message persists then there must be some bug. The access log valve would not fix an error for you. It is there to help you diagnose one. Back to basics: do you know how file upload works? What protocol is? What is sent over the wire? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: redirecting people to maintenance mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel, On 8/22/12 5:04 AM, Miguel González Castaños wrote: On 21/08/2012 17:00, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel, On 8/21/12 6:25 AM, Miguel González Castaños wrote: Dear all, I have a Tomcat web server. From time to time, I need to do some maintenance and want people not to interact with the Tomcat server while I'm doing it. The key thing here is that the Tomcat server is up and running. This is what I want to achieve: - I want all people to be redirected from 80/443 port at server1 to a different URL http://server2/maintenance.html except my IP address (so I can check Tomcat myself). - If possible, I want this to be transparent to the user, so they get a http redirect showing the server1 in the client's browser, not server2 (but this is not that important). I assume I can use iptables to redirect people to a different web server, but how can I know that I need to redirect them to the maintenance.html if that server is serving other web pages too? I don't know if you want to add this kind of complication to your environment, but this is pretty much what mod_jk was built for: distributing requests to one or more back-end Tomcat servers. With mod_jk's management interface, you can take (load-balanced) workers out of a pool, upgrade them, then add them back to the pool. Before you add them back, you can always access them directly if you have set up an HTTP Connector and you can feel free to use any technique (iptables, bind to 127.0.0.1, etc.) to prevent direct access to the HTTP port from normal users. The use of Apache httpd out in front of your app server(s) also means that you can detect error conditions in the Tomcat instance (like it's crashed or whatever) and give a semi-nice error message instead of a connection failure. This is one of those situations where using Apache httpd out in front of Tomcat makes some sense: not for performance, but for availability. See Mladen's article with explains some of the why, what and how of setting up a mod_jk-based cluster: http://people.apache.org/~mturk/docs/article/ftwai.html It makes sense. I will give it a thought. Unfortunately until we migrate to a bigger server, I'm not sure the overhead of Apache is too much. Although I know Apache is faster for static content. This is a common misconception: Apache httpd is *not* faster than Tomcat for static content when configured appropriately. The current default configuration is unfortunately much less optimized than Apache httpd's default configuration, so httpd beats Tomcat out-of-the-box. If you are going to end up fronting Tomcat with Apache httpd, it's probably worth your while to push your static content out to the httpd level so that you *can* serve your static content without proxying that stuff over to your Tomcat instances. That /will/ certainly improve performance given a two-tier setup. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA1AJoACgkQ9CaO5/Lv0PANlwCgtFR4YnlMDlsH4Mb1qlb8iBjt pA8AmgP1RzyXWBNNY+n2L3pNSn7PrvAc =u3UR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with uploading large files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sahana, On 8/22/12 10:31 AM, Sahana Voleti wrote: Yes. I have tried with Chrome and Opera David. Firefox n Explorer just fail instantly after looking at the file size over 2GB. FF has a (recently-fixed) bug where it cannot properly upload files larger than 2GB. I believe this was mention on this list within the past week -- perhaps even in this thread. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA1AX0ACgkQ9CaO5/Lv0PCcpwCfY4SjIyD651d8/FCrv1UMdpxk SAAAoI/6mFL6/R75xYgPdWD5NGQ222HV =w7h4 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.x and Internet Explorer Adobe Reader plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel, On 8/21/12 10:24 AM, Miguel Gonzalez wrote: Our webapp worked fine under Tomcat 5.5. We decided to migrate to Tomcat 7 to get better performance and get support from the community in case something goes wrong as suggested in this mailing list. I installed tomcat 7.0.29 from the Apache website. I had issues downloading PDFs from IE, but not from Firefox or Chrome. I googled a little bit and some people suggested to downgrade to 7.0.26. But still having issues with it under IE while it works under Firefox and Chrome. Any ideas? http://www.catb.org/esr/faqs/smart-questions.html Your question is I had an app that was working and then I upgraded and it doesn't work. What might be the problem?. Well, the problem might be that the power isn't connected to your server. But you haven't provided any information that suggests what had issues downloading PDFs from IE means. What issues? What did you try? What happened when you did that? What have you attempted to do so far to fix the issue and what have you discovered? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA1A3sACgkQ9CaO5/Lv0PCchACeOpjj29k4FVQgs1dTSdy9sCqh eYYAnjQlZv16wzAH1HrzObrrZC/rsHei =1xQU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christovam, On 8/17/12 5:41 PM, Christovam Paynes Silva wrote: catalina.sh following settings: FYI it's better to create a bin/setenv.sh and set your environment variables, there. JAVA_OPTS=-Dfile.encoding= ISO-8859-1 ... One more nit to pick: you want to set CATALINA_OPTS instead of JAVA_OPTS. If you use JAVA_OPTS, then you are setting a 1GiB heap for the process that merely sends shutdown commands to Tomcat. -Duser.timezone=America/Sao_Paulo -server -Xms700m -Xmx1100m -XX:PermSize=626m -XX:MaxPermSize=826m -XX:+UseCodeCacheFlushing -XX:ReservedCodeCacheSize=264m -XX:CodeCacheFlushingMinimumFreeSpace=50m Finally, why are you even specifying the code-cache sizes at all? Do you have these problems when you remove *all* of the code-cache configuration parameters from your _OPTS environment variables? Generally speaking, there's no reason to adjust such settings unless you are actually having a problem. Maybe you started having code-cache-related problems before you added those settings, but you didn't say that so I assume it's not true. Instead, I assume that you are fiddling with settings that you don't need to set. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA1BNIACgkQ9CaO5/Lv0PAYtgCfQpcJdnvvX8tZD0T73qDPCBcj r+sAmQHy90LQp6IpJLDaroGXRawJ0Bp3 =Ci1j -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled
Hello Christopher, Before you even set the environment variables, I already had this problem with the cache. How was using jdk1.0.5, I upgraded to 1.0.7 jdk, messages of Java HotSpot (TM) 64-Bit Server VM warning: CodeCache is full. Compiler Has Been disabled, disappeared, however some images not loading the application. Then I read about this BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166379 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170971 I'll look on this environment variable CATALINA_OPTS 2012/8/22 Christopher Schultz ch...@christopherschultz.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christovam, On 8/17/12 5:41 PM, Christovam Paynes Silva wrote: catalina.sh following settings: FYI it's better to create a bin/setenv.sh and set your environment variables, there. JAVA_OPTS=-Dfile.encoding= ISO-8859-1 ... One more nit to pick: you want to set CATALINA_OPTS instead of JAVA_OPTS. If you use JAVA_OPTS, then you are setting a 1GiB heap for the process that merely sends shutdown commands to Tomcat. -Duser.timezone=America/Sao_Paulo -server -Xms700m -Xmx1100m -XX:PermSize=626m -XX:MaxPermSize=826m -XX:+UseCodeCacheFlushing -XX:ReservedCodeCacheSize=264m -XX:CodeCacheFlushingMinimumFreeSpace=50m Finally, why are you even specifying the code-cache sizes at all? Do you have these problems when you remove *all* of the code-cache configuration parameters from your _OPTS environment variables? Generally speaking, there's no reason to adjust such settings unless you are actually having a problem. Maybe you started having code-cache-related problems before you added those settings, but you didn't say that so I assume it's not true. Instead, I assume that you are fiddling with settings that you don't need to set. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA1BNIACgkQ9CaO5/Lv0PAYtgCfQpcJdnvvX8tZD0T73qDPCBcj r+sAmQHy90LQp6IpJLDaroGXRawJ0Bp3 =Ci1j -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christovam, On 8/22/12 12:39 PM, Christovam Paynes Silva wrote: Before you even set the environment variables, I already had this problem with the cache. Okay, good to know. How was using jdk1.0.5, I upgraded to 1.0.7 jdk AFAICT, neither of those are legal version numbers. What actual versions of the Java Development Kit are you testing? messages of Java HotSpot (TM) 64-Bit Server VM warning: CodeCache is full. Compiler Has Been disabled, disappeared, however some images not loading the application. Then I read about this BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166379 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170971 Looks like you need to update to build 1.7.0_06 which is already available. It also looks like you can probably drop the code cache settings and leave them to the default. I'll look on this environment variable CATALINA_OPTS Please do. The best place to read about CATALINA_OPTS is in the bin/catalina.sh file where those environment variables are all documented quite nicely. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA1JioACgkQ9CaO5/Lv0PClfQCfcj5YAdlttfLif92C4GpKoBB/ bDwAoLIvTxMdaVDHJE5f4+wdNlPM5bn4 =gJza -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.x and Internet Explorer Adobe Reader plugin
On Aug 22, 2012, at 11:06 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel, On 8/21/12 10:24 AM, Miguel Gonzalez wrote: I installed tomcat 7.0.29 from the Apache website. I had issues downloading PDFs from IE, but not from Firefox or Chrome. I googled a little bit and some people suggested to downgrade to 7.0.26. But still having issues with it under IE while it works under Firefox and Chrome. Any ideas? http://www.catb.org/esr/faqs/smart-questions.html Your question is I had an app that was working and then I upgraded and it doesn't work. What might be the problem?. Well, the problem might be that the power isn't connected to your server. But you haven't provided any information that suggests what had issues downloading PDFs from IE means. What issues? What did you try? What happened when you did that? What have you attempted to do so far to fix the issue and what have you discovered? We are having what sounds like a similar problem (although 7.0.26 works for us) and can provide our details. We are using Solaris 10, Tomcat 7.0.26, Apache/2.2.16, mod_jk/1.2.35 and Java(TM) SE Runtime Environment (build 1.6.0_30-b12) in our production environment. We are using the same except for the latest Tomcat 7.0.29 in our test environment. Recently one of our testers found that when using IE8 against our test environment she could not download PDFs (available as links on web pages) and would instead see the error A network error occurred while accessing this document on the Internet but it worked fine on the older Tomcat in production. Indeed if I roll our testing environment back to Tomcat 7.0.26, this problem does not occur. It also doesn't occur in any other browser we tried (IE9, FireFox 14.0.1 and Safari 5.1.7). I had remembered that something similar had been discussed on this list, but the archived thread looks like it went stale when it couldn't be reproduced: PDF Download problem tomcat = 7.0.27 (http://mail-archives.apache.org/mod_mbox/tomcat-users/201207.mbox/%3CCAC=HunuF5zqKf5s_D9syTZ1J2nFXdCjEWKj=zq+hc8bgnn1...@mail.gmail.com%3E) A good portion of our visitors use IE8 with the 9.5.1 Adobe Reader and we have a number of PDF documents available for download so I'm hoping perhaps our different configuration to the ones previously reported might eventually lead to a fix. Thank you, -Kari _ Kari Scott Senior Programmer kari.sc...@cdw.commailto:kari.sc...@cdw.com CDW 5520 Research Park Drive Madison, WI 53711 Office: 608 298 1223 Fax: 608 288 3007
Re: Tomcat 7.x and Internet Explorer Adobe Reader plugin
On 22/08/2012 18:06, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel, On 8/21/12 10:24 AM, Miguel Gonzalez wrote: Our webapp worked fine under Tomcat 5.5. We decided to migrate to Tomcat 7 to get better performance and get support from the community in case something goes wrong as suggested in this mailing list. I installed tomcat 7.0.29 from the Apache website. I had issues downloading PDFs from IE, but not from Firefox or Chrome. I googled a little bit and some people suggested to downgrade to 7.0.26. But still having issues with it under IE while it works under Firefox and Chrome. Any ideas? http://www.catb.org/esr/faqs/smart-questions.html Your question is I had an app that was working and then I upgraded and it doesn't work. What might be the problem?. Not exactly, I said problems downloading PDFs in IE. It reported an error when tried to download like it couldn't finish off the downloading (it takes forever). Well, the problem might be that the power isn't connected to your server. But you haven't provided any information that suggests what had issues downloading PDFs from IE means. What issues? What did you try? What happened when you did that? What have you attempted to do so far to fix the issue and what have you discovered? In the end downgrading to 7.0.26 has solved the issue. The person that reported that he had also issues with 7.0.26 and IE8 recognized it might be his install since it happened just with a particular file, not all PDF files. I couldn't reproduced the issue with IE8 Thanks, Miguel - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.x and Internet Explorer Adobe Reader plugin
We are having what sounds like a similar problem (although 7.0.26 works for us) and can provide our details. We are using Solaris 10, Tomcat 7.0.26, Apache/2.2.16, mod_jk/1.2.35 and Java(TM) SE Runtime Environment (build 1.6.0_30-b12) in our production environment. We are using the same except for the latest Tomcat 7.0.29 in our test environment. Recently one of our testers found that when using IE8 against our test environment she could not download PDFs (available as links on web pages) and would instead see the error A network error occurred while accessing this document on the Internet but it worked fine on the older Tomcat in production. Indeed if I roll our testing environment back to Tomcat 7.0.26, this problem does not occur. It also doesn't occur in any other browser we tried (IE9, FireFox 14.0.1 and Safari 5.1.7). I had remembered that something similar had been discussed on this list, but the archived thread looks like it went stale when it couldn't be reproduced: PDF Download problem tomcat = 7.0.27 (http://mail-archives.apache.org/mod_mbox/tomcat-users/201207.mbox/%3CCAC=HunuF5zqKf5s_D9syTZ1J2nFXdCjEWKj=zq+hc8bgnn1...@mail.gmail.com%3E) A good portion of our visitors use IE8 with the 9.5.1 Adobe Reader and we have a number of PDF documents available for download so I'm hoping perhaps our different configuration to the ones previously reported might eventually lead to a fix. As I have answered to Chris, it came down that the downgrade to 7.0.26 fixed it. Only a person reports problems that with a particular PDF file so we have assumed it's an issue with his setup. I couldn't reproduce the issue as I did with 7.0.29, so it seems there is something wrong with that version. Thanks! Miguel - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.x and Internet Explorer Adobe Reader plugin
Am 22.08.2012 22:31, schrieb Miguel González Castaños: We are having what sounds like a similar problem (although 7.0.26 works for us) and can provide our details. We are using Solaris 10, Tomcat 7.0.26, Apache/2.2.16, mod_jk/1.2.35 and Java(TM) SE Runtime Environment (build 1.6.0_30-b12) in our production environment. We are using the same except for the latest Tomcat 7.0.29 in our test environment. Recently one of our testers found that when using IE8 against our test environment she could not download PDFs (available as links on web pages) and would instead see the error A network error occurred while accessing this document on the Internet but it worked fine on the older Tomcat in production. Indeed if I roll our testing environment back to Tomcat 7.0.26, this problem does not occur. It also doesn't occur in any other browser we tried (IE9, FireFox 14.0.1 and Safari 5.1.7). I had remembered that something similar had been discussed on this list, but the archived thread looks like it went stale when it couldn't be reproduced: PDF Download problem tomcat = 7.0.27 (http://mail-archives.apache.org/mod_mbox/tomcat-users/201207.mbox/%3CCAC=HunuF5zqKf5s_D9syTZ1J2nFXdCjEWKj=zq+hc8bgnn1...@mail.gmail.com%3E) A good portion of our visitors use IE8 with the 9.5.1 Adobe Reader and we have a number of PDF documents available for download so I'm hoping perhaps our different configuration to the ones previously reported might eventually lead to a fix. As I have answered to Chris, it came down that the downgrade to 7.0.26 fixed it. Only a person reports problems that with a particular PDF file so we have assumed it's an issue with his setup. I couldn't reproduce the issue as I did with 7.0.29, so it seems there is something wrong with that version. Is your setup using tcnative? Version 7.0.27 introduced an update Changelog: Update the native component of the Tomcat APR/native connector to 1.1.23 and take advantage of the simplified distribution. (mturk) Maybe you could change your HTTP connector from protocol=http (has some autodetection for apr) to protocol=org.apache.coyote.http11.Http11Protocol and retest with 7.0.29. Bye, Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.x and Internet Explorer Adobe Reader plugin
On Aug 22, 2012, at 3:55 PM, Stefan Mayr wrote: Am 22.08.2012 22:31, schrieb Miguel González Castaños: We are having what sounds like a similar problem (although 7.0.26 works for us) and can provide our details. We are using Solaris 10, Tomcat 7.0.26, Apache/2.2.16, mod_jk/1.2.35 and Java(TM) SE Runtime Environment (build 1.6.0_30-b12) in our production environment. We are using the same except for the latest Tomcat 7.0.29 in our test environment. Recently one of our testers found that when using IE8 against our test environment she could not download PDFs (available as links on web pages) and would instead see the error A network error occurred while accessing this document on the Internet but it worked fine on the older Tomcat in production. Indeed if I roll our testing environment back to Tomcat 7.0.26, this problem does not occur. It also doesn't occur in any other browser we tried (IE9, FireFox 14.0.1 and Safari 5.1.7). I had remembered that something similar had been discussed on this list, but the archived thread looks like it went stale when it couldn't be reproduced: PDF Download problem tomcat = 7.0.27 (http://mail-archives.apache.org/mod_mbox/tomcat-users/201207.mbox/%3CCAC=HunuF5zqKf5s_D9syTZ1J2nFXdCjEWKj=zq+hc8bgnn1...@mail.gmail.com%3E) A good portion of our visitors use IE8 with the 9.5.1 Adobe Reader and we have a number of PDF documents available for download so I'm hoping perhaps our different configuration to the ones previously reported might eventually lead to a fix. As I have answered to Chris, it came down that the downgrade to 7.0.26 fixed it. Only a person reports problems that with a particular PDF file so we have assumed it's an issue with his setup. I couldn't reproduce the issue as I did with 7.0.29, so it seems there is something wrong with that version. Is your setup using tcnative? Version 7.0.27 introduced an update Changelog: Update the native component of the Tomcat APR/native connector to 1.1.23 and take advantage of the simplified distribution. (mturk) Maybe you could change your HTTP connector from protocol=http (has some autodetection for apr) to protocol=org.apache.coyote.http11.Http11Protocol and retest with 7.0.29. Bye, Stefan No, we are using the AJP connector. Connector port=8009 protocol=AJP/1.3 connectionTimeout=1 maxParameterCount=1 maxThre ads=400 redirectPort=8443 / _ Kari Scott Senior Programmer kari.sc...@cdw.commailto:kari.sc...@cdw.com CDW 5520 Research Park Drive Madison, WI 53711 Office: 608 298 1223 Fax: 608 288 3007
Re: Tomcat 7.x and Internet Explorer Adobe Reader plugin
Am 22.08.2012 23:04, schrieb Kari Scott: On Aug 22, 2012, at 3:55 PM, Stefan Mayr wrote: Am 22.08.2012 22:31, schrieb Miguel González Castaños: We are having what sounds like a similar problem (although 7.0.26 works for us) and can provide our details. We are using Solaris 10, Tomcat 7.0.26, Apache/2.2.16, mod_jk/1.2.35 and Java(TM) SE Runtime Environment (build 1.6.0_30-b12) in our production environment. We are using the same except for the latest Tomcat 7.0.29 in our test environment. Recently one of our testers found that when using IE8 against our test environment she could not download PDFs (available as links on web pages) and would instead see the error A network error occurred while accessing this document on the Internet but it worked fine on the older Tomcat in production. Indeed if I roll our testing environment back to Tomcat 7.0.26, this problem does not occur. It also doesn't occur in any other browser we tried (IE9, FireFox 14.0.1 and Safari 5.1.7). I had remembered that something similar had been discussed on this list, but the archived thread looks like it went stale when it couldn't be reproduced: PDF Download problem tomcat = 7.0.27 (http://mail-archives.apache.org/mod_mbox/tomcat-users/201207.mbox/%3CCAC=HunuF5zqKf5s_D9syTZ1J2nFXdCjEWKj=zq+hc8bgnn1...@mail.gmail.com%3E) A good portion of our visitors use IE8 with the 9.5.1 Adobe Reader and we have a number of PDF documents available for download so I'm hoping perhaps our different configuration to the ones previously reported might eventually lead to a fix. As I have answered to Chris, it came down that the downgrade to 7.0.26 fixed it. Only a person reports problems that with a particular PDF file so we have assumed it's an issue with his setup. I couldn't reproduce the issue as I did with 7.0.29, so it seems there is something wrong with that version. Is your setup using tcnative? Version 7.0.27 introduced an update Changelog: Update the native component of the Tomcat APR/native connector to 1.1.23 and take advantage of the simplified distribution. (mturk) Maybe you could change your HTTP connector from protocol=http (has some autodetection for apr) to protocol=org.apache.coyote.http11.Http11Protocol and retest with 7.0.29. Bye, Stefan No, we are using the AJP connector. Connector port=8009 protocol=AJP/1.3 connectionTimeout=1 maxParameterCount=1 maxThre ads=400 redirectPort=8443 / Same same but different: this one is also using autodetection. So you should test protocol=org.apache.coyote.ajp.AjpProtocol Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7.x and Internet Explorer Adobe Reader plugin
too many permutations of component versions to point to any one culprit start with a rock solid environment put in a ROOT.WAR that will demonstrate the aberrant Replace each component one at a time with a test version i would start with Tomcat APR/native connector something like this should work working version is _ test version is ___ save the $TOMCAT_HOME\logs output for working environment each component delta diff the catalina.*.log from test environment with working set diff the localhost.*.log from test environment with working set Finally are you CERTAIN the adobe plugin is correct for the version of your Browser? Martin __ Verzicht und Vertraulichkeitanmerkung/Naote de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Wed, 22 Aug 2012 23:31:28 +0200 From: ste...@mayr-stefan.de To: users@tomcat.apache.org Subject: Re: Tomcat 7.x and Internet Explorer Adobe Reader plugin Am 22.08.2012 23:04, schrieb Kari Scott: On Aug 22, 2012, at 3:55 PM, Stefan Mayr wrote: Am 22.08.2012 22:31, schrieb Miguel González Castaños: We are having what sounds like a similar problem (although 7.0.26 works for us) and can provide our details. We are using Solaris 10, Tomcat 7.0.26, Apache/2.2.16, mod_jk/1.2.35 and Java(TM) SE Runtime Environment (build 1.6.0_30-b12) in our production environment. We are using the same except for the latest Tomcat 7.0.29 in our test environment. Recently one of our testers found that when using IE8 against our test environment she could not download PDFs (available as links on web pages) and would instead see the error A network error occurred while accessing this document on the Internet but it worked fine on the older Tomcat in production. Indeed if I roll our testing environment back to Tomcat 7.0.26, this problem does not occur. It also doesn't occur in any other browser we tried (IE9, FireFox 14.0.1 and Safari 5.1.7). I had remembered that something similar had been discussed on this list, but the archived thread looks like it went stale when it couldn't be reproduced: PDF Download problem tomcat = 7.0.27 (http://mail-archives.apache.org/mod_mbox/tomcat-users/201207.mbox/%3CCAC=HunuF5zqKf5s_D9syTZ1J2nFXdCjEWKj=zq+hc8bgnn1...@mail.gmail.com%3E) A good portion of our visitors use IE8 with the 9.5.1 Adobe Reader and we have a number of PDF documents available for download so I'm hoping perhaps our different configuration to the ones previously reported might eventually lead to a fix. As I have answered to Chris, it came down that the downgrade to 7.0.26 fixed it. Only a person reports problems that with a particular PDF file so we have assumed it's an issue with his setup. I couldn't reproduce the issue as I did with 7.0.29, so it seems there is something wrong with that version. Is your setup using tcnative? Version 7.0.27 introduced an update Changelog: Update the native component of the Tomcat APR/native connector to 1.1.23 and take advantage of the simplified distribution. (mturk) Maybe you could change your HTTP connector from protocol=http (has some autodetection for apr) to protocol=org.apache.coyote.http11.Http11Protocol and retest with 7.0.29. Bye, Stefan No, we are using the AJP connector. Connector port=8009 protocol=AJP/1.3 connectionTimeout=1 maxParameterCount=1 maxThre ads=400 redirectPort=8443 / Same same but different: this one is also using autodetection. So you should test protocol=org.apache.coyote.ajp.AjpProtocol Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
