Re: Anyone????? intermittent javax.net.ssl.SSLException: Invalid padding tomcat6.x axis 1.4 jdk 1.5 linux
Hi. From what I can see below (and what you explain yourself), this problem has nothing to do with Tomcat. It is the (your) webapp which uses an SSL connection to some other server, and which receives this exception. Tomcat does not even know that this is happening. Tomcat in this case is just the engine which runs your webapp. What may have something to do with the error, is the java JVM which is used to run both Tomcat and your webapp. Have you tried updating the JVM to a more recent version (like 1.6) ? You can run the same Tomcat (and your webapp) under the newer JVM without any change. The reason why it happens under Linux and not under Windows, is most probably because the JVM is different. Michele Mase' wrote: On Sun, Jul 25, 2010 at 9:06 PM, Michele Mase' michele.m...@gmail.comwrote: Hi folks! I've a strange problem, please help me to find a solution (not telling me to make a script in order restart tomcat in case of the exception) Under linux environment, RedHat EL5.5 Jdk 1.5.0_22 Tomcat6.0.26 axis1.4 our webapps takes strange intermittent javax.net.ssl.SSLException: Invalid padding errors. The same webapp under a windows system never catches the exception The webapps uses tomcat like a client with the axis library (1.4 version only, it is non axis 1.4 capable) in order to connect to an external webservice with https. You catch the exception after 1 hour of work, 5, 7 hours and more than 24 hours of work. Once the exception is catched, the only solution to make the webapp can work again, is to restart the tomcat. Under the windows machine we never caught the exception. Attachments: wsloader.txt is the code for the invocation of webservices. I also attach the wireshark compatible files of both situations: interop91ko.enc when it doesn't work; you can take a look at the pattern 294. http://www.ietf.org/rfc/rfc2246.txt?number=2246 bad_record_mac This alert is returned if a record is received with an incorrect MAC. This message is always fatal. interop91ok.enc when it work The attachment logs-ko.txt is the application log when it doesn't work The attachment logs-ok.txt is the application log when it works. pls, Help me! My boss wants to use the webapp under windows (migrating it from linux) since in windoz test environment we have never seen the exception Regards Michele Masè - 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: Anyone????? intermittent javax.net.ssl.SSLException: Invalid padding tomcat6.x axis 1.4 jdk 1.5 linux
Both windoz and linux use the same java :( On Fri, Sep 3, 2010 at 12:01 PM, André Warnier a...@ice-sa.com wrote: Hi. From what I can see below (and what you explain yourself), this problem has nothing to do with Tomcat. It is the (your) webapp which uses an SSL connection to some other server, and which receives this exception. Tomcat does not even know that this is happening. Tomcat in this case is just the engine which runs your webapp. What may have something to do with the error, is the java JVM which is used to run both Tomcat and your webapp. Have you tried updating the JVM to a more recent version (like 1.6) ? You can run the same Tomcat (and your webapp) under the newer JVM without any change. The reason why it happens under Linux and not under Windows, is most probably because the JVM is different. Michele Mase' wrote: On Sun, Jul 25, 2010 at 9:06 PM, Michele Mase' michele.m...@gmail.com wrote: Hi folks! I've a strange problem, please help me to find a solution (not telling me to make a script in order restart tomcat in case of the exception) Under linux environment, RedHat EL5.5 Jdk 1.5.0_22 Tomcat6.0.26 axis1.4 our webapps takes strange intermittent javax.net.ssl.SSLException: Invalid padding errors. The same webapp under a windows system never catches the exception The webapps uses tomcat like a client with the axis library (1.4 version only, it is non axis 1.4 capable) in order to connect to an external webservice with https. You catch the exception after 1 hour of work, 5, 7 hours and more than 24 hours of work. Once the exception is catched, the only solution to make the webapp can work again, is to restart the tomcat. Under the windows machine we never caught the exception. Attachments: wsloader.txt is the code for the invocation of webservices. I also attach the wireshark compatible files of both situations: interop91ko.enc when it doesn't work; you can take a look at the pattern 294. http://www.ietf.org/rfc/rfc2246.txt?number=2246 bad_record_mac This alert is returned if a record is received with an incorrect MAC. This message is always fatal. interop91ok.enc when it work The attachment logs-ko.txt is the application log when it doesn't work The attachment logs-ok.txt is the application log when it works. pls, Help me! My boss wants to use the webapp under windows (migrating it from linux) since in windoz test environment we have never seen the exception Regards Michele Masè - 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: Anyone????? intermittent javax.net.ssl.SSLException: Invalid padding tomcat6.x axis 1.4 jdk 1.5 linux
Michele Mase' wrote: Both windoz and linux use the same java :( Well no, they are NOT the same, even if they have the same version. The Windows java JVM is a Windows executable program (java.exe). The Linux java JVM is a Linux executable program. Each is compiled from presumably much the same code, but there are significant differences between them, such as for example the fact that they are linked to different native libraries (DLLs under Windows, .so libraries under Unix/Linux). So a bug can exist in one, and not in the other. And code that has to do with TCP/IP and SSL is likely quite different under each platform. Anyway, java 1.5.0 is quite old. From the java website : J2SE 5.0 End of Service Life Notice J2SE 5.0 reached its End of Service Life (EOSL) on November 3, 2009, which is the date of the final publicly available update of version 5.0 (J2SE 5.0 Update 22). You should try a recent 1.6 release (1.6.21 ?), and see if the problem still exists. Or you can continue posting the same question on this forum every couple of months, but it is unlikely that anyone would be very interested in investigating much further, until you try it and report that the issue appears in a recent JVM too. On Fri, Sep 3, 2010 at 12:01 PM, André Warnier a...@ice-sa.com wrote: Hi. From what I can see below (and what you explain yourself), this problem has nothing to do with Tomcat. It is the (your) webapp which uses an SSL connection to some other server, and which receives this exception. Tomcat does not even know that this is happening. Tomcat in this case is just the engine which runs your webapp. What may have something to do with the error, is the java JVM which is used to run both Tomcat and your webapp. Have you tried updating the JVM to a more recent version (like 1.6) ? You can run the same Tomcat (and your webapp) under the newer JVM without any change. The reason why it happens under Linux and not under Windows, is most probably because the JVM is different. Michele Mase' wrote: On Sun, Jul 25, 2010 at 9:06 PM, Michele Mase' michele.m...@gmail.com wrote: Hi folks! I've a strange problem, please help me to find a solution (not telling me to make a script in order restart tomcat in case of the exception) Under linux environment, RedHat EL5.5 Jdk 1.5.0_22 Tomcat6.0.26 axis1.4 our webapps takes strange intermittent javax.net.ssl.SSLException: Invalid padding errors. The same webapp under a windows system never catches the exception The webapps uses tomcat like a client with the axis library (1.4 version only, it is non axis 1.4 capable) in order to connect to an external webservice with https. You catch the exception after 1 hour of work, 5, 7 hours and more than 24 hours of work. Once the exception is catched, the only solution to make the webapp can work again, is to restart the tomcat. Under the windows machine we never caught the exception. Attachments: wsloader.txt is the code for the invocation of webservices. I also attach the wireshark compatible files of both situations: interop91ko.enc when it doesn't work; you can take a look at the pattern 294. http://www.ietf.org/rfc/rfc2246.txt?number=2246 bad_record_mac This alert is returned if a record is received with an incorrect MAC. This message is always fatal. interop91ok.enc when it work The attachment logs-ko.txt is the application log when it doesn't work The attachment logs-ok.txt is the application log when it works. pls, Help me! My boss wants to use the webapp under windows (migrating it from linux) since in windoz test environment we have never seen the exception Regards Michele Masè - 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: Anyone????? intermittent javax.net.ssl.SSLException: Invalid padding tomcat6.x axis 1.4 jdk 1.5 linux
Michele, I just want to clarify my previous answers : I am not saying that the problem that you encounter is *necessarily* a bug in one or the other JVM. You have not shown the code of your webapp, so we cannot tell you that the problem is there either. One thing we can tell you, is that the problem, as you show it, is *not* in the Tomcat code, because in this case Tomcat does not participate in what your webapp is doing. It is your webapp, and your webapp alone, which sets up this SSL connection with another server. The Tomcat code is not involved in this. Without a very detailed examination of your webapp code, it is not possible to say if the problem is there, and I doubt that anyone here really has the time or inclination to study your webapp code in detail. But on the surface, I would say that the chances are at least 10:1 that it is your webapp code that generates the problem. It may be doing something unsafe, which for some reason to do with the different platforms, or differences in the JVMs between those platforms, or differences between the loads on these platforms, shows up under Linux and not under Windows. So the recommendation to try a more recent JVM is not because I am sure that it is 100% of the solution to your problem. But it is the cheapest way to find out if by changing the environment a little bit, the problem still appears in the same way, or not. Under both Windows and Linux, you should be able to install a 1.6 JVM next to the 1.5 JVM, and then just set the JAVA_HOME environment variable of your Tomcat, to run under the one or the other. Maybe if you upgrade both the Windows and the Linux JVM to 1.6.21, then the problem will start appearing on both platforms. That would be a clearer sign that the problem is in the webapp. And if the problem then still appears only under Linux, then it is worth looking deeper. If the problem does not appear at all anymore, then there are 2 possibilities : - the problem was due to a bug in the Linux 1.5 JVM or one of the underlying native libraries OR - the problem is still in the webapp, but it does not show up so easily anymore under the 1.6 JVM (that would be the worse outcome, because then you are not sure anymore when it will hit you again) André Warnier wrote: Michele Mase' wrote: Both windoz and linux use the same java :( Well no, they are NOT the same, even if they have the same version. The Windows java JVM is a Windows executable program (java.exe). The Linux java JVM is a Linux executable program. Each is compiled from presumably much the same code, but there are significant differences between them, such as for example the fact that they are linked to different native libraries (DLLs under Windows, .so libraries under Unix/Linux). So a bug can exist in one, and not in the other. And code that has to do with TCP/IP and SSL is likely quite different under each platform. Anyway, java 1.5.0 is quite old. From the java website : J2SE 5.0 End of Service Life Notice J2SE 5.0 reached its End of Service Life (EOSL) on November 3, 2009, which is the date of the final publicly available update of version 5.0 (J2SE 5.0 Update 22). You should try a recent 1.6 release (1.6.21 ?), and see if the problem still exists. Or you can continue posting the same question on this forum every couple of months, but it is unlikely that anyone would be very interested in investigating much further, until you try it and report that the issue appears in a recent JVM too. On Fri, Sep 3, 2010 at 12:01 PM, André Warnier a...@ice-sa.com wrote: Hi. From what I can see below (and what you explain yourself), this problem has nothing to do with Tomcat. It is the (your) webapp which uses an SSL connection to some other server, and which receives this exception. Tomcat does not even know that this is happening. Tomcat in this case is just the engine which runs your webapp. What may have something to do with the error, is the java JVM which is used to run both Tomcat and your webapp. Have you tried updating the JVM to a more recent version (like 1.6) ? You can run the same Tomcat (and your webapp) under the newer JVM without any change. The reason why it happens under Linux and not under Windows, is most probably because the JVM is different. Michele Mase' wrote: On Sun, Jul 25, 2010 at 9:06 PM, Michele Mase' michele.m...@gmail.com wrote: Hi folks! I've a strange problem, please help me to find a solution (not telling me to make a script in order restart tomcat in case of the exception) Under linux environment, RedHat EL5.5 Jdk 1.5.0_22 Tomcat6.0.26 axis1.4 our webapps takes strange intermittent javax.net.ssl.SSLException: Invalid padding errors. The same webapp under a windows system never catches the exception The webapps uses tomcat like a client with the axis library (1.4 version only, it is non axis 1.4 capable) in order to connect to an external webservice with https.
RE: Anyone????? intermittent javax.net.ssl.SSLException: Invalid padding tomcat6.x axis 1.4 jdk 1.5 linux
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: Anyone? intermittent javax.net.ssl.SSLException: Invalid padding tomcat6.x axis 1.4 jdk 1.5 linux Both windoz and linux use the same java :( That is a myth. Besides the points André brings up, even the .class files of the JRE are different. The rt.jar file for Linux is *not* the same as the one for Windows. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Anyone????? intermittent javax.net.ssl.SSLException: Invalid padding tomcat6.x axis 1.4 jdk 1.5 linux
For Andrè If you read in a better way my mail, you find the attachment *wsloader.txt *that is the code of the bad webapp :D For Chuck Is Java really cross-platform? For all: I forgot to tell you that we are using the Strong Cryptography Library Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 5.0 and the webservices that are on the other side run unde IBM websphere. For linux: I don't want to migrate the application on windowz (my boss choice) For all: Be patient for (if/any) my english mistakes Michele On Fri, Sep 3, 2010 at 3:11 PM, André Warnier a...@ice-sa.com wrote: Michele, I just want to clarify my previous answers : I am not saying that the problem that you encounter is *necessarily* a bug in one or the other JVM. You have not shown the code of your webapp, so we cannot tell you that the problem is there either. One thing we can tell you, is that the problem, as you show it, is *not* in the Tomcat code, because in this case Tomcat does not participate in what your webapp is doing. It is your webapp, and your webapp alone, which sets up this SSL connection with another server. The Tomcat code is not involved in this. Without a very detailed examination of your webapp code, it is not possible to say if the problem is there, and I doubt that anyone here really has the time or inclination to study your webapp code in detail. But on the surface, I would say that the chances are at least 10:1 that it is your webapp code that generates the problem. It may be doing something unsafe, which for some reason to do with the different platforms, or differences in the JVMs between those platforms, or differences between the loads on these platforms, shows up under Linux and not under Windows. So the recommendation to try a more recent JVM is not because I am sure that it is 100% of the solution to your problem. But it is the cheapest way to find out if by changing the environment a little bit, the problem still appears in the same way, or not. Under both Windows and Linux, you should be able to install a 1.6 JVM next to the 1.5 JVM, and then just set the JAVA_HOME environment variable of your Tomcat, to run under the one or the other. Maybe if you upgrade both the Windows and the Linux JVM to 1.6.21, then the problem will start appearing on both platforms. That would be a clearer sign that the problem is in the webapp. And if the problem then still appears only under Linux, then it is worth looking deeper. If the problem does not appear at all anymore, then there are 2 possibilities : - the problem was due to a bug in the Linux 1.5 JVM or one of the underlying native libraries OR - the problem is still in the webapp, but it does not show up so easily anymore under the 1.6 JVM (that would be the worse outcome, because then you are not sure anymore when it will hit you again) André Warnier wrote: Michele Mase' wrote: Both windoz and linux use the same java :( Well no, they are NOT the same, even if they have the same version. The Windows java JVM is a Windows executable program (java.exe). The Linux java JVM is a Linux executable program. Each is compiled from presumably much the same code, but there are significant differences between them, such as for example the fact that they are linked to different native libraries (DLLs under Windows, .so libraries under Unix/Linux). So a bug can exist in one, and not in the other. And code that has to do with TCP/IP and SSL is likely quite different under each platform. Anyway, java 1.5.0 is quite old. From the java website : J2SE 5.0 End of Service Life Notice J2SE 5.0 reached its End of Service Life (EOSL) on November 3, 2009, which is the date of the final publicly available update of version 5.0 (J2SE 5.0 Update 22). You should try a recent 1.6 release (1.6.21 ?), and see if the problem still exists. Or you can continue posting the same question on this forum every couple of months, but it is unlikely that anyone would be very interested in investigating much further, until you try it and report that the issue appears in a recent JVM too. On Fri, Sep 3, 2010 at 12:01 PM, André Warnier a...@ice-sa.com wrote: Hi. From what I can see below (and what you explain yourself), this problem has nothing to do with Tomcat. It is the (your) webapp which uses an SSL connection to some other server, and which receives this exception. Tomcat does not even know that this is happening. Tomcat in this case is just the engine which runs your webapp. What may have something to do with the error, is the java JVM which is used to run both Tomcat and your webapp. Have you tried updating the JVM to a more recent version (like 1.6) ? You can run the same Tomcat (and your webapp) under the newer JVM without any change. The reason why it happens under Linux and not under Windows, is most probably because the JVM is different. Michele
RE: Anyone????? intermittent javax.net.ssl.SSLException: Invalid padding tomcat6.x axis 1.4 jdk 1.5 linux
From: Michele Mase' [mailto:michele.m...@gmail.com] Subject: Re: Anyone? intermittent javax.net.ssl.SSLException: Invalid padding tomcat6.x axis 1.4 jdk 1.5 linux For Chuck Is Java really cross-platform? Definitely - once the JRE is ported to the platform of interest. But down in the guts of the JRE, there is a fair amount of platform-specific code, some written in C++, some C, and some in Java. This is unfortunately necessary due to the differing APIs and functional semantics of the various platforms; consequently, different platforms may have different bugs. (Or problems on just different CPU chips, such as the recent errors seen in certain String methods when run on Intel CPUs with SSE 4.2 instructions enabled.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Anyone????? intermittent javax.net.ssl.SSLException: Invalid padding tomcat6.x axis 1.4 jdk 1.5 linux
Caldarale, Charles R wrote: From: Michele Mase' [mailto:michele.m...@gmail.com] Subject: Re: Anyone? intermittent javax.net.ssl.SSLException: Invalid padding tomcat6.x axis 1.4 jdk 1.5 linux For Chuck Is Java really cross-platform? Definitely - once the JRE is ported to the platform of interest. But down in the guts of the JRE, there is a fair amount of platform-specific code, some written in C++, some C, and some in Java. This is unfortunately necessary due to the differing APIs and functional semantics of the various platforms; consequently, different platforms may have different bugs. (Or problems on just different CPU chips, such as the recent errors seen in certain String methods when run on Intel CPUs with SSE 4.2 instructions enabled.) let me re-explain this in ASCII graphics : MachineMachineMachine type A type B type C JVM 1.6.x JVM 1.6.x JVM 1.6.x for type A for type B for type C \ |/ Java application code (*) The Java application code (*) is perfectly cross-platform, in the sense that it should run on any of the machines. That is because all the above JVM's will (or should) run the same Java code in the same way. In other words : the java application code does not see the real machine; it sees only the Java virtual machine (JVM). But the JVMs themselves are different, because they need to be specific to each machine type. That is the ideal goal of Java. In the practice, it is 99.9% that way, but there can be small differences due to the underlying platform (or to a bug in a JVM), that could make some Java code run a little bit differently on each platform. (*) of which the Tomcat code is one example, and your webapp is another example. Tomcat just starts your webapp and gives it a certain environment. But it is the JVM which runs your webapp. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
