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 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 >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
