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
