PQ77492: EJB value in a jitc compiled method on AIX using WSAS is returned correctly the first time but not on subsequent calls | |||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description This is a problem that occurs on AIX using jdk ca131-20030329 and also on ca131-20030618. It may be that this problem has existed on all versions of ca131. Customer ran the same code on ca122 jdks (jdks for WSAS 3.5.x) and did not see a problem. . Customer code has a stateless session bean using a wrapper and in the constructor it calls a setter method on another object to set a default timeout. The value is calling integer.parseInt. This works fine in WebSphere (WSAS or WAS) 5.0 and 5.0.1 on Win2K and in WSAD. On Aix, the first time it is called after the jvm is started, it works fine, but subsequent calls fail. * The first time it is called, the value, which is 15, gets set on the called object. The second time it is called, the value that gets returned is 0, although he has verified that what is in the Hashtable is 15, not 0. The net result is that there is a timeout message immediately, rather than after 15 seconds; this is because the timeout was gets set to 0 not 15 seconds. . The first time it (the method) runs,it gets jit compiled and the second time it runs, it is using the compiled code. Setting a delay fixes the problem.Local fix There are a couple of work-arounds 1. Puting a sleep before calling the setter allows it to work. 2. Putting in a for loop (to delay the return) makes it work. 3. Using a try-catch around it to catch the number format exception locally fixes it. . 4. Disabling the JIT fixes it. 5. Putting a logging statement in the method fixes it. 6. Running remote debugger fixes it. 7. Using long.pause.long fixes it. 8. disable the jit compling for the affected methods; you may wind up having to skip jit compiling on the caller of the method that is returning the wrong result. . This is sov defect 61881. Any jdk that contains this fix will fix this problem. This is available begninning with the ca131-200308xx jdk.Problem summary **************************************************************** * USERS AFFECTED: All WebSphere Application Server users on * * AIX and using the IBM Software Developers * * Kit prior to version ca131-200308xx. * **************************************************************** * PROBLEM DESCRIPTION: An EJB value in a jit compiled method * * on AIX using WebSphere is returned * * correctly the first time but not * * on subsequent calls. * **************************************************************** * RECOMMENDATION: * **************************************************************** This is a problem that occurs on AIX using the IBM Software Developers Kit ca131-20030329 and also on ca131-20030618. It may be possible that this problem has existed on all versions of ca131. Code that has a stateless session bean using a wrapper and the constructor calls a setter method on another object to set a default timeout. The value is calling the integer.parseInt method. This works fine in WebSphere 5.0 and 5.0.1 on Windows and in WSAD. On Aix, the first time it is called after the JVM is started, it works fine, but subsequent calls fail. The first time it (the method) runs, it gets jit compiled and the second time it runs, it is using the compiled code. Setting a delay fixes the problem.Problem conclusion There are a number of work-arounds: 1. Putting a sleep before calling the setter allows it to work. 2. Putting in a for loop (to delay the return) makes it work. 3. Using a try-catch around it to catch the number format exception locally fixes it. 4. Disabling the JIT fixes it. 5. Putting a logging statement in the method fixes it. 6. Running remote debugger fixes it. 7. Using pause() fixes it. 8. Disable the jit compling for the affected methods; you may wind up having to skip jit compiling on the caller of the method that is returning the wrong result. This is sov defect 61881. Any jdk that contains this fix will fix this problem. This is available begninning with the ca131-200308xx jdk.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
Publications Referenced
|
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 00A
Software edition:
Reference #: PQ77492
IBM Group: Software Group
Modified date: Sep 3, 2003
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.