tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Anyone????? intermittent javax.net.ssl.SSLException: Invalid padding tomcat6.x axis 1.4 jdk 1.5 linux
Date Fri, 03 Sep 2010 13:11:23 GMT
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 <aw@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.mase@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message