link管理
链接快照平台
- 输入网页链接，自动生成快照
- 标签化管理网页链接
相关文章推荐
|
仗义的大象 · excel数据筛选技巧：应用切片器对多数据透 ...· 3 周前 · |
|
|
酒量小的小蝌蚪 · 婚戒物语 - 萌娘百科 万物皆可萌的百科全书· 3 周前 · |
|
|
跑龙套的蚂蚁 · python找出两个集合中相同的数 - ...· 4 月前 · |
|
|
踏实的墨镜 · 零充手游盒子3.0.24325 ...· 5 月前 · |
|
|
激动的烤地瓜 · Impala查询功能测试-阿里云开发者社区· 8 月前 · |
When the Administration Console created an Application MBean, the associated WebAppComponent MBean incorrectly inherited the Application MBean name instead of the WebAppComponent's URI name. This caused the deployer tool to incorrectly create an additional deployment repository for this application when it was updated.
This defect was corrected by a code change.
Navigation through the directories did not go through action servlet, so encoding was not set properly.
A change was made to set the encoding explicitly in the page, so the correct encoding is used to produce the response.
Propagation from list page to realm deletion changed the MBean class name specific to the MBean to be deleted. Because of this MBean showed only the last deleted type MBeans in the list.
A attribute (original class name from list) has been introduced which will be propagated in the above described flow. This attribute provides a way to recover the original class name and listing remains undisturbed. This solution applies to all MBean types.
The console jsp that was used to upload applications to remote servers was calling the ApplicationManager.update() method even when the server was not in development mode.
Removed the call to ApplicationManager.update() if ProductionMode is enabled. Uploaded applications are no longer automatically deployed when Production Mode is enabled.
A NullPointerException sometimes appeared on the Administration Console while the WebApplication Deployment Descriptor was being edited.
WebLogic Server was not checking for the descriptor being null, which is the case when it can not be parsed. For this reason a NullPointerException was thrown.
If the descriptor is null, the proper error action will now be called to display the correct message.
The correct icons were not being retrieved by the console pages due to changes in the getServletContext code to be in compliance with the Servlet 2.3 specification.
Code changes were made to buildIconList() to provide the path to the images subdirectory in the console.war.
Correct icons now appear in the navigation applet.
Creating a new ACL with a blank Permission caused an unexpected error. This was due to names not being checked for null and blank values under some circumstances.
Appropriate checks have been added, and messages for null names have been corrected.
The getParameter() method in GraphApplet is used to get the value of the min/max heap size. Although the return type is long, WebLogic Server was using Integer.parseInt to convert the string values. When the heap size was over 2G, there was an overflow in the integer value. Because of this, the current free memory was sometimes reported as a negative number.
WebLogic Server now uses Long.parseLong to avoid overflow and to get the correct value of the heap even if it is over 2G .
WebLogic Server was sending a file link to the browser to report the results of start cluster and start/kill domain operations. That link worked only if the browser was running on the same machine as the administration server. This occurred on all platforms.
WebLogic Server now sends a action link which will process the file and send the output to the browser in an HTML format.
When a JMSJDBCStore was created, the "None" option was eliminated from the Connection Pool drop down list.
Adding the ability to make JDBCConnectionPool null restored "None" to the list.
When an application with an incorrect web.xml file was added to the applications directory, the Administration Console reported it as having been deployed even though it was not deployed at startup.
WebLogic Server now correctly reports such applications as undeployed.
WebLogic Server was using the greater than symbol, '>', as the Token delimiter. Because of this, if a custom message contained a '>', it was being truncated while being displayed.
WebLogic Server no longer truncates the last token when writing to the log.
readClassDescriptor() of MsgAbbrevInputStream was trying to resolve a class and throwing a ClassNotFoundException for unknown classes. Java serialization will skip this ClassNotFoundException if corresponding data is not being read.
readClassDescriptor() of MsgAbbrevInputStream no longer tries to resolve unknown classes and MsgAbbrevInputStream implemented resolveClass().
ReplicatedSessionContext has two hashtables, one of which stores the sessions for which the server is primary, and the other stores sessions for which the server is secondary. The hashtable with secondary sessions has sessionId as a key and ROID as value.
When a session was invalidated and the request to remove the session came to the secondary server, WebLogic Server passed the ROID to the ReplicatedSessionContext, iterated over the values in the hashtable in order to compare ROID with that value, and then removed the entry. WebLogic Server now avoids iterating over the hashtable by passing the sessionId instead of ROID.
weblogic.cluster.MulticastObjectListener was locked on a call to objectAdded and waited to lock a HashMap while in a different thread MulticastReceiver locks the HashMap and attempted a lock on MulticastObjectListener. This caused a Java Level Deadlock.
Changing the lock order eliminated the deadlock.
When a node in cluster was restarted, it first tried to synchronize with other cluster members resulting in one server adding the other to the cluster view.
Before that cluster node opened the listen port, if a request came in with this cluster node as a secondary, it resulted in an error and from that point on all requests to create secondaries on that cluster node failed.
Now during cluster synchronization, when a node is coming up, it first identifies all the running nodes in a cluster and then sends out a broadcast identifying itself. This ensures that the cluster node coming up is identified by other nodes after it opens a listen port.
When a Dynamic Proxy that implemented interfaces declared inside the web application was put into the HttpSession and the session was replicatable, WebLogic Server was not able to load the interface classes on the secondary server.
Dynamic Proxies implementing interfaces stored in the application archive can now be put into HttpSession and be correctly replicated.
The cluster members timed out if they did not receive a heartbeat within the default 30 second timeout period. Heartbeats were sent every 10 seconds and servers waited for 3 periods (total wait time was 30 seconds) to get a heartbeat before the cluster member was timed out and declared unavailable. For example, during session replication if the secondary server was unavailable at TCP level, the 30-second period was sometimes too long for a very busy web site. Before the secondary was removed from the cluster view, the primary tried to replicate many sessions to the secondary and thus caused the server to hang or made the server slower.
The timeout value IdlePeriodsUntilTimeout is now tunable. It is set on the <Server IdlePeriodsUntilTimeout="3"> tag in the config.xml file. In general customers should not tune this value and should leave it at the default (3). However, in certain cases depending on the load, available redundancy in the architecture and specific application problems and/or certain production scenarios, tuning this value carefully might alleviate the problem temporarily until the root cause is identified and fixed.
BEA WebLogic recommends that you use HIGH caution when changing this value and ensure sufficient testing of your application at peak load scenarios to ensure the expected behavior. There is no recommendation that fits all scenarios, so testing for load and stress is a must if this value needs to be changed.
When a request landed on a server that was neither primary nor secondary, it got the session from the existing secondary by looking it up on the secondary server with the host port information from the session id.After it successfully got the session from existing secondary it removed the existing session and tried to create a new session.
When two such requests occurred at the same time a distributed deadlock could occur since these requests landed on the 'Replication' thread queue and the 'Replication' thread queue had only two threads and there was no other thread available for reading the response.
Code was added to WebLogic Server which fixed the problem so that it will not deadlock.
In WebLogic Server 7.0 and higher, the javax.ejb.TransactionRolledbackLocalException's SVUID was changed and when WebLogic Server 7.0 or 8.1 experienced a javax.ejb.TransactionRolledbackLocalException when a WebLogic Server 6.1 client made a remote call to ejb hosting by a WebLogic Server 7.0 or 8.1 server instance, it experienced an InvalidClassException.
This problem is fixed in WebLogic Server 6.1 so that it now understands the incoming final-ejb20 ClassDescriptor for javax.ejb.TransactionRolledbackLocalException.
Stopping a windows service configured with beasvc.exe sometimes caused a timeout when a stopclass was specified. The service was timing out because there was a race condition between the stop and main threads of beasvc.exe.
The race condition has been corrected and the windows service no longer times out.
A ConcurrentModificationException was thrown when the monitoring subsystem was trying to read the values of the abbrev table and at the same time the abbrev table was being modified by the rjvm layer.
Cloning the key set before sending the data to the monitoring subsystem so that the HashMap is not modified simultaneously by two threads eliminates the ConcurrentModificationException.
When an application cached a stateless session bean remote stub, and all the servers in the cluster were restarted, the stub was unable to refresh its lists of server nodes where the remote object was available and failover did not succeed. This was happening because the stub did not have the information needed to re-establish the initial context with the cluster nodes, hence the remote method invocation failed.
WebLogic Server code was not propagating the thread environment for the stateless session bean stubs in WebLogic Server 6.1 versions and it is required in WebLogic Server 7.0 and higher versions for unmarshalling to set the environment so failover works.
The runtime descriptors for the clusterable stateless session beans now have the propagate-environment attribute set to true by default.
The descriptor is now read and the propagateEnvironment is set so the environment is passed on during unmarshalling. This will allow the failover logic to reconnect to the cluster nodes to retrieve the new list of server nodes where the remote object is available and allow for proper failover.
Every time the beasvc service handler was called, the beasvc log added a line indicating that it was called.
For example:
Tue Apr 27 11:52:17 2004] [I] [service_ctrl] 4
This caused the log to fill up when there was no real activity on the server.
The debug statement was removed, eliminating the log problem.
WebLogic Server running as a service sometimes ran out of memory if it was using a large number of threads.
Reducing the reserve stack size used by beasvc.exe and beasvc64.exe from 1mb to 256kb eliminated the memory problem.
Stateful Session Bean handles taken from the 70 (or 81) WebLogic Server servers to WebLogic Server 61 server/client were failing with a ClassNotFoundException in the serialization code.
Compared to the WebLogic Server 6.1 server, WebLogic Server 70 and 81 servers used a different PK mechanism for SFSB in the ejb container.
Adding the necessary classes to 6.1 line to support the inter-op requirement eliminated the ClassNotFoundException.
According to the documentation in "Starting and Stopping Servers" if the CLASSPATH is too long, it can be added as a single line to a file and then accessed as -classpath @filename. However, when beasvc attempted to load the contents of CLASSPATH file, it truncated the last character when the file did not end with a new line.
Now beasvc determines whether the file terminates properly and then reads the file accordingly.
Interoperability between 6.1 SP04 and 8.1 SP02 us t3 was failing when the protocol was changed from "secure" to "non-secure" between the front-end and back-end. The front-end QOS was being propagated to the back-end for the authentication call and it was failing.
The problem was resolved by using "anonymous" when doing the bootstrap authenticate call.
When <<no stack trace available>> was sent out as part of the exception message field (from the server side) rmi layer was recursively adding / appending the exception as server side stack trace. This was filling up the log files. This manifested when the server was running out of heap and there was a NullPointerException thrown by the application code (EJB + Servlets)
WebLogic Server now parses the exception message field, traps this specific exception and ensures that it is appended only once.
Under heavy load, T3File client often threw an ArrayIndexOutOfBoundsException when closing OutputStream/InputStream.
WebLogic Server now acquires the lock on the Vector before starting the loop.
Installing WebLogic Server as a Windows service immediately after uninstalling it sometimes created wrong registry keys, which could lead to startup problems.
A code fix ensure that the registry keys are flushed and properly closed.
When setting the maximum length of an execute queue with the -Dweblogic.kernel.allowQueueThrottling flag to throttle "slow moving resource intensive" requests on a custom queue, clients did not receive a 503 response and therefore waited for the timeout.
This problem was resolved by a code fix to check for the dispatch return value on the caller and use the sendError() API to return the 503 response.
According to the documentation at "Starting and Stopping Servers" if the CLASSPATH is too long, it could be added as a single line to a file and then accessed as -classpath @filename. However, this was not working because when beasvc attempted to load the contents of CLASSPATH file, it sometimes truncated the last character. This only happened when the file did not end with a new line.
A code change was made so beasvc figures out whether the file terminates properly and is then read accordingly."
A distributed deadlock occurred due to a failure to maintain session stickiness with the primary server. When a request lands on the server which is neither primary nor secondary, it will try to remove the existing session from the primary as well as the secondary and create a new one on the current server and register a new secondary to it. In doing so, this server makes a remote request to the primary to remove the session on non-blocking queue, the primary server makes a remove call to the secondary server to remove itself on non-blocking queue. If there are more than one such requests, there will be no other thread to receive the response on the current server since there will be only two threads available in non-blocking queue and hence there is a distributed deadlock.
WebLogic Server now makes no new remote requests while processing requests that come in on a non-blocking queue. This fixes the problem, as it ensures that there will always be a thread available in the non-blocking queue to receive a response.
When <validate-db-schema-with>MetaData</validate-db-schema-with> was used AND a cmp-field and a cmr-field were mapped to the same column, a java.lang.IndexOutOfBoundsException was being thrown.
WebLogic Server has been modified and this exception is no longer thrown under these circumstances.
When a EJB QL syntax error occurred, WebLogic Server generated an error message with an incorrect xml file reference.
WebLogic Server now generates the message as follows if there are syntax errors in EJB QL.
[java] ERROR: Error from ejbc: Error while reading 'META-INF/ejb-jar.xml' or 'META-INF/weblogic-cmp-rdbms-jar.xml'. The error was:
For BLOBs, in the generated code, WebLogic Server calls ObjectOutputStream.writeObject and ObjectInputStream.readObject to serialize/deserialize the object before writing/reading it to the database. These calls add extra header information. The writeObject method writes the class of the object, the signature of the class, the values of the non-transient and non-static fields of the class, and all of its supertypes are written. (This is the reason for the extra header seen in the database.) These calls do not cause a problem when customers are using only WebLogic Server to set and get BLOBs, because it uses readObject to convert the bytes into the appropriate object, which needs that extra header information. However, if the BLOB has been inserted directly into the database by some other vendor or programmer using:
OutputStream os = ((weblogic.jdbc.common.OracleBlob) lob).getBinaryOutputStream(); os.write(this.tiffImage); // byte[] tiffImage
then problems may occur because WebLogic Server uses readObject and the header information is missing. For the data inserted using WebLogic Server, the other programs that would read the bytes directly get the extra header information and fail.
A system property has been added which allows WebLogic Server to correctly report header information.
A high value for idleTimeoutSecs, for instance, 60000000, in the Deployment Descriptor when multiplied by 1000 to convert it into msecs was overflowing into a negative value. This caused the trigger that cleans the passivated beans from the disk to constantly fire, causing high CPU usage.
The variables within the EJB container which held the timeout values in milliseconds, such as idleTimeoutMS, sessionTimeoutMS, and readTimeoutMS, have been changed from the int type to long. This prevents any numeric overflow.
EJBStatelessHomeRuntimeMBean's implementation class did not provide correct details of pool statistics.
Code was changed to provide the correct pool statistics in the runtime mbean methods.MBean calls now show the correct data.
The Stateful EJB monitoring page did not have the machine name prefixed to its output
so it was impossible to see to which machine the entry referred.
The machine name was added to the Stateful EJB monitoring page.
The read-only concurrency strategy in 6.x used Exclusive concurrency. This guaranteed exclusive access to the bean, but not to the generated Set for the 1-N relationship. It was possible for two clients to get access to the same Set. In such a case, when some method was called on the relationship Set, it caused a NullPointerException.
Relevant code changes were made to guarantee exclusive access to the relationship Set to fix the issue.
In WebLogic Server 6.1 SP04, the Administration Console reported incorrect values for waiters for entity beans.
The problem was solved by adding a waiterCurrentCount attribute that is incremented when a client starts waiting for a lock and decremented when the lock is acquired or the client times out.
EJBContext.getRollbackOnly() returned "true" if a transaction marked for rollback and had not yet been rolled back. After the transaction was rolled back, it returned "false".
EJBContext.getRollbackOnly() now returns "true" even if the transaction has already been rolled back.
The Administration Console was not exposing the Transactions Committed Total Count, the Transactions Rolled Back Total Count or the Transactions Timed Out Total Count for Stateful and Entity EJBs.
The Administration Console now allows monitoring of these items.
The EJBDeployer was writing an incorrect deployment message to the log for Message Driven Beans.
The correct message is now being logged when a Message Driven Bean is deployed.
MessageLocalizer was not setting the l10n_package attribute in localized catalog files using the l10ngen utility.
MessageLocalizer now correctly sets the l10n_package attribute in a localized catalog file.
After a long database outage, a JDBC connection pool that used the XA jDriver for Oracle with TestConnectionsOnReserve="true" could not recover and recreate connections to the database. The following error messages were thrown:
<Warning> <JDBC> <001096> <Refreshing this bad pool connection failed weblogic.common.ResourceException: java.sql.SQLException: open failed for XAResource 'oracleXAPool' with error XAER_RMERR: A resource manager error has occurred in the transaction branch.
<Warning> <JDBC> <001096> <Refreshing this bad pool connection failed weblogic.common.ResourceException: java.sql.SQLException: LDA pool exhausted - make sure you call Connection.close()
The problem was that during the outage, the JDBC connection pool attempted to recreate connections, but on failure, those connection attempts were not cleaned up and were depleting Oracle client resources (in the LDA).
The jDriver now cleans up connection creation attempts that fail.
class weblogic.db.oci.OciLob defined two class level variables to hold the returned byteArray for either BLOB or CLOB data from database. As this byte array could be quite large each instance of OciLob filled up the heap quickly until a garbage collection occurred.
Further testing and a modified OciLob moving the class level variables retBArray[] and retCArray[] into the methods caused the variable to be allocated on the stack and reduced the size of the OciLob object instance and thus overall heap usage was reduced.
Code was added to move the global variables retBArray and retCArray to the method level in order to reduce the size of the memory heap usage.
The WebLogic Server jDriver was not functioning properly with Oracle 9.2 when using the AL32UTF8 character set.
This problem was resolved with a code fix.
WebLogic jDriver may cause the server to crash with Oracle error message ORA-02392 when using the long raw type under heavy loads.
A code fix was implemented to resolve this issue.
WebLogic Server Oracle jDriver was not properly releasing Clob Objects for garbage collection.
WebLogic Server now releases Clob Objects correctly.
In previous releases, methods in the weblogic.jdbc.common.Pool and weblogic.jdbc.common.JDBCServices interfaces were referenced in the Programming WebLogic JDBC guide, but the Javadocs for those interfaces were not published.
In WebLogic Server 6.1 SP7, the Javadocs for these interfaces are published at ../javadocs/weblogic/jdbc/common/package-summary.html. Note, however, that the methods in these interfaces have been deprecated and are not available in WebLogic Server 7.0 and 8.1.
Statement.getResultSet() sometimes generated an unnecessary new ResultSet wrapper for the one underlying DBMS resultset, if a result set had already been returned to the user code. If the user code had run an executeQuery() call first, without retaining the result set it returned, garbage-collecting could close it immediately, with the underlying DBMS resultset, invalidating and prematurely closing any result set returned by a subsequent getResultSet() call.
WebLogic Server no longer generates unnecessary wrappers due to a code change.
WebLogic Server sometimes threw an incorrect warning about a JDBC connection leak that began:
[SerialConnection]: Connection Leak detected!!!!!!java.lang.Throwable: StackTrace at creation of connection: /n
The leak detection code that sent this warning is obsolete. A code change resolved the problem.
In jta.DataSource, when doing refreshAndEnlist, WebLogic Server called tx.enlist(), but the connection was not returned to the pool if there was an exception in the refreshAndEnlist call.
A code change catches the exception and releases the connection to the pool.
When an EJB transaction created many new entities or otherwise engaged many beans that all use JDBC, WebLogic Server risked running out of Oracle cursors, because in an attempt to avoid a suspected Oracle driver bug, WebLogic Server delayed closing JDBC statements until the end of a transaction, holding the cursors for the statement until then.
This behavior has been changed so that the session need not hold cursors until the transaction ends.
New versions of JDBC drivers track the transactional state of connections. If a local transaction was active on a connection, XA operations could not be performed on it, resulting in an XAER_PROTO or XAER_RMERR when an xa_start() was called on the connection. As a result, applications had to go through the tedious process of narrowing down where in their code they had started but not ended a local transaction.
The problem was resolved by a code change in the recovery method that prevents special XA connections from being released to the pool twice.
WebLogic JMS was not receiving notification when ServerDebugMBean() JMS attributes were changed.
The ServerDebugMBean() can now be used to dynamically enable and disable "DebugJMS" ServerDebugMBean attributes. This allows customers to dynamically enabled or disable JMS Debugging flags.
Under certain circumstances when a server with JMS messages in a pending state was shut down or crashed, pending messages were not recovered when the server was restarted.
Pending messages are now recovered upon restarting the server.
In previous WebLogic Server 6.1 service packs, when the server instance went down but its clients remained active, JMS threw a runtime exception weblogic.rmi.extensions.RemoteRuntimeException, instead of a JMSException as expected per the JMS specifications.
A code change has resolved the problem in this Service Pack.
A receiver stops processing messages when a RedeliveryLimit is configured and the number of times the RedeliveryLimit is reached is greater than the MessagesMaximum setting on the ConnectionFactory.
Example: RedeliveryLimit=0, MessagesMaximum=10. Receiver receives a message and calls sesssion.recover() 10 times. Receiver will stop processing messages and the console will show 10 messages pending.
Code was added to adjust the window counter when a message is removed from the queue because the RedeliveryLimit had been reached.
An idle bridge was logging a message after the maximum idle time setting had been reached.
Code was added to suppress the repetitive log message "Bridge X start transferring messages" logged by an idle bridge.
If the bridge is stopped and restarted, or if it encounters an exception and is restarted you will see the "Bridge "bridgename" starts transferring messages" log message, but you will not see the repetitive message logged by an idle bridge.
Enhancement request to allow explicit naming of JDBC driver being used in class VendorId.
This customer enhancement was made through a code change.
When the character encoding was set by JSP pages or servlets, the ServletOutputStream.write(int) method, which takes int type as its argument, received the data encoded using the specified charset encoder.
WebLogic Server no longer encodes the binary data when ServletOutputStream.write(int) is called.
WebLogic Server was sending wlsproxy specific headers even when the request did not originate with a proxy.
Code was added to check if the request is coming from a proxy and send the appropriate header.
The HttpSessionBindingListener were not getting fired correctly. In some cases they were invoked twice.
Re-implementing the callbacks strictly per the Servlet Specification fixed this problem.
A web application that had a local EJBObject reference in its session, sometimes got an javax.ejb.EJBException after it was redeployed.
Code was added to catch the exception and log a message. An error message is now logged to indicate serialization failure and the getAttribute() of HttpSession, ServletRequest or ServletContext returns null under these circumstances.
There was a problem that was preventing serving custom error pages, if the request was a conditional GET (Is-Modified-Since header set) for a protected resource.
The logic was fixed to serve the custom error page if one is defined.
Code that used a response wrapper and called getOutputStream on the original response passed into a JSP resulted in NestedBodyResponse always throwing an IllegalStateException.
Mixed use of getWriter() and getOutputStream() from NestedBodyResponse are now allowed, so the exception will only be thrown when appropriate.
A protocol exception, excjava.net.ProtocolException: Didn't meet stated Content-Length, was occurring when a client cancelled a request while the default fileServlet was sending a file.
This was resolved with a code change.
WebLogic Server decoded the path /foo/bar%c0%baz/ to /foo/bar because sun.io.ByteToCharConverter stopped converting the remaining bytes if it encountered bytes that were not valid in UTF8 (for example, 0xc0). This problem does not occur on JDK 1.4.
The problem was resolved with a WebLogic Server UTF-8 converter that replaces invalid UTF-8 sequences with U+FFFD characters. As a result of this fix, the path /foo/bar%c0%baz/ is decoded to /foo/bar?%baz.
The java.lang.IllegalStateException: HttpSession is invalid exception occurs in the servlet container's internal call. If other threads using the same session ID invalidate the session object during processing of ServletRequestImpl.syncSession(), an IllegalStateException may occur while calling SessionData.putValue() or SessionData.isNew().
Ignore the IllegalStateException if the session has been invalidated by other threads.
When a Serializable Servlet request attribute was added, and then overwritten it with a non-Serializable value, the original value masks the new one.
A code change was made to try to remove the value from a HashMap table of serializable attributes if necessary, when replacing a Serializable value with a non-Serializable one.
On a Web server without a default Web application, an HTTP request for a missing resource received a response that included an incorrect date header:
HTTP/1.1 404 Not Found Date: Thu, 01 Jan 1970 00:00:00 GMT
This header is not valid according to section 14.18 of RFC2616. A code change resolved the problem.
HttpClusterServlet threw this exception, when KeepAliveEnabled was set to true after a large file download was canceled.
Analysis revealed that when a client canceled a file download, the remaining data was left in the inputstream. If the socket was recycled for a subsequent request, the servlet read the remaining data, resulting in the exception.The problem was solved with a code fix to drain the inputstream and if the download is canceled we will read this remaining data.
ServletContext.setAttribute threw a NullPointerException when a null value was passed to it.
The problem was resolved by a code change that calls removeAttribute() when a null value is passed to the setAttribute().
Using ServletOutputStream.write(byte) to write more than the buffer size caused infinite loop.
A code change resolved the problem by updating the check for boundary conditions when the buffer is full and autoflush is set to false.
After a protocol exception, the server hung while trying to process a new license because of a problem with the ensureContentLength method.
A code change ensured that the server no longer hangs during this process.
breakUpAndWriteItOutAsNecessary() tried to separate a manifest header to enforce a maximum of 72 bytes per line, and wrote one line to an outputstream at a time. The cause of this problem was that the start offset for the new line is wrong.
A code change resolved the problem.
A JSP in a subcontext of the root context was precompiled when deployed as a Web application packaged in a WAR file, but not if it was deployed in exploded format.
JSPs now precompile when deployed in an exploded format.
Jsp used several MBeans with attributes that had the same names, thus when they were displayed, it looked as though there were duplicates, when in fact, there were none.
The display labeling of the MBean attributes was changed for the mbeans that had the same attribute names. They are now distinguishable.
When a Serializable ServletContext attribute was added and then overwritten with a non-Serializable value, the original value masked the new value.
When replacing a Serializable value with a non-Serializable one, WebLogic Server now removes the original value from the attributes hashtable.
A race condition arose during the computation of a secondary JVMID when more than one frame was used. It appeared that the computation of the secondary JVMID was resetting the member variable value by one thread, causing the race condition.
Following a code change, the computation of the secondary JVMID no longer leads to the race condition.
The HTML page served by the CertificateServlet displayed the wrong value for the radio button—it displayed 2048 for the radio button, but using the button resulted in a 1024 bit certificate.
The radio button now produces the correct 2048 bit certificate.
The WebLogic Server implementation of HttpURLConnection did not check whether keep-alive connection had been timed out on the server side when using POST method, resulting in the error: Connection aborted by peer: socket write error on flush.
Checks were added to ensure that the HttpClient is non-null before updating the timestamp.
Harmless IOExceptions were not being suppressed on Japanese locales.
WebLogic Server now sets the locale to C by default when enabling nativeIO. Customers who do not want to set the locale to C can use the system property
-Dweblogic.nativeIO.useDefaultLocale=true
On non-english locales, the harmless exceptions are now suppressed.
A change to support piping of passwords into weblogic.Admin. That change locked up the System.in stream, preventing automated scripts from working correctly.
The change that locked the System.in. stream has been corrected and scripts can now be automated.
When a deployment was done where the targets were across two different platforms (such as unix and windows), the deployment files were not found.
The deployment location was not being localized for the local machine type. If one deployed a webapp from an administration server running on windows and targeted it to a unix based machine, the location of the deployment was malformed for that platform.
The deployment path has now been localized for each machine type.
The WebLogic Server MBeanHome method getAllMBeans() threw an exception when running in a WebLogic Portal environment.
WebLogic Server MBeanHome Helper needed additional knowledge of WebLogic Portal mbean class locations and a correction to existing logic.
The ClassNotFound exception is no longer thrown in the WebLogic Portal environment.
when an exception was thrown while retrieving attributes via MBeanServer.getAttributes(), any exceptions thrown by the JMXServer were handled and a null value was returned.
WebLogic Server now rethrows the exception instead of returning a null value.
When the attributes of an array type changed(meaning certain elements of the array were added or deleted or both), AttributeAdd/Remove notifications were not being sent out. Thus certain deployments were not being carried out properly.
The WebLogic Server now sends AttributeAdd/Remove notifications, in addition
to the AttributeChange notification, when an array type attribute values change.
When the value of SqlStmtProfilingEnabled was set through MBeans or manually in config.xml file and then you tried to retrieve that value through MBeans it did not show the value. Instead, it returned a message, "It appears that no attributes have been specified for this MBean".
Exposing the SqlStmtProfilingEnabled attribute of JDBCConnectionPoolMBean eliminated the error.
The KernelDebugMBean options, DebugDGCEnrollment and ForceGCEachDGCPeriod, could not be enabled. There was no way to "set" the enable attribute in weblogic.management.configuration.KernelDebugMBean.
The setter signature did not take boolean for these attributes, so the values for these flags could not be changed from the default.
These attribute setters now accept boolean.
When printing the ExecuteQueueRuntimeMBean, the ExecuteThreads attribute was not being displayed correctly with the weblogic.Admin tool.
The entries in the ExecuteThreads attribute are now displayed as a readable string value.
When Domain and Server logfile names were date and time based (SimpleDateFormat), the following features were not fully functional:
- These type of logs were not being rotated.
- The total number of log files were not restricted even when the FileCount was set.There was no code in place to delete the older log files because the FileFilter could not list these files because of their file name patterns.
- Remove NameTrans fn="ntrans-j2ee" name="j2ee" from the default object in the obj.conf file.
- Remove Init fn="load-modules" shlib="C:/Sun/WebServer6.1/bin/https/bin/j2eeplugin.dll" shlib_flags="(global|now)" from the magnus.conf file.
- Configure a cluster with server instances on at least two machines.
- Deploy a sample EJB to cluster.
- Restart the Administration Server.
- Untarget the EJB from cluster
- Retarget the EJB to cluster.
- Doing a canceAllStatementsBeingUsed in the internalRollback method of the weblogic.jdbc.jts.Connection class before calling a rollback on the connection.
- Introducing a new method, canceAllStatementsBeingUsed in the weblogic.jdbc.common.internal.ConnectionEnv class that iterates through all the open statements and calls cancel on them for the connection being rolled back, ignoring the SQL exception.
- Start a user transaction on one server instance 1.
- Put a JMS message into a persistent queue. The JMS server and queues are on server instance 2.
- Update an EJB on server instance 2.
- Commit the transaction.
- During test within the remote method of an entity bean, create a stateful session bean (local/localhome interfaces).
- Call business methods on the stateful session bean, which in turn create different types of beans.
- Try to remove the stateful session bean.
-
rmic
code was fixed to remove the static classloader entry in the Utilities class at the end of ejbc
-
ExecuteThread
was fixed to clean the contextclassloader before re-using the thread.
-
ejb code was fixed for canceling the triggers when the cmp/bmp with exclusive concurrency was undeployed.
DB QueryString was generated incorrectly when using the Oracle thin driver for Connection Pool creation.
- Create a connectionPool using oracle thin driver.
- Run the test case ejb20/relations/FindersTest/testStringFunctionLOCATE().
- The above test case can be run from the ejb20/relations/finder.ts file.
- Make sure the EJBs "ComputerEJB", "EmployeeEJB" and "FinderEmployeeEJB" use this connection Pool, created using thin driver.
- When this is run, we get "Invalid Character" error.
- A web application deployed on the Administration Server of Domain 1.
- An EJB was deployed to one Managed Server in a cluster in Domain 2.
- The web application did a lookup on the EJB using the URL of the Managed Server to which the EJB was deployed.
- The web application created a remote object and put it on the HttpSession
- The web application failed to obtain the remote object from the session with the following exception:
- Start a user transaction on one server instance 1.
- Put a JMS message into a persistent queue. The JMS server and queues are on server instance 2.
- Update an EJB on server instance 2.
- Commit the transaction.
- Configure a cluster such that the cluster instances on at least two machines.
- Deploy a sample EJB and target to cluster.
- Now restart the Admin server.
- Now go to console and untarget the EJB from cluster, apply and then retarget the EJB to cluster and Apply the changes.
- call:node1 ---> test.jsp (HTTP Session is created)
- call:node2 ---> submit data from test.jsp (via GET) to /ctrl/* Servlet
- Virtual Directory is configured.
- Mime type is configured to * (proxy everything).
- DefaultFileName is added to iisproxy.ini
- The IIS access log would show the message:
Out-of-process+ISAPI+extension+request+failed. 500 1726 99122 2003 84078
- The Windows Event Log would record Event ID 37:
Event Type: Warning Event Source: W3SVC Event Category: None Event ID: 37 Date: 8/26/2003 Time: 6:45:03 PM User: N/A Computer: name Description: Out of process application '/LM/W3SVC/2/Root/caf' terminated unexpectedly. For additional information specific to this message please visit the Microsoft Online Support site located at: http://www.microsoft.com/contentredirect.asp.
- The wlproxy.log entry showed:
Fri Nov 21 19:06:31 2003 Write to the browser failed: calling URL::close at line 1270 of .\iisproxy.cpp Fri Nov 21 19:06:31 2003 *******Exception type [WRITE_ERROR_TO_CLIENT] raised at line 1271 of .\iisproxy.cpp
This problem was solved with a code fix.
(NSAPI) A memory leak was detected that could cause the plug-in to crash. The problem occurred because the plug-in accessed an exception object after the object had been deleted. The code was fixed to retrieve the exception code from the exception object and then delete the object, which prevents the memory leak from occurring.
(NSAPI) When a client stopped a response from being sent to it (for example, by closing the browser before the response had completed), the plug-in wrote a 500 [WRITE TO CLIENT ERROR] to the Web server log file. This could cause problems with health monitoring tools that interpret the 500 error as a problem in the Web server.
This problem was solved with a code fix.
(ISAPI) In a configuration that included nine IIS servers and nine clustered WebLogic Server instances, IIS crashed every a few hours, writing an Event 37 to the event log. The wlproxy log contained this message:
Thu Oct 09 13:01:46 2003 *******Exception type [WRITE_ERROR_TO_CLIENT] raised at line 1269 of .\iisproxy.cpp
Diagnosis revealed that the Reader::fill() method was not allocating enough memory while growing the initial buffer. 4 bytes to mark the end of buffer were getting lost and which resulted in the core dump. The problem was solved with a code fix.
(NSAPI) During load testing, when NSAPI running on HP11.00 proxying to a 6 node cluster on 2 Solaris boxes (3 WebLogic Server instances on each), memory consumption steadily increased, and after approximately 50 minutes, the ns-httpd process crashed.
The same load test did not crash on HP11.00 or Solaris.
Analysis revealed that codes in proxy.cpp used strdup(), a native system call. strdup() allocates system memory to the program's heap space. WebLogic Server uses Iplanet's FREE macro to free previous allotted space when it is no longer needed. Because FREE does not free the allocated space by strdup() call, the memory leak occurred.
The problem was solved by replacing all native strdup()system calls in proxy.cpp with Iplanet's STRDUP macro so the FREE macro knows what to free.
(NSAPI) Plugin does not handle %0A in the post request gracefully
A POST request %0A at the end sent to WebLogic Server through the NSAPI plug-in was not handled gracefully. The request added extraneous data into the body stream, and headers appeared at the end of the body. Requests sent directly to WebLogic Server were processed correctly it works fine. Customer needs a plugin which can handle %0A at the end gracefully.
The problem was corrected by code change to the plug-in to detect and handle HTTP/0.9 responses correctly.
(NSAPI) When WLExcludePathOrMimeType was set, the file types were cut in the request to WebLogic Server, but iplanet failed to serve those files instead.
For example, this request for a .jsp that contained a .jpg was made:
<Object name="test5" ppath="*/weblogic/*"> Service fn="wl_proxy" WebLogicHost="lorna" WebLogicPort="7001" PathTrim="/weblogic" Debug="ALL" DebugConfigInfo="ON" WLExcludePathOrMimeType="*.jpg" </Object>
The request for the .jsp was proxied to WebLogic Server, and the .jsp was displayed without the .jpg. Iplanet failed to server the jpg.The iplanet access log contained this message:
10.40.4.117 - - [28/Oct/2003:11:45:34 -0500] "GET /weblogic/images/logo_tm_onwt.jpg HTTP/1.1" 500 305 I get the following in wlproxy.log: Tue Oct 28 11:45:35 2003 ============================= new request =============================== Tue Oct 28 11:45:35 2003 INFO: SSL is not configured Tue Oct 28 11:45:35 2003 URI=[/hello.jsp] Tue Oct 28 11:45:35 2003 attempt #0 out of a max of 5 Tue Oct 28 11:45:35 2003 general list: trying connect to '10.40.4.117'/7001/7001 at line 1224 for '/hello.jsp' Tue Oct 28 11:45:35 2003 INFO: New NON-SSL URL Tue Oct 28 11:45:35 2003 Going to check the general server list Tue Oct 28 11:45:35 2003 WLS info : 10.40.4.117:7001 recycled? 0 Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept]=[*/*] Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept-language]=[en-us] Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept-encoding]=[gzip, deflate] Tue Oct 28 11:45:35 2003 Hdrs from Client:[user-agent]=[Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)]
WLExcludePathOrMimeType should cause WebLogic Server to not service the request, and to pass control to the web server, allowing it to continue processing the request.
The problem was solved with a code change.
In WebLogic Server 6.1 SP04, replicated session beans under heavy load resulted in increasing heap usage and OutOfmemoryErrors.
Analysis revealed that examples.ejb20.basic.statefulSession.TraderBean_5ysgq2_EOImpl objects were not being garbage-collected even when garbage collection was forced. For clustered stateful session beans, strong references were maintained to the EOImpl object primary in the weblogic.rmi.cluster.PrimarySecondaryRemoteObject. As a remove is never called on the bean, the reference to the EOImpl was never removed from the eoMap.
A code fix was implemented to unexport the EO when the passivated bean has been deleted, after session-timeout-seconds.
IIOP calls from a WebLogic Server 6.1 SP04 instance to an EJB running on a WebLogic Server 7.0 SP02 instance resulted in an exception when the IIOP connection idle timed out. The exception occurred on the WebLogic Server 7.0 side, when it tried to send back the response—the connection was closed. The exception is not sent to the 6.1 server, and the client thread hangs.
The WebLogic Server 7.0 SP02 exception was:
<Jul 29, 2003 5:21:55 PM PDT> <Error> <IIOP> <002013> <Complete failure to send exception class java.rmi.MarshalException: java.rmi.MarshalException: IOException while sending; nested exception is: java.io.IOException: Attempt to send message on closed socket. java.rmi.MarshalException: IOException while sending; nested exception is: java.io.IOException: Attempt to send message on closed socket java.io.IOException: Attempt to send message on closed socket at weblogic.iiop.MuxableSocketIIOP.send(MuxableSocketIIOP.java:362) at weblogic.iiop.EndPointImpl.send(EndPointImpl.java:1078) at weblogic.iiop.OutboundResponseImpl.sendThrowable(OutboundResponseImpl.java:194) at weblogic.rmi.internal.BasicServerRef.handleThrowable(BasicServerRef.java:473) at weblogic.rmi.internal.BasicServerRef.postInvoke(BasicServerRef.java:440) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:328) at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189) >
Analysis revealed that close connection messages were not being handled properly. The error was solved with a code change.
WebLogic Server sometimes threw a java.rmi.UnmarshalException when a client application using the thin-client .jar (wlclient.jar) accessed an EJB. On the server, partial exception was:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.IOException: Serializable readObject method failed internally.
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.IOException: Serializable readObject method failed internally at com.ejb_cvps36_EOImpl_WLSkel.invoke(Unknown Source)
[...]On the client, the partial exception was:
java.rmi.MarshalException: CORBA MARSHAL 0 No; nested exception is:
org.omg.CORBA.MARSHAL: vmcid: 0x0 minor code: 0 completed: No
at
com.sun.corba.se.internal.iiop.ShutdownUtilDelegate.mapSystemException(ShutdownUtilDelegate.java:97)
at javax.rmi.CORBA.Util.mapSystemException(Util.java:65)
[...]This problem did not occur when using weblogic.jar on the client. The code was modified to address this problem.
WebLogic Server used reflection on inbound contexts that it did not understand. This caused IIOP clients on AIX to fail, because the IBM ORB makes assumptions about the stream format based on the service contexts. The code was fixed to correctly handle service contexts so that IIOP clients can be used on AIX.
If you configured WebLogic Server to use a custom security realm, and the realm was unavailable, WebLogic Server would not boot. This Service Pack introduces a new startup command, -Dweblogic.security.RealmFailureOk=true, that allows the server to start if the realm is unavailable. The command forces the server to start using the file realm, rather than the configured custom realm.
This command is available only for WebLogic Server 6.x, and is not implemented in other server versions.
Warning: Administrators must be cautious when using this command. If you have a custom realm that is configured only for authorization (not authentication) and the user store is the file realm, booting the server with -Dweblogic.security.RealmFailureOk=true may result in having no security.
Use this option only to access the Administration Console and reconfigure the custom realm so that the server can boot normally. Do not allow applications to access the server you have booted with -Dweblogic.security.RealmFailureOk=true.
When the CR093292 patch was applied to WebLogic Server Service Pack 5, the server began logging messages such as:
java.io.IOException: Length is Zero
at weblogic.security.SSL.GenericCipher.input(GenericCipher.java:196)
at weblogic.security.SSL.SSLCiphertext.input(SSLCiphertext.java:68)
at weblogic.security.SSL.SSLSocket.getRecord(SSLSocket.java:1147)
[...]These messages were intended only for debugging purposes. The code was fixed so that the messages are no longer logged.
The password used to access the encrypted private key in the Node Manager key file, weblogic.nodemanager.keyPassword, was in plain text and accessible.
The problem was resolved by the creation of the Node Manager properties file, nodemanager.properties.
Authenticated users could become unable to access WebLogic Server 6.1 SP04 after another user had been locked out. This problem could occur with Novell eDirectory. After a user had entered an incorrect password enough times to become locked out, other, authenticated users would become unable to access the server, receiving a 500 error similar to:
<[WebAppServletContext(7814505,security,/security)] Servlet failed with Exception netscape.ldap.LDAPException: error result (53); NDS error: login lockout (-197); DSA is unwilling to perform [...]
The problem was fixed in WebLogic Server by catching the LDAPException thrown in this case, and destroying the connection to the LDAP server.
This Service Pack includes a new property, weblogic.security.SSL.trustManager, that you can use to specify the custom trust manager if you are using HttpsURLConnection to connect to another server. Using this property enables you to obtain the CA root in the SSL handshake for business logic purposes.
Warning: This feature is implemented only in WebLogic Server 6.1, and it will not be made available in WebLogic Server 7.x or later releases.
In WebLogic Server 6.1 SP04, HTTP requests occasionally failed when CachingRealm.refresh() was called. This servlet synchronizes the cache and the database. The cluster used the RDBMS Realm as the Basic Realm.
A simple health check HTTP request calling index.html of an Web application occasionally failed with this exception.
<Error> <HTTP> <hanptl02> <managedServer2> <ExecuteThread: '9' for queue: '__weblogic_admin_rmi_queue'> <> <> <101020> <[WebAppServletContext(1014083,healthcheck02,/healthcheck02)] T_[ubgÍ Exception Éæè_¸"sµÜµ½_B> java.lang.NullPointerException: Start server side stack trace: java.lang.NullPointerException at weblogic.security.acl.GroupImpl.addMember(GroupImpl.java:46) at weblogic.security.acl.OwnerImpl.<init>(OwnerImpl.java:32) at weblogic.security.acl.AclImpl.<init>(AclImpl.java:164) at weblogic.servlet.security.internal.SecurityModule.auditPerm(SecurityModule.java:358)
Analysis revealed that two threads were accessing the CachingRealm simultaneously; for example, the refresh servlet has cleared the cache, but the request to the index.jsp is attempting to find a user that has been cleared from the cache.
The problem was solved with a code fix.
When a Web Application attempted to make an HTTPS connection and the handshake with the remote server stalled, WebLogic Server never timed out the associated SSL socket. This resulted in execute threads becoming "stuck" indefinitely, eventually locking the server. The code was fixed to ensure that timeout values are enforced with HTTPS connections.
WebLogic Server did not encrypt the private key password when storing the password to a file. The code was fixed to automatically encrypt the password when writing the password back to a file. Upon the first booting, WebLogic Server checks to verify that the password is encrypted, and encrypts it in the file if necessary.
WebLogic Server uses the encryption service associated with the domain. This means that you can use the password file only with the domain in which it was created.
Note: Secure a plain text copy of the private key password before you allow WebLogic Server to write the password to a file. You will not be able to retrieve the plain text password from the file after booting the server at this Service Pack level.
In WebLogic Server 6.1 SP05, with CR093813_61sp5.jar, removing the Node Manager properties file caused problems.
The Node Manager properties file is always created in the <saved logs dir>/NodeManagerInternal directory. This customer periodically archives and deletes the contents of NodeManagerInternal. This removes the Node Manager properties file, so that the certificate password stored in the Node Manager properties file cannot be decrypted, and Node Manager will not work correctly.
The problem was solved by a code change to create the Node Manager properties file in the directory specified by user.dir, if the file is not found in NodeManagerInternal, or in the user.dir directory.
In WebLogic Server 6.1 SP05, weblogic.net.http.HttpsURLConnection did not honor https.nonProxyHosts environment variable. The problem was exhibited in this scenario:
client <--> Proxy <---> Server
The client can be running within WebLogic Server or be a stand-alone Java program Requests always went through the proxy even if the targeted host was specified in https.nonProxyHosts. If instead, the host is specified in http.nonProxyHosts, the problem does not occur: a direct connection to the host, not to the proxyHost is established, not to the proxyHost, if defined.
Analysis revealed that logic for connecting directly to a host specified in https.nonProxyHosts, even when a proxyHost is defined. This problem did not exist for http.nonProxyHosts, only with https.nonProxyHosts.
Appropriate logic was developed to connected directly to a host specified in https.nonProxyHosts, even when a proxyHost is defined.
In WebLogic Server 6.1 SP05, the number of open LDAP connections kept increasing when using an external LDAP server.
The problem was solved with a code fix.
In WebLogic Server 6.1 Service Pack 3, calling Socket.getSendBufferSize() when using WebLogic Server JSSE caused the following error:
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketGetOption(Native Method)
at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:190)
at java.net.Socket.getSendBufferSize(Socket.java:527)
[...]The code was fixed to properly override and delegate getSendBufferSize().
The LDAPDelegate.groupContainsInternal() method performed a recursive search of the list of groups without first checking if the list contained the desired group. This performance problem was fixed by updating groupContainsInternal() to first iterate through the group list to determine if it contains the desired group.
When WebLogic Server 6.1 SP03 was configured to log all HTTP requests in extended format, at the rotation time, the following error is thrown at approximately one minute intervals after the rotation is scheduled (which is the log flush time interval setting):
####<Aug 20, 2002 9:00:00 PM PDT> <Error> <HTTP myapp> <host2> <myserver> <ExecuteThread: '6' for queue: 'default'> <system> <> <000000> <Exception flushing HTTP log file> java.io.IOException: Failed to rename log file on attempt to rotate logs at weblogic.servlet.logging.LogManagerHttp.rotateLog(LogManagerHttp.java:168) at weblogic.servlet.logging.LogManagerHttp.access$2(LogManagerHttp.java:148) at weblogic.servlet.logging.LogManagerHttp$RotateLogTrigger.trigger(LogManagerHttp.java:432) at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:238) at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:229) at weblogic.time.server.ScheduledTrigger.execute(ScheduledTrigger.java:69) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) ####<Aug 20, 2002 9:00:05 PM PDT> <Error> <HTTP myapp> <host2> <myserver> <ExecuteThread: '7' for queue: 'default'> <system> <> <000000> <Exception flushing HTTP log file>...
Analysis revealed that the log had been flushed inappropriately. The problem was solved with a code change to ensure that the log is not flushed on rotation, and to check for a null value for the log file name.
WebLogic Server threw a NullPointerException when you enabled HTTP logging on a Managed Server that was booted with HTTP logging disabled and had no existing log file. On each HTTP access to the Managed Server, the following exception was thrown:
java.lang.NullPointerException
at
weblogic.servlet.logging.LogManagerHttp.log(LogManagerHttp.java:292)
at weblogic.servlet.internal.HttpServer.log(HttpServer.java:865)
at
weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1044)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2265)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)The problem was solved with a code fix.
In WebLogic Server 6.1 SP05 running under Unix, CGIServlet, which extracts the cgiscripts in a WAR so that it can execute them, was calling the scripts without setting the current working directory.
A fix was implemented to ensure that the current working directory is set so that cgi scripts can call subscripts, even in WAR webapps.
In WebLogic Server 6.1 SP01, SP02, SP03, and SP04, <charset-mapping> in weblogic.xml is ignored when compiling JSP file with precompile=true.
As a result, some of double bytes characters are garbled because of the mismatch between the character's encoding specified in <charset-mapping> and in the compiled classes.
Analysis revealed an error in the precompiler. The problem was solved with a code fix.
An update to the HttpClusterServlet implementation changed the default SSL port number in the WebLogicCluster parameter to 443. The updated implementation also failed to report an error when the WebLogicCluster parameter was not specified correctly.
A code fix was made to ensure that the HttpClusterServlet implementation matched the earlier behavior:
- WebLogicCluster again uses the format host:port:sslport for specifying the SSL port number.
- WebLogic Server logs an error if the SSL port is not specified, and uses the default SSL port of 7002.
Objects that implement the HttpSessionAttributeListener interface did not receive the correct value when calling HttpSessionBindingEvent.getValue() on events received via attributeReplaced(). Instead of returning the old attribute value, as stated in the Servlet 2.3 specification, getValue() returned the newer value. The problem was solved with a code fix.
Prior to this Service Pack, a call to weblogic.version did not show the correct version information if a patch had been applied to the WebLogic Server instance. The code was modified so that weblogic.version now shows the correct version and patch information in the format:
WebLogic Server version date build with patch [, patch] [...]
For example:
WebLogic Server 8.1 03/20/2003 246620 with CRXXXX, CRXXXX, CRXXXXX
In WebLogic Server SP04, there was a change in the behavior of the CGIServlet that could affect the execution of CGI scripts having no filename extension. For example, if a web.xml file defined the CGI directory and Servlet mapping in the following way:
<param-name>cgiDir</param-name>
<param-value>/home/user/cgi-bin</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>CGIServlet</servlet-name>
<url-pattern>/cgi-bin/*</url-pattern>
</servlet-mapping>and stored a script named myscript in the /home/user/cgi-bin directory, a URL such as http://localhost/mywebapp/cgi-bin/myscript would map to /home/user/cgi-bin without specifying the script name. (This problem did not occur with scripts having an extension, such as myscript.ksh).
The code was fixed to make the behavior match earlier releases of CGIServlet. Using the above example, the code fix ensures that the URL http://localhost/mywebapp/cgi-bin/myscript maps to /home/user/cgi-bin/myscript.
After parsing an HTTP request containing a null HTTP-Version field, WebLogic Server would throw the following exception:
java.lang.NullPointerException
at
weblogic.servlet.internal.ServletRequestImpl.initInputEncoding(ServletRequestImpl.java:727)
at
weblogic.servlet.internal.ServletRequestImpl.mergePostParams(ServletRequestImpl.java:565)
at
weblogic.servlet.internal.ServletRequestImpl.parseQueryParams(ServletRequestImpl.java:489)
at
weblogic.servlet.internal.ServletRequestImpl.getParameter(ServletRequestImpl.java:686)
at
weblogic.servlet.internal.ServletRequestImpl.initSessionInfo(ServletRequestImpl.java:1481)
at
weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.java:1345)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:1010)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:910)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:279)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:403)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:285)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)The code was fixed to use HTTP/0.9 as the default version when none is specified in the request.
When logging HTTP transactions using extended log format, WebLogic Server did not record query parameters (cs-uri-query) for requests made from one Servlet or JSP to another. Also, WebLogic Server recorded the URI (cs-uri-stem) of the forwarded request, rather than the original request URI from the client.
The code was fixed to ensure that the URI and query string of the original request are recorded in access.log when logging forwarded HTTP transactions.
A <url-pattern> value with a single character in a <servlet-mapping> element was not honored in a web.xml deployment descriptor. For example, <url-pattern>*.f</url-pattern> produced a 404 File Not Found error when attempting to access welcome.f, but <url-pattern>*.oop</url-pattern> worked properly when attempting to access welcome.oop.
This problem has been resolved so that single character <url-patterns> now work as expected.
The HttpClusterServlet was not correctly parsing the session id from post data.
If you sent a request through HttpClusterServlet to a cluster, establishing a session, and then sent a second request without a cookie but with the session id in the post parameters, the servlet did not recognize the session.
The servlet is now able to extract the session id from the post data.
HttpClusterServlet failed to increase its failure count if a WebLogic Server in the cluster was hung. This caused HttpClusterServlet to go into an infinite loop if each server in a cluster slept for a time longer than HungServerRecoverSeconds, or if 2 out of 3 servers in a cluster slept longer than HungServerRecoverSeconds. The code was fixed to ensure that the failure count is properly incremented.
If you set the buffer size to zero in a servlet, it would fail to respond and would initiate an infinite loop in the server. WebLogic Server would ultimately display a warning similar to:
"Suspend Checker Thread" prio=10 tid=0x23eb90 nid=0xfec runnable
<May 14, 2003 10:53:34 AM PDT> <Warning> <WebLogicServer> <000337>
<ExecuteThread: '10' for queue: 'default' has been busy for "1,181" seconds working on the request "Http Request: servlet_uri", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>This problem was solved with a code fix.
JSP code that intended to set double byte characters as a parameter's value—for example:
<jsp:include page="included.jsp">
<jsp:param name="title"
value="<%= java.net.URLEncoder.encode(\"[double byte characters]\")
%>"/>
</jsp:include>—resulted in specified double byte characters being changed to their URL-encoded code. This problem has been resolved.
The Administration Console incorrectly indicated that the log file format could be dynamically changed between Common Log Format (CLF) and Extended Log Format (ELF), when such a change actually requires a server reboot. The code was changed to properly indicate the required server reboot when changing this configuration parameter.
When processing requests through a proxy servlet, WebLogic Server only honored the SecureProxy setting for incoming requests that used HTTPS. If the incoming request used HTTP, WebLogic Server did not use an HTTPS connection even when SecureProxy was enabled in the proxy servlet. This problem was solved with a code fix.
If TrackingEnabled was set to false, WebLogic Server created a new session for each request, but the sessions were not getting invalidated.
The code was modified to invalidate a session immediately if TrackingEnabled is set to false. This is the correct behavior.
Under certain conditions, WebLogic Server threw a NullPointerException when using CGIServlet with the useByteStream parameter set to true. The problem occurred when using framesets where one frame contained static URL links and another frame used CGIServlet. If a user selected the frame containing static links before the other frame completed downloading a page, an IO exception was caught and presented to the user as:
java.lang.NullPointerException
at
weblogic.utils.Executable$Drainer.run(Executable.java:366)This problem was solved with a code fix.
WebLogic Server attempted to write to an output stream even after an IOException occurred. This led to 100% CPU utilization if an unexpected socket disconnection occurred with a Web Application that did not handle IOException.
org.apache.xml.serialize.XMLSerializer ignores IOException until the end of its process. This caused the problem to occur if an IOException was thrown in the middle of returning XML documents as part of an HTTP response.
The code was modified to ensure that writes to an output stream stop after an IOException occurs.
When multiple Web Applications were deployed in a Single Sign-On configuration and one application called weblogic.servlet.security.ServletAuthentication.invalidateAll(request), the HttpSessionListeners in the other applications were not invoked until their session timeouts occurred. This happened because only the session associated with the first Web Applications was registered for invalidation; after the user was authenticated, subsequent sessions were not registered.
The code was fixed to ensure that both the session ID and context path of all Web Applications are registered for invalidation as necessary by invalidateAll(request).
In WebLogic Server Service Pack 3, it was possible for the server to write standard log entries to a log file before the writing Extended Log Format headers. This situation could occur during a log rotation when multiple threads attempted to write to the new log file at the same time.
The code was fixed to ensure that the thread handling the log rotation has exclusive access to the new log file until after the log headers are written.
WebLogic Server Service Pack 5 could throw a NullPointerException when used with Apache and Netegrity's SiteMinder. An initial request forwarded through Apache to SiteMinder, and authenticated by SiteMinder, would also be successfully authenticated by WebLogic Server. However, if the user used the browser's Back button to return to the login page and authenticated again using a different username and password, WebLogic Server threw a NullPointerException:
java.lang.NullPointerException
at
weblogic.servlet.security.internal.SecurityModule.logoutSession(SecurityModule.java:386)
at
weblogic.servlet.security.internal.SecurityModule.checkAuthenticate(SecurityModule.java:292)
at
weblogic.servlet.security.ServletAuthentication.weak(ServletAuthentication.java:353)
at com.uprr.security.weblogic.SiteMinderAuthFilter.doPreAuth(Unknown
Source)
at weblogic.servlet.security.AuthFilter.service(AuthFilter.java:51)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198)
at
weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:530)
at
weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:350)
at
weblogic.servlet.security.internal.ServletSecurityManager.checkAccess
(ServletSecurityManager.java:144)
[...]This problem was solved with a code fix.
When WebLogic Server 6.1 SP04, a SNMP shutdown trap was not received.
8-Oct-02 15:57:24 FAILURE mytest!0[41]!oam/systest/snmp/oam_snmp!2[69]!if!3[86]!weblogic.qa.tests.oam.systest.snmp.trap.SNMPTrapTest.testServerShutdownTrap() wlsServerShutdownTrap wasn't received. PARAMETERS: managedServerName = oamserver1 adminServerName = adminServer
Analysis revealed that SNMP traps were not generated for Managed Server if the listen address or listen port are overridden with command line option.
The problem was resolved with a logic change to use the listen port value from ServerMBean, rather than the one in the URL.
When using two-way SSL to invoke a Web Service, and the client code uses the WSDL of the Web Service in its invocation, the client API now correctly sends the certificates both when making the WSDL lookup and when invoking the operation. Previously, certificates were sent only for the WSDL lookup and not for the actual invocation of the operation.
This problem was solved with a code fix.
The wsgen Ant task has been optimized to use a new classloader for every Web Service it assembles from a single build.xml file.
Previously, wsgen would use a single classloader for its entire execution, even if there were multiple Web Services listed in the build.xml file, and all auxiliary classes for each subsequent Web Service would be obtained from the single classloader and then copied, which was a sub-optimal way of generating all the needed class files. Depending on the number of Web Services in the build.xml file that had to be assembled, a full execution of wsgen could take over 30 minutes.
This problem was solved with a code fix.
WebLogic Web Services now correctly represent a null xsd:dateTime value in the SOAP response as xsi:nil='true'.
Previously, if a WebLogic Web Service returned an xsd:dateTime value that was null, it incorrectly represented it in the SOAP response as xsi:null='1', which is how the 1999 version of XML Schema defined null values. WebLogic Web Services support the 2001 version of XML Schema, which defines null values as xsi:nil='true'.
This problem was solved with a code fix.
When using the XML Registry for external entity resolution, WebLogic Server no longer returns an error when resolving DTDs using the Public ID.
This problem was solved with a code fix.
The generated WebLogic Web Services client stubs, when sending an XML document to a Web service as an org.w3c.dom.Element object, now correctly preserve any new-lines characters inside the body of an element in the XML file. Previously the client stubs would incorrectly convert these new-line characters to spaces.
This problem was solved with a code fix.
WebLogic Web Services now correctly send the utf-8 encoding header in SOAP Fault responses that are generated as a result of an exception in the invocation of the Web Service. The complete correct header is:
<?xml version="1.0" encoding="utf-8"?>
Previously, WebLogic Web Services did not include this header in SOAP Fault responses.
This problem was solved with a code fix.
In WebLogic Server 6.1 SP03 configured to use Tuxedo 8.0, when WebLogic Server shut down abnormally (CTRL-C) while there were uncommitted Tuxedo transactions, upon restart, the WebLogic Server instance hung. The problem was exhibited in this scenario:
- WebLogic was killed while there are still uncommitted transactions with Tuxedo
- WTC is configure to be started "ON_DEMAND"
- Start WebLogic
- WebLogic hangs with the reported problem
- WebLogic was killed while there are still uncommitted transactions with Tuxedo
- WTC is configure to be started "ON_DEMAND"
- Remove WebLogic tlog files "*.tlog"
- Start WebLogic
- WebLogic starts without any problem
- WebLogic was killed while there are still uncommitted transactions with Tuxedo
- WTC is configure to be started "ON_STARTUP"
- Start WebLogic
- WebLogic starts without any problem
- Start an Administration Server and a Managed Server.
- Shutdown the Administration Server.
- Invoke the 'stop' method on the ServerConfigMBean of the Managed Server.
- java.vendor.url='http://java.sun.com/'
- WebLogic Server 61SP03 on Linux (Redhat, JDK1.3.1) (1 admin, 1 managed)
- Win2K, calling weblogic.refresh (WebLogic Server61SP3, JDK1.3.1)
- an MDB was consuming from a JMS queue on another server
- JMS server died
- Inside weblogic.ejb20.internal.MDListener, UserTransaction.commit threw an exception
- MDListener goes on with its life
- Subsequent invocations of the MDB from JMS failed in UserTransaction.begin
- When using Driver.connect() to get the connection directly, SQLExcetpion.getErrorCode() returned 17002.
- When using a data source to get a connection from a connection pool, configured with Oracle Thin Driver, whose TestConnectionsOnReserve setting was true, SQLExcetpion.getErrorCode() returned 0.
- peerGone from the client.
- un-referenced call from the BasicServerRef during DGC.
- Remote client code properly closes the connection.
- When used as-is without any other change, refresh will only reserve and test one connection at a time, and will release it immediately. This addresses the locking-all-connections issue.
- If the customer adds a driver property to the pool definition, secondsToTrustAnIdlePoolConnection, with a positive integer value, such as 1, 2, 30 etc., then the pool will avoid testing pool connections that are known to have successfully connected to the DBMS within that period. This will speed up refresh and testConnsOnReserve.
- Connection.commit()/Connection.rollback()/Connection.close
() is called at the connection level (this Connection is weblogic.jdbc.
oci.Connection). - A SQL statement is executed and the connection is set to autoCommit mode (i.e., non-TX Data Source or a direct connection from the pool).
- The return code from an OCI SQL call indicates that a commit/rollback at database level has occurred.
- A connection is attempted which fails - OK
- A second connection is attempted 15 seconds later - OK
- The subsequent connection attempts are at an interval of 5 seconds - NOT OK
- RJVMFinder was made as PeerGoneListener to remember the unavailable server and not try the server until the replica list is empty.
- Fix to BasicReplicaHandler to avoid refreshReplicalist calls during failover, when it finds the replica list has more servers.
- T3JVMConnection has new functionality, to create the socket on a worker thread. In addition, the same timeout is used for the so_timeout, so on solaris8 clients, read will not block for one minute. The new flag is -Dweblogic.client.SocketConnectTimeoutInSecs=15 flag.
- Control heartbeat period on server and client using the existing -D values. Increase the default execute queue on server to take care of extra heartbeat load. Client heartbeat time is controlled by -Dweblogic.PeriodLength=10000 flag. Server heartbeat is controlled by PeriodLength="10000" flag in the ServerMBean in the config.xml.
When (re)binding and unbinding clusterable RMI objects from JNDI tree, the unbind operation was sometimes making the object null, setting it up for garbage collection, but still holding a reference to the null object when the object was hosted locally on the server.
A code fix was implemented to ensure that the object it is set for garbage collection only when no other replica of this object is available in the cluster.
When performing a Context.lookup on a composite name, a NameNotFoundException occurs if the name was not resolved, either fully or partially.
Name remainingName = nnfe.getRemainingName(); should obtain the components that were not resolved from the name. These are the subcontexts that need to be created in the JNDI tree.
So when enumeration e = remainingName.getAll() is called, the enumeration obtained should contain the unresolved components as string elements. e.g ("Unresolved1","Unresolved2","Unresolved3"). However, the Enumeration contains only one string, "Unresolved1.Unresolved2.Unresolved3"
The problem was solved by a change to BasicNamingNode.java to ensure that CompositeName is constructed with the '/' separator.
In WebLogic Server 6.1 SP03 and SP04 weblogic.jndi.Environment objects were not released on a timely basis, causing an OutOfMemoryError error during lookups for ejb-ref-name on the InitialContext.
A code fix was implemented to correctly close the context.
WebLogic Server 6.1 SP03,the JspParser threw an UnsupportedEncodingException for the extra quoted value in charset with JSP tag:
<%@ page contentType="text/html; charset=\"Shift_JIS\"" %>
resulted in this error:
java.lang.RuntimeException: Unknown/unsupported charset: "Shift_JIS" - java.io.UnsupportedEncodingException: Charset: '"Shift_JIS"' not recognized, and there is no alias for it in the WebServerMBean
WebLogic Server did not correctly support the HTTP specification.
The problem was resolved by adding support for quoted strings and comments to Content-Type header charset attribute value.
In WebLogic Server 6.1 SP03, a generated java file failed to compile on HP-UX 11with virtual host.The .ear file deployed correctly when not targeted to a virtual host. When accessed, login.jsp generated the java file and compiled it.
A virtual host was configured, and the webapp part of the .ear was targeted to the virtual host.
After restart of the server, when accessed, login.jsp generated the java file but failed to compile it into a class file.
The problem was solved with a code fix. The temporary directory now contains an element identifying the WebServer component so as to distinguish between virtual hosts and/or the default web-server. This prevents deployment file clashes when WebApps are deployed and the temporary directory is cleaned out.
A JSP file with multibyte name did not compile, and the directory returned its contents.
Analysis revealed that the JSP file path was not correctly detected when the file name contained multibyte characters. WebLogic Server decoded the path by VM default, then the path was decoded again using 'input-charset'.
Browser decoding implementation was a related issue. Internet Explorer performs URLencode based on UTF-8. Netscape does it based on platform default.
The problem was resolved by a code fix to decode ContextPath, ServletPath, and PathInfo based on UTF-8.
Decoding method can be configured with weblogic.http.URIDecodeEncoding.
The javax.servlet.jsp.PageContext.out attribute was notcleaned up correctly for body content tags.
The problem was solved with a code fix.
Java comments that start in one scriptlet and end in the next one cause an error:
<22.07.2002 14:12:24 CEST> <Error> <HTTP>
<[WebAppServletContext(7422744,DefaultWebApp,/DefaultWebApp)] Servlet failed with Exception weblogic.servlet.jsp.JspException: (line 12): scriptlet close brace '}' unbalanced at line 12 which breaks scope '_base_service_scope_' at ....
The problem was solved by back-porting grammar from WebLogic Server 7.0 that caused the ScriptletScopeLexer to skip an entire Java comment.
JSP compile by the server did not include the system classpath. On server startup, JSPs that referenced a jar in CLASSPATH did not compile.
This message occurred:
package com.bea.p13n.util.debug does not exist probably occurred due to an error in /devtools/debug.jsp line 1:<%@ page import="com.bea.p13n.util.debug.Debug" %>
Analysis revealed that the problem occurred when the jar in system classpath began with "../..".
The problem was solved with a codefix to support consider ./ and ../ cases when cleaning the classpath.
According to the JVM specification, the size limit for a method size is 64K. In WebLogic Server 6.1 SP03, a customer has JSPs with many body tags for which the generated java code exceeded the 64K limit for the __jspService method.
The problem was solved by a code change. Now, when an empty BodyTag of the form <my:tag ... /> is encountered, the generated code that would normally set up scope for the body is replaced by a single call to a static method in StandardTagLib.java that tricks the BodyTag into thinking it is being invoked as usual from the JSP source.
In WebLogic Server 6.1SP02 when a transaction is in unknown state the transaction is lost
Given the following cluster configuration:
- Queue1 - MDB1 TX Required
- Queue2 - MDB2 TX Required
- Queue3 - MDB3 TX required
- SLSB - send() - TX required
- sendImmediate() - TX RequiresNew
- MDB3 -> SLSB.send() and then SLSB.sendImmediate()
- the SLSB.send does: SLSB.send() ...>MDB2-> MDB1 -> SLSB.sendImmediate() called twice
- Send 100 messages to Queue3, allow processing to commence. Kill MS-1 after all messages have been enqueued but prior to all the messages being consumed from Queue3.
- Restart MS-1.
- Configured WebLogic Server to run as NT service.
- Started WebLogic Server from the Windows Control Panel.
- Restarted Windows-NT from the Windows Start menu.
- OFF—disables the enforcement entirely is not recommended as a solution unless you really have no other choice. For example, a customer has bought certificates from a commercial CA and the chain doesn't pass the new check. Note that most current commercial CA certificates should work under the default STRONG setting.
- STRONG—BasicConstraints for V3 CA certificates are checked and the certificates are verified to be CA certificates. This is the default.
- STRICT—This level does the same checking as the STRONG level, but in addition it also strictly enforces IETF RFC 2459 which specifies the BasicConstraints for CA certificates also must be marked as "critical". Set this if you want to strict conformance to RFC 2459.
- plug-in via T3s to application server. (No SSL Session caching and NO Keep-Alive)
- plug-in via HTTPS to application server. (No SSL Session caching and NO Keep-Alive)Customer is asking for SSL session resumption between plug-in and Weblogic Server.
- WebLogic Server 6.1 SP04 received a void return value as a result of a call to a WebLogic Server 7.0 SP02 server instance
- A method with no arguments was invoked on a 6.1 server instance by a WebLogic Server 7.0 SP02 server instance
- only responds to HTTP 1.0 requests
- does not send the ContentLength
- read and write byte by byte, and
- use HTTP/1.0 to send requests to KnowNow
- when the plug-in marks a server "bad", it notes the time
- the bad server is skipped in load balancing cycles until MaxSkipTime is reached
- then, a new server list is forced
- JSESSIONID with /webapp as the path
- JSESSIONID with / as the path
- did not reset control variable readAllChunks when recycling PostInputStream,
- isChunkComplete did not detect the end of chunk correctly
- The WTC service request failed over to the secondary domain listed in the services section for the bdmconfig file.
- The WTC service request did not check the primary domain listed in the services section of the bdmconfig file; the request went to the secondary domain.
- WebLogic Server 6.1.0 with SP02
- IIS plugin
- Windows 2000 SP2
- IIS 5.0
- Add the following line of Java code to the client application right before creating a URL:
- If you are running the examples server with the SSL certificate shipped with WebLogic Server, you need to specify the following on the command line when running your client application:
The queues are persisted to a DB, MDBs transactionally de-queueing messages. The following occurs:
When MS-2 is killed, the MS-1 receives a peergone exception and the transaction which is ready to commit its status goes from prepared to unknown. When the second server is brought back up the transaction is lost because it does not know what to do is commit or rollback because of the UNKNOWN state.
The problem was solved with a code fix to rollback a transaction when an unknown exception is received during commit.
In WebLogic Server 6.1 SP02, a deadlock between LogManager and JTA occurred on server startup. Thread dump analysis revealed:
Execute thread 7: This thread is trying to enlist a resource. It calls ResourceDescriptor.startResourceUse. Inside the synchronized block of this method is a trace statement.
Execute Thread 6: The Audit Bean is trying to make a call to LogBroadcaster. This makes an RMI call that causes the transaction to be suspended and delist the resources. Delist makes also a call on ResourceDescriptor.startResourceUse.
The trace statement inside the startResourceUse in thread 7 is blocking waiting on the LogBroadcast in thread 6 and the enlist of thread 7 is waiting for the delist in thread 6.
The problem was solved by moving the trace statement in startResourceUse outside the synchronized block.
The javax.transaction.xa.XAResource interface defines a method, setTransactionTimeout(), that allows the transaction manager to set the transaction timeout in the resource manager for operations associated with the XAResource instance. The WebLogic Server transaction manager did not invoke this method when a resource manager is accessed by an application in a global transaction.
This problem was solved by adding a XATransactionTimeout property to be used when XASetTransactionTimeout is "true". This is because, if the JTA Transaction Timeout value is used and that value is high, if WebLogic Server crashes in mid- transaction, Oracle locks the rows and no one can access them unless Oracle is cycled.
In WebLogic Server 6.1SP03 a transaction timeout occurred when calling a stateless EJB in a remote 6. 1SP03 Cluster.
The problem was solved by a code fix to transaction/internal/TransactionImpl.java.
In WebLogic Server 6.1 SP04, a null point exception was thrown by weblogic.transaction.internal.ServerResourceInfo.isAccessibleAtAndAssignableTo. The problem occurred intermittently even when the server is idle, and could not be reliably reproduced.
The problem was resolved with a code fix to weblogic/transaction/internal/ServerResourceInfo.java .
In WebLogic Server 6.1 SP02 and later, the Oracle 8.1.7.4 thin driver XA connection pool became unusable after the database stopped and started under WebLogic Server load.
The test application used XA connection pool to update columns in Oracle 8.1.7.4 via MDBs. When WebLogic Server is processing the MDB messages and the Oracle database is stopped/restarted the XA connections are not refreshed and distributed locks in Oracle are not recovered (ORA-01591). WebLogic Server goes into a cyclic "hang" situation and tries to refresh the XA connections. WebLogic Server log file shows following when "cycling" to refresh/use XA connections:
... ####<13.12.2002 12:09:54 CET> <Info> <JDBC Pool FoundationThinXAPool> <A4PMA9ALX> <myserver> <ExecuteThread: '9' for queue: 'default'> <guest> <484:6c709abb7f28edb9> <000000> <javax.transaction.SystemException: start() failed on resource 'weblogic.jdbc.jta.VendorXAResource' null at weblogic.transaction.internal.ServerResourceInfo.xaStart(ServerResourceInfo.java:1010) at ...
WebLogic Server never recovered from this situation (cycles). All threads of the server seemed blocked and server had to be killed (weblogic.Admin SHUTDOWN not working). Only restarting the WebLogic Server resolved the distributed locks in Oracle as soon as JTA recovery takes place. Before the recovery is done many ORA-01591 exceptions were thrown as the MDBs try to re-deliver their outstanding messages. After JTA recovered the in-doubt distributed transactions, processing of outstanding JMS messages completes successfully.
The problem was solved with code fixes to weblogic\jdbc\oci\xa\XADataSource.java.
When servers participating in a transaction were killed and restarted, recovery was slow, or deadlock occurred. The configuration included four JMSServers with pinned connection factories and distributed inbound and outbound queues, four MDB Servers (each with four MDBs deployed, five beans in pool listening to each distributed member in the inbound queue), 40,000 messages of size 2K in the inbound queue.
When JMS and MDB servers were restarted, the JMS servers used up all default queue threads and the Execute Queue continued to grow.
ServerTransactionImpl.java was modified to fix the problem.
If a transaction was rolled back, and there was a server participant that had no resource participants, it was possible that the transaction would never be completed. The transaction would continue to exist on the coordinating server and continually retry notifying the server with no resources to roll back. Eventually, the transaction would be abandoned. Although all resource participants were informed of the rollback, it was possible that after completion callbacks would not be processed on the coordinating server.
This problem was resolved by logic changes in rollback async reply processing to accommodate servers with no resources and to immediately set state to rolled back when all servers/resources are accounted for.
In WebLogic Server 6.1 SP04, beasvc.exe did not shut down gracefully when Windows-NT was restarted. The problem occurred when the user:
The server log was empty, and the event viewer contained this message:
The myserver service terminated unexpectedly. It has done this 1 time(s).
The following corrective action will be taken in 0 milliseconds: No action.
Analysis revealed that the Windows Service Control Manager (SCM) should be notified of SERVICE_ACCEPT_SHUTDOWN so that it will inform beasvc.exe of SERVICE_CONTROL_SHUTDOWN during system shutdown.
A code change to implement the required processing solved the problem.
In WebLogic Server 6.1 SP02, using a JMX client to delete a managed server resulted in a null pointer exception at weblogic.management.internal.MBeanHomeImpl.getInterface(MBeanHomeImpl.java:431)
The problem was solved with a correction to the mbean delete.
(HttpClusterServlet) During benchmark tests, 503 and 500 HTTP error were being returned by the proxy server running the HttpClusterServlet. The errors were random and occasional. The configuration was JRockit 7.0 SP2 Load 2 and the Sun JDK 1.3.1_06. AcceptBacklog and the thread count were increased to 1000 and 50 respectively. The benchmark was run with 100-200 client threads.
This problem occurred when the servlet's dynamic server list contained no entries.
The problem was solved with a code fix to check the size of the dynamic server list of servers before creating an array out of that list.
(NSAPI) All version of the iPlanet plugin had /_wl_proxy/_post hardcoded:
#else /* UNIX */
sprintf(name,"/tmp/_wl_proxy/_post__%d_%d", pid, postCounter);
fsep = '/';
#endif
This poses problems for customers that have multiple servers using different user IDs and groups.
For example, uploaded files from clients are saved temporarily in /tmp/_wl_proxy of web servers that proxy to WebLogic Server. The _wl_proxy directory is removed each time the web server is rebooted. If the environment is shared (multiple instances on the same physical servers) the user process that creates this directory blocks other users from writing to it, because it uses its default umask to create the permissions (i.e., application A [running as User ID A] creates /tmp/_wl_proxy/<some temp file> and then application B tries to upload a file and gets the following error in the error file:
[27/Aug/2002082140] failure (14367) for host 172.18.5.122 trying to POST /filetransfer/TransferUtility.do, wl-proxy reports exception occurred 'READ_ERROR [os error=13, line 501 of proxy.cpp] Cannot open TEMP file '/tmp/_wl_proxy/_post__14367_5' in $TMP/_wl_proxy for POST of 2867 bytes
This problem was solved by adding a configurable WLTempDir argument. This argument applies to both wlproxy.log and _wl_proxy. For backward compatibility, WLLogFile overrides WLTempDir during log file creation.
(NSAPI and ISAPI) Performance degradation occurred when connection pooling was turned off.
Resource requirements for URL creation were high.
WebLogic closed the connection before the plug-in did, resulting in "half-open" connections, and PROTOCOL_EXCEPTIONS in the plug-in.
The problems were addressed by multiple code changes:
(NSAPI) The web application container returned 404 messages for InitJVMID requests from the plugins, resulting in log files filling up with messages:
####<Sep 6, 2002 4:56:43 PM EDT> <Debug> <HTTP> <petunia> <ms1petunia> <ExecuteThread: '13' for queue: 'default'> <kernel identity> <> <101147> <HttpServer(887891,null default ctx,ms1petunia) found no context for "/WLDummyInitJVMIDs".
The problem was solved by sending InitJVMID requests to the internal web application which is always deployed on WebLogic Server.
(all plug-ins) __WebLogicBridgeConfig returned internal representation of Debug—a confusing 10 character code.
A code fix was made to return the value represented by the code.
(ISAPI) When KeepAlive was enabled, the time to close the connection is about 30 seconds with a HEAD HTTP request.
This problem was exhibited under 6.1 SP01, Windows 2000, IIS 5.0.
This problem was corrected with a code fix to close the connection immediately for HEAD request.
(ISAPI) For all plug-ins, it was not possible to differentiate between WRITE_ERRORS that occurred while writing to the request/post-data to WebLogic Server and WRITE_ERRORS that occurred while writing response headers/data to the browser in the __WebLogicBridgeConfig statistics. This deficiency made it more difficult to use the statistics displayed by __WebLogicBridgeConfig for plug-in/cluster health monitoring.
This deficiency was corrected by implementing two new error types WRITE_ERROR_TO_CLIENT and WRITE_ERROR_TO_SERVER.
(NSAPI) Plug-in did not read the SESSIONID from post data.
Analysis revealed a problem in getPreferredServersFromCookie(). When session.getId() was kept as post data. getId() included an extra string: |time.
The problem was solved by a code fix:,
(ISAPI) For all plug-ins and HttpClusterServlet, the MaxSkips feature was disabled, because its default value of 10 proved to make the feature less useful than desired. The lack of this feature posed potential performance degradation when one or more servers in the cluster are unresponsive.
This problem was resolved by providing a new parameter, MaxSkipTime.
MaxSkipTime can be used to specify the time in seconds to wait after marking a server bad until forcing a new server list.
(NSAPI) If performing a redirect using a URL that contains both a query string and an anchor, the anchor was incorrectly considered part of the value portion of the last query string member. This problem only occurred when using Internet Explorer in a three-tier environment, using iPlanet 6.0 for the HTTP server). Using Netscape or Mozilla, or if running the server in a two-tier environment, the problem did not occur.
To replicate, invoke foo.jsp.
foo.jsp:
String redirectURL = "http://hostname/T/foo2.jsp?a=b#foo";;
response.sendRedirect(redirectURL);
foo2.jsp:
<%= request.getParameter("a") %>
The Administration Console displayed the value for "a" as "b#foo"., instead of "b".
The problem was solved by a code fix to trim the anchor from the query string, because Internet Explorer does not do so for sendRedirected URL
(ISAPI, NSAPI) A changed was made to reduce vulnerability to SSL certificate chain attacks. Code to check BasicConstraints for CA certificates was added. Constraint checking is controlled with the plug-in parameter EnforceBasicConstraints. The parameter settings are now:
This change may result in security exceptions that did not occur in WebLogic Server 6.1 SP04. For example, an attempt to make an outbound SSL call, resulted in this error when the certificate presented by the remote server instance did not have a basic constraint:
<May 8, 2003 4:36:18 PM MDT> <Notice> <WebLogicServer> <SSLListenThread listening on port 7002> <May 8, 2003 4:36:19 PM MDT> <Notice> <Management> <Starting discovery of Managed Server... This feature is on by default, you may turn this off by passing -Dweblogic. <May 8, 2003 4:36:19 PM MDT> <Notice> <WebLogicServer> <Started WebLogic Admin Server "myserver" for domain "412253" running in Production Mode> EXCEPTION: Socket Closed java.io.IOException: Socket Closed at weblogic.security.SSL.SSLSocket.sendAlert(SSLSocket.java:1086) at...
Such errors may be prevented by setting the plug-in parameter EnforceBasicConstraints to false. You can set disable checking of basic constraints at the command line with this command:
-Dweblogic.security.SSL.enforceConstraints=false
A customer requested support for SSL session caching and keep-alives between the plug-in and and WebLogic Server, for T3s and HTTPS.
The request was satisfied by adding the KeepAliveEnabled flag , and adding SSL session cache.
(NSAPI) The SP03 version of the plug-in failed to parse the the JVMIDs for the following request:
2002 Found Encoded
Session=[JSESSIONID=9dq5Z081!805492834!174332983!7001!7002?_JASPER=1000/r/1037920979629&PAGE=HOME_TEMPLATE&INTEGRATION=YES]
Thu Nov 21 15:16:09 2002 Parsing cookie
JSESSIONID=9dq5Z081!805492834!174332983!7001!7002?_JASPER=1000/r/1037920979629&PAGE=HOME_TEMPLATE&INTEGRATION=YES
Thu Nov 21 15:16:09 2002 getpreferredServersFromCookie:
805492834!174332983!7001!7002?_JASPER=1000/r/1037920979629&PAGE=HOME_TEMPLATE&INTEGRATION=YES
Thu Nov 21 15:16:15 2002 parseJVMID: could not resolve hostname 'r', treating it as invalid
The problem was solved with a code fix to check JVMID portion of session cookie contains '/' instead of the whole sessionid.
(NSAPI) JSP sendRedirect() failed when web application is deployed on a cluster and the JSP is accessed through the iPlanet proxy plug-in.
An IE browser returns the message The page cannot be displayed... and Netscape returns The document contained no data...
The problem was solved with a code fix to check for null value of secondary session.
(ISAPI) The PathTrim value was case-sensitive, causing problems for environments that prefer to allow clients to access an application with a case-insensitive URL.
This problem was resolved by changing the PathTrim value to be case-insensitive.
(NSAPI) A call to encodeRedirectURL() failed when:
(a) A webapp is deployed as a .war file on a cluster;
(b) A JSP in the webapp is accessed through the iPlanet proxy plug-in; and
(c) The JSP invokes encodeRedirectURL() in a FORM using the HTTP GET method
A core dump occurs on the iPlanet Web Server. An Internet Explorer browser returns The page cannot be displayed...Cannot find server or DNS Error and Netscape returns The document contained no data... 1.
Analysis revealed that the problem was caused by storing primary or secondary jvmid in a fixed length buffer without trimming the query string.
The problem was solved by a code change to should trim the query string before parsing the session cookie
(Apache) Failover from primary server did not occur when response time exceeded the time limit set by HungServerRecoverSecs, and the Indempotent primitive is on.
Analysis revealed that the problem was related to an error in the exception handling source code in ap_proxy.cpp.
The problem was solved by rewriting the failover code.
(NSAPI) If the server listed in WebLogicHost and WebLogicPort or in WebLogicCluster was not up and running, or for example, Solaris started in single user mode, the plug-in hung until the operating system timed out the connection.
By default, this timeout is lengthy.
A new introduce plug-in parameter, WLSocketTimeoutSecs, was added. Use of this parameter prevents long delays when a machine is down. This default value is 2 seconds. The value must be greater than 0.
(ISAPI) Parsing post data for cookies not implemented correctly in plugins. This error resulted
"Bad request in the post data [NameField=aaaaa&ValueField=111111111111&AddValue=+Add+]"
The UrlUnescape() method was returning incorrect return type, and parsing post data for content-types other than application/x-www-form-urlencoded.
The bug was corrected with a code fix.
(ISAPI) The plug-in could not successfully resolve to the appropriate server instance. The error in the log files was: Primary JVMID not found in the server list, ignore preferred servers.
Analysis revealed an error in getPreferredServersFromCookie(). The problem was solved with a code fix.
(Apache) After failover of primary server, the plug-in continued to search for the primary server instance, instead of search for the secondary server instance and sending the it the request upon which the primary server failed.
The problem was solved by a rewrite of the failover code.
(ISAPI) The IIS plug-in parsed cookies incorrectly when the client sent multiple cookies, resulting in the plug-in not sticking to the primary server instance.
Analysis revealed an error in the string checking logic, strstr() did not correctly parse the session cookie name.
(Apache) The X_WEBLOGIC_FORCE_JVMID header was sent to to a server instance in a cluster.
X_WEBLOGIC_FORCE_JVMID should only be sent when the server list is non-clustered and the current server does not have a jvmid yet.
This problem was solved by a code fix.
(All plug-ins) A customer need to determine a browser's cipher strength on the WebLogic side, in a configuration that included a plug-in with 128 bit step up certs between WebLogic Server and the browser. The browser had 40 bit or 128 bit strength. The customer used this code to obtain the browsers cipher strength: (Integer)httpRequest.getAttribute("javax.servlet.request.key-size") to get the browser's strength.
The value returned was always 128, although the browser was set to use a cipher size less than 128 bit. The https_keysize determines the strength of the connection that is made. Because 128 bit certs were used on plug-in, 128 was returned, regardless of the strength used by the browser. When the request was directed to WLS, 40 or 128 was returned, depending on the browser strength.
The plug-in does not modify the HTTPS_KeySIZE or HTTPS_SECRETKEYSIZE headers.
To meet this need, to new headers were implemented: WL-Proxy-Client-Keysize and WL-Proxy-Client-Secretkeysize. Both headers values can be obtained with request.getHeader().
(NSAPI) The iPlanet server, running under Windows2000, crashed when a load testing application is trying to make multiple connections to the server. The iPlanet server crashes after multiple attempts are made to connect to the server.
Analysis revealed the iPlanet server crashed because of access violation and it points to MSVCRT!CxxThrowException.
The problem was solved by a code fix to sendResponse, to return and handle the exception, instead of throwing the exception.
The following new exception types were added:
READ_ERROR_FROM_CLIENT—error when reading data from client
READ_ERROR_FROM_SERVER—error when reading data from backend server
READ_ERROR_FROM_FILE—error when reading from temporary file which stores post data
WRITE_ERROR_TO_FILE—error when writing post data to the temporary file
(NSAPI and Apache) Failover to a secondary server instance when the primary server instance hung did not occur reliably. After establishing a primary and a secondary session, the client sent a recovery request that slept for longer then the value of HungServerRecoverySecs if the request.getParameter("primary") was equal to the server name. The web server did not detect that the primary server was hung and fail over the request to the secondary.
Analysis revealed that the secondary server was marked bad, which caused the plug-in to skip it, and use the general server list.
The problem was solved by a code change to reset the server to good after MaxSkipTime.
(ISAPI) When requests contained multiple cookies, if cookies not named JSESSIONID were after the JSESSIONID cookie, they were stripped off and not delivered to WebLogic Server.
The problem was solved be a code change.
(NSAPI) In WebLogic Server 6.1 SP04, ssl_certchain_verify_callback() incorrectly returned SSLNoErr for certain error conditions.
The problem was solved be a code change to return X509CertChainInvalidErr when the error conditions are encountered.
(Apache) When starting Apache using the plugin on Linux for ssl128, this error occurred:
Cannot load /usr/local/apache/libexec/mod_wl_ssl128.so into server: /usr/local/apache/libexec/mod_wl_ssl128.so: undefined symbol: pthread_mutexattr_init
Analysis revealed a build problem, which was solved by rebuilding the plug-in.
Under WebLogic Server 6.1 SP03, BoxedRMI IDL file seq2_seq1_octet.idl for multi dimensional arrays, generated with weblogic.ejbc contained module/path declaration org.omg.boxedRMI twice.
The problem was solved with a code fix to correct the IDL declaration for multidimensional boxedRMI sequences.
Under WebLogic Server 6.1 SP04, accessing an EJB over IIOP from an ActiveX component caused WebLogic Server to hangs. The thread dump indicated a dead lock in the java layer.
The problem occurred with SUN JDK 1.3.1, under Red Hat Linux 7.2 and Windows2000.
Analysis revealed that IIOP socket timeout trigger closing sockets could cause deadlocks.
A code fix was implemented to prevent this scenario.
In previous releases of WebLogic Server 6.1 dispatching methods with no arguments or invoking methods with a void return type would cause WebLogic Server to try and read data that potentially was not there.
The data is not there when delivered from 7.0sp2, for other releases we try and accommodate 6.1 by delivering the extra (unnecessary) data.
WebLogic Server 6.1 SP04 and earlier does not interoperate with WebLogic Server 8.1. Transactions between 6.1 and 8.1 server instances timeout with an ArrayIndexOutOfBoundsException on the 6.1 server instance.
This problem is solved in WebLogic Server 6.1 SP05.
This release solves an interoperability problem between WebLogic Server 6.1 SP04 and WebLogic Server 7.0 SP02.
WebLogic Server 6.1 SP04 erroneously tried to read void parameters that were returned to it, resulting in an UnmarshalException. This occurred when:
This problem prevented interoperability with other ORBs.
Under WebLogic Server 6.1 SP03 and SP04, out of memory messages occurred on repeated creation and close of InitialContext.
This problem was diagnosed as a memory leak on the DGCServerHelper class.
This problem was resolved with a code change to register LocalServerRef only if the dgcpolicy on descriptor is not "Managed".
Under WebLogic Server 6.1 SP03, a client JDBC connection that was not closed properly by the client, was not closed by WebLogic Server and garbage collected.
This problem was solved by a code fix to ensure that connections are be closed properly even when the remote client does not close the connection properly.
Notes: Client-side code should properly close connections. Although WebLogic Server will close unclosed connections, the process may be protracted, depending on the use and the distributed garbage collection behavior.
In WebLogic Server 6.1 SP04, with a WebLogic Server 8.1 server instance as client of a WebLogic Server 6.1 SP04 server instance, a transaction timed out with this exception:
java.rmi.RemoteException: Exception while committing Tx: Name=[EJB weblogic.qa.tests.interop.ejb11.txcrossdomain.TravelPlannerBean.planItinerary_Required(java.lang.String,java.util.Properties)],Xid=BEA1-000147799CCFA039D1D7(2653792),Status=Committing,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=120,seconds
This interoperability issues was solved with a code fix.
WebLogic Server did not ensure each certificate in a certificate chain was issued by a certificate authority. This problem meant anyone could get a personal certificate from a trusted certificate authority, use that certificate to issue other certificates, and WebLogic Server would not detect the invalid certificates. Now all X509 V3 CA certificates used with WebLogic Server must have the Basic Constraint extension defined as CA thus ensuring all certificates in a certificate chain were issued by a certificate authority. By default, any certificates for certificate authorities not meeting this criteria are rejected. If WebLogic Server is booted with a certificate chain that will not pass the certificate validation, an information message is logged noting that clients could reject it.
For more information, see SSL Certifi
Note: password.ini cannot be upgraded to the boot.properties file used in WebLogic Server version 7.0.
WebLogic Server 6.1 SP04 became unusable after IPlanet LDAP realm disabled a user. The problem appeared with this sequence of events:
Bring up an LDAP realm with the server. Deploy a webapp that uses form authentication. For any user in the LDAP realm, use the wrong password until you reach the user lockout threshold. Client receives a 500 error, and the server will show:
<Mar 9, 2003 7:17:22 PM PST> <Error> <HTTP> <[WebAppServletContext(3017390,security,/security)] Servlet failed with Exception netscape.ldap.LDAPException: error result (19); Exceed password retry limit. Please try later.; Constraint violation
After this error, the server becomes unusable with respect to authentication; for example, no other user can log into the web application, and the console is inaccessible.
The problem was solved with a code fix to check for LDAP exceptions when user enters an invalid password.
During testing, the session binding listener's (HttpSessionBindingListener) valueBound() and valueUnBound() methods were called multiple times for a single invocation.
A code fix was implemented to prevent duplicate method calls.
A new configuration parameter, UseHighestCompatibleHTTPVersion, was added to the WebServer element in config.xml.This parameter causes WebLogic Server to send responses in the highest version of the HTTP protocol that is compatible with the version used in the request. For instance, setting this parameter to be true causes WebLogic Server to respond to an HTTP/1.0 request with an HTTP/1.1 response. This affects only the version-string portion of the response. The default setting for the parameter is false in WebLogic Server 6.1
The parameter value can be changed by editing config.xml. The Administration Console does not provide an interface for setting the parameter value.
Using the NSAPI proxy plug-in with form-based authentication through iPlanet listening on port 80, j_security_check was not redirecting correctly, and authentication failed.
Analysis revealed that the form based authentication module did not call processRedirectedURL in the case of default port.
In WebLogic Server 6.1 SP03, the web server log (access.log), and the JDBC sub-system log (jdbc.log) were created relative to the product installation directory, instead to the RootDirectory.
This problem was corrected with a code fix.
In WebLogic Server 6.1 SP01, when using JDBC persistence for a session and storing a complex object that contained nested hashMaps and TreeMaps, a subsequent request came before the session was persisted, resulting in loss of session data.
The problem was solved with a code fix to move removeSession(id) to the end of method sync() in FileSessionContext.java.
The fix associated with "CR055987" introduced a timeout to solve the connection not being released problem. The fix introduced an InterruptedIOException that was not handled. When the exception was encountered, unwanted retries occurred.
The problem was resolved with a code fix to catch InterruptedIOException and re-throw the exception to prevent retries.
In WebLogic Server 6.1SP02, ServletContextListener was invoked before HttpSessionListener. According to the 2.3 servlet specifications, session listeners must be notified of session invalidations prior to context listeners being notified of application shutdown.
A code fix was made to ensure compliance with the specification.
In WebLogic Server 6.1SP03, a web application generated a java.lang.ClassNotFoundException without indicated the name if the missing file:
<[WebAppServletContext(4730538,olam,/olam)] Error loading servlet: ""> java.lang.ClassNotFoundException:
Analysis revealed that WebLogic Server did not correctly handle a null or empty string value for the auth-filter tag. The problem was resolved with a code fix.
Using HttpProxyServlet to proxy to a 3rd party event server from KnowNow caused Internet Explorer 6 to wait indefinitely with no response.
Analysis revealed that the KnowNow server :
If there is no content length, and the data is not chunk transferred, WebLogic Server reads until the end of stream. If the KnowNow server keeps sending data, HttpProxyServlet keeps reading data.
The problem was resolved with a new configuration parameter, UseKnowNow, that causes HttpProxyServlet to:
To use this parameter, add this syntax to the web.xml for the HttpClusterServlet webapp.
<init-param> <param-name>UseKnowNow</param-name> <param-value>true</param-value> </init-param>
In WebLogic Server 6.1SP02, getContextPath from HttpServletRequest returned incorrect value. For instance, for the request
http://localhost//webapp/foo
getContextPath returned
/webap
This error was corrected with a code fix.
The MaxSkips parameter for HttpClusterServlet and all plug-ins has been deprecated, and replaced with the MaxSkipTime parameter.
With this parameter,
Session was lost when trying to re-establish a WebLogic Server session after a request to a web application that did not explicitly set CookiePath in weblogic.xml.
Analysis revealed the browser (IE6) sent back two session cookies with different paths:
According to J2EE, multiple cookies in the header are ordered such that those with more specific Path attributes precede those with less specific. WebLogic Server searched the cookie vector backwards for the JSESSIONID, for performance reasons, and hence encountered the less specific path .
A code change was implemented to ensure that WebLogic Server uses the first cookie in the header.
In WebLogic Server 6.1 SP03, redirect-with-absolute-url = false did not work for j_security_check.
This is because j_security_check stores a absolute path and passes it to the sendRedirect() method.
j_security_check also should be aware of redirect-with-absolute-url.
A code change was implemented to make FormSecurityModule redirect requests in accordance with the setting of redirect-with-absolute-url.
In WebLogic Server 6.1 SP03 under Solaris 8, when receiving a HTTP/1.1 request that did not have a Host header field, the value of Date header field that WebLogic Server returned was "Date: Thu, 01 Jan 1970 00:00:00 GMT". This made it impossible to determine when the erroneous request was generated.
The problem was solved by a code change to set the request invoke time before sending the bad request error.
A performance fix introduced in WebLogic Server 6.1 Service Pack 3 (083654) caused multi-byte headers to become garbled. A work-around is available, but in SP03 and SP04, a patch was required to employ the work-around. (See 089868 for details.)
In SP05, the CR089868 patch is no longer necessary.
WebLogic Server 6.1 SP03 threw a null pointer exception while parsing request when the WL-Proxy-SSL header precedes the Host header. This occurred with client running over HTTPS, and SSL accelerator, IPlanet, and WebLogic Server running over HTTP. The problem was only replicated when configuration included the SSL accelerator.
java.lang.NullPointerException at weblogic.servlet.internal.ServletRequestImpl.setField(ServletRequestImpl.java:1903) at weblogic.servlet.internal.RequestParser.parse(RequestParser.java:254) at weblogic.servlet.internal.MuxableSocketHTTP.dispatch(MuxableSocketHTTP.java:390) at weblogic.socket.MuxableSocketDiscriminator.dispatch(MuxableSocketDiscriminator.java:275) at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:633) at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
The error occurred because the context is null, as the request was still being parsed, and context was not yet known. The WL-Proxy-SSL went before the HOST header.
Problem was resolved with a code fix.
For chunked data transfer WebLogic Server 6.1 SP03 prepended the chunk size to the data to bet transferred, hence adding extra characters to the data transferred.
The problem was resolved with a code change, to move setChunking out of mergePostParams of ServletRequestImpl to MuxableSocketHttp after request.setInputStream.
With this change, servlets and JSPs no long needs to decode chunk data. The WebLogic Server servlet engine will merge chunk data automatically.
When hosting a web application with user-defined error pages, WebLogic Server returned the following response for 400 error and closed the connection immediately, with no Connection: close header:
HTTP/1.1 400 Bad Request Date: Thu, 01 Jan 1970 00:00:00 GMT Content-Length: 463 Content-Type: text/html Last-Modified: Thu, 07 Nov 2002 21:56:52 GMT <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html>
The problem was solved with a code fix.
WebLogic Server threw a null pointer exception to HttpClusterServlet when checking for X_WEBLOGIC_CLUSTER_HASH. Stack trace:
<Tue Nov 05 15:58:00 PST 2002>: Start connection timeout scheduler <Tue Nov 05 15:58:00 PST 2002>: GenericProxyServelt: init() <Tue Nov 05 15:58:00 PST 2002>: HttpClusterServlet:init() <Tue Nov 05 15:58:00 PST 2002>: ===New Request===GET /base;JSESSIONID=9G8ZGUTNwnNTXm8B5V5z41e hG0T3oChTPvhnXe7EHCZ1IQI5lgF4!822557425 HTTP/1.1 <Tue Nov 05 15:58:00 PST 2002>: Found cookie: 822557425 <Tue Nov 05 15:58:00 PST 2002>: Trying to get JVMID id from server: coolant!7003!443 <Tue Nov 05 15:58:00 PST 2002>: Update dynmaic hash: WakHYk8LlxQ7XrnhkSXEohfZMAw <Tue Nov 05 15:58:00 PST 2002>: java.lang.NullPointerException at weblogic.servlet.proxy.HttpClusterServlet.initDynamicServerList(HttpClusterServlet .java:761) at weblogic.servlet.proxy.HttpClusterServlet.getPreferred(HttpClusterServlet.ja va:622 ) at weblogic.servlet.proxy.HttpClusterServlet.service(HttpClusterServlet.java:21
Analysis revealed that response headers are stored in the HashMap in random order. A code fix was implemented to set the server list before setting hash.WebLogic Server 6.1 SP03, servlet filters had to explicitly call flushBuffer() on the response wrappers after having called chain.doFilter() to send the response to the client. This caused customers to have to write separate versions of the filter for different application servers. Not doing so causes the response to contain no data. This happens because of bytes being buffered in the printWriter's OutputStreamWriter object.
A code change was implemented to ensure that user code does not need to explicitly call flushBuffer().
When "extended format" is selected for the HTTP logging option and the server is restarted, the following Null Pointer Exception was thrown:
<Oct 9, 2002 6:45:48 PM PDT> <Error> <kernel> <000802> <ExecuteRequest failed
java.lang.NullPointerException
java.lang.NullPointerException
The problem was solved with a code fix to open access.log file if filename is null
RequestDispatcher.forward dropped the version number at the end of the URL header. The request should have been forwarded as:
Request URI: /RequestDispatcher/SnoopServlet/myTest.txt;37
Instead, it was forwarded as:
Request URI: /RequestDispatcher/ProxySnoopServlet/myTest.txt
The problem was resolved to a code fix to set processPathParameters to false in setRequestURI() when doing forward().
When HttpClusterServlet was undeployed during a load test, an .IndexOutOfBoundsException resulted:
<Nov 27, 2002 4:05:11 PM PST> <Error> <HTTP> <101268>
<ServletContext(id=5220998,name=proxywebapp,context-path=): Failed while destroying servlet:
java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
IndexOutOfBoundsException while destroying HttpClusterServlet
Analysis revealed an error occurred when removing the last element in the connection pool with pool.remove(i).
The problem was resolved with a code fix.
WebLogic Server 6.1 SP04 ignored the quote character (") if cookie valued includes a quote character. For example, this syntax:
Cookie cookieWithQuotedValue = new Cookie("TestQuotedCookie", "\"TestValue\"");
assigned TestValue is added as cookie value, not "TestValue".
A code change was made to preserve quote characters in cookie values.
In WebLogic Server 6.1 SP04, comma character (,) in a Netscape cookie resulted in a Got bad cookie header error message.
A code fix resolved the problem.
In WebLogic Server 6.1 SP04, JISAutoDetect encoding for HttpRequest resulted in this UnsupportedEncodingException:
java.io.UnsupportedEncodingException: JISAutoDetect at sun.io.Converters.getConverterClass(Converters.java:102) at sun.io.Converters.newConverter(Converters.java:133) at sun.io.CharToByteConverter.getConverter(CharToByteConverter.java:62) at weblogic.servlet.internal.ServletRequestImpl.setCharacterEncoding(ServletRequestImpl.java:344) ...
This problem did not occur with WebLogic Server 6.1 SP03.
The problem occurred because ServletRequestImpl.java used the CharToByteConverter class instead of sun.io.ByteToCharConverter. CharToByteConverter is the one for input converter. CharToByte is for output converter. JISAutoDetect is only available for input stream.
The problem was corrected with a code fix.
In WebLogic Server 6.1 SP03, when using the HTTPClusterServlet to access a secure webapp on a backend cluster, Internet Explorer 5.5 hung for 30 seconds after the username and password were entered. The problem was not replicated in other browsers, and did not occur under Internet Explorer when accessing a back end server directly, rather than through the plug-in.
The problem occurred because Internet Explorer does not close the connection when it gets a Connection: Close header from the server. When accessing WebLogic Server directly, WebLogic Server closes the connection when it throws a 401 error. However through the HttpProxyServlet, the browser-to-ProxyServlet connection was kept alive even though the backend server had closed the connection.
The problem was solved by a code fix to GenericProxyServlet which causes the front end connection to disable KeepAlives when a Connection: Close header is returned from the back end server. This causes Internet Explorer to send the authentication details back straight away instead of hanging while waiting for WebLogic Server to timeout the connection.
A new installation of WebLogic Server 6.1 SP04 threw a null pointer exception when a successfully deployed web app that has a property set to java protocol is accessed. The browser returned Error 500--Internal Server Error. The problem did not occur with an upgrade installation.
<Dec 16, 2002 11:59:05 AM PST> <Error> <HTTP>
<[WebAppServletContext(2092664,sampleApp,/sampleApp)] Servlet failed with
Exception
java.lang.NullPointerException
at weblogic.servlet.JSPServlet.service(JSPServlet.java:132)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262)
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198)
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2637)
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2359)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
Analysis revealed an error in ZipSource.getURL(). The problem was resolved by adding logic to check for null value of source.getURL().
In WebLogic Server 6.1 SP03 the HttpRequest.getRemoteAddr() method returned the IP address of HttpClusterServlet instead of the client browser's IP address.
Analysis revealed that HttpClusterServlet does not set the proprietary header, "WL-Proxy-Client-IP", and instead returns the IP address of the socket upon which it is listening.
The problem was solved by a code fix to HttpClusterServlet to set the "WL-Proxy-Client-IP" header when WebLogic Plugin Enabled parameter is enabled.
The error message:
<Warning> <HTTP> <WebAppServletContext(5294080,blue,/blue) One of the getParameter family of methods called after reading from the ServletInputStream, not merging post parameters>
was erroneously generated.
A code fix was implemented to ensure that the message is not generated erroneously.
A new capability was added to allow a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. To enable this new feature, add AuthCookieEnabled="true" to the WebServer element in config.xml:
<WebServer Name="myserver" AuthCookieEnabled="true"/>
This will cause an new secure cookie to be sent to the browser when authenticating via an HTTPS connection. Once set, the session can access other security-constrained HTTPS resources only if the cookie is sent from the browser.
Note: If authenticating via plain HTTP, the secure cookie will not be set or required for any HTTPS resources. When accessing a non-protected HTTPS resource, the cookie will not be verified (since it will not have been sent from the browser). This allows the browser to access non-protected HTTPs resources without the user logging in.
In WebLogic Server SP02, when two interacting web applications use different session cookie names, the session ID was lost.
Analysis revealed that session attributes were not updated correctly when a web application specifies cookieName, a resource from another web application is included, and a RemoteUser exists in the request prior to the inclusion of the external resource.
The problem was solved by a code fix.
During testing, session data was lost intermittently, when the persistence type was JDBC. The following exception occurred:
weblogic.qa.tests.cluster.webapp.plugins.RequestSessionBeforeInvalidateTest.testRequestSessionBeforeInvalidationTest()
Session Was Invalidated
Sent: http://qa47-1:7771/pluginsjdbc/SessionBeforeInvalidate.jsp?count=1
Received: <html><body>PROBLEM: session is not the same as the first
request!FirstRequest sid:
2tjgF02nPIGgHGyojFubyOIjqt0ZAVK4no1Ny0afTxGKMrOj25z5!2356550501043194848402Sid
The problem was resolved with a code fix to the isRequestedSessionIdValid() method.
WebLogic Server 6.1 SP04 threw a NullPointerException when a null value was set in a servlet HTTP header:
<Jan 22, 2003 11:11:53 AM KST> <Error> <Kernel> <Execute Request failed java.lang.NullPointerException: Start server side stack trace: java.lang.NullPointerException at weblogic.servlet.internal.ResponseHeaders.writeHeaders(ResponseHeaders.java:360) at weblogic.servlet.internal. ServletResponseImpl.writeHeaders(ServletResponseImpl.java:902) at weblogic.servlet.internal.ServletOutputStreamImpl. sendHeaders(ServletOutputStreamImpl.java:239) at weblogic. servlet.internal.ServletOutputStreamImpl.flush(ServletOutputStreamImpl.java:121) at weblogic.servlet.internal. ServletOutputStreamImpl.commit(ServletOutputStreamImpl.java:484) at weblogic.servlet.internal.ServletOutputStream Impl.finish(ServletOutputStreamImpl.java:531) at weblogic. servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1091) at weblogic.servlet.internal.Servlet RequestImpl.execute(ServletRequestImpl.java:2364) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread. java:120) End server side stack trace at weblogic.servlet. internal.ResponseHeaders.writeHeaders(ResponseHeaders.java:360) at weblogic.servlet.internal.ServletResponseImpl. writeHeaders(ServletResponseImpl.java:902) at weblogic. servlet.internal.ServletOutputStreamImpl.sendHeaders(ServletOutputStreamImpl.java:239) at weblogic.servlet.internal. ServletOutputStreamImpl.flush(ServletOutputStreamImpl.java:121) at weblogic.servlet.internal.ServletOutputStream Impl.commit(ServletOutputStreamImpl.java:484) at weblogic.servlet.internal.ServletOutputStreamImpl.finish(ServletOutputStreamImpl.java:531) at weblogic.servlet.internal. ServletResponseImpl.send(ServletResponseImpl.java:1091) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2364) at weblogic.kernel.ExecuteThread. execute(ExecuteThread.java:139) at weblogic.kernel.Execute Thread.run(ExecuteThread.java:120)
The problem was resolved by added logic to check for null values in ResponseHeaders.java.
Response time for a web application deployed to WebLogic Server 6.1 SP02, when accessed from a browser set to HTTP Version 1.0 with flushRes=true. The problem did not occur with flushRes=false.
Analysis revealed that useKeepAlive was reinitialized inappropriately. The socket connection was not closed when it should have been, and the client waited for the socket to time out.
A code fix was implemented to initialize useKeepAlive when setting request and response.
In WebLogic Server SP02, SP03, and SP04, when getting certain POST requests from WAP devices, a web application encountered a java.util.ConcurrentModificationException
<29.jan.03 13:03:05 WET> <Error> <HTTP> <[WebAppServletContext(2810713,TnMFF,/TnMFF)] Servlet failed with Exception java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.next(HashMap.java:736) at weblogic.utils.enumerations.IteratorEnumerator.nextElement(IteratorEnumerator.java:25) at com.colibria.core.xmlswitch.XMLSwitch.getQueryStringXML(XMLSwitch.java:347) at ...
Analysis revealed that when a charset is associated with the request's content-type, the code read the data again using the encoding, and reset the query parameters, in the application. The application already has the enumeration object and iterates it (request.getParameterNames), and then tries to get the value of the parameter (request.getParameterValues(k)). At that point, the query parameters are wiped out and getParameterValues method tries to set it, resulting in the exception.
The problem was resolved by a code change to set query parameters after they are wiped, so that the data can be read again when a charset is associated with the request's content-type
The scheduled log rotation time for a WebLogic Server HTTP server log was calculated incorrectly when weblogic.httpd.logRotationBeginTime was a date in the past.
The error was corrected by changing the data type of operands used in the calculation from INT to LONG.
If the request received has no cookie but does have valid credentials WebLogic Server should allow access to the protected resource. Instead, this exception occurred:
java.lang.NullPointerException at weblogic.servlet.security.internal.SecurityModule.checkAuthCookie(SecurityModule.java:579) at weblogic.servlet.security.internal.BasicSecurityModule.checkUserPerm(BasicSecurityModule.java:157) at ...
The problem was solved with a code fix.
When a request with an incorrect URI was received from a from plug-in, WebLogic Server threw this stack trace
<Mar 8, 2003 3:27:20 PM PST> <Error> <Socket> <BEA-000421> <Uncaught Throwable i n processSockets java.lang.NullPointer Exception. java.lang.NullPointerException at weblogic. servlet.internal.ServletResponseImpl.writeHeaders(ServletResponseImpl.java:968) at weblogic.servlet.internal.Servlet OutputStreamImpl.sendHeaders(ServletOutputStreamImpl.java:244) at weblogic.servlet.internal.ServletOutputStreamImpl. flush(ServletOutputStreamImpl.java:121) at weblogic.servlet. internal.ServletOutputStreamImpl.commit(ServletOutputStreamImpl.java:486) at weblogic.servlet.internal.ChunkOutput. commit(ChunkOutput.java:269) at weblogic.servlet.internal. ChunkOutputWrapper.write(ChunkOutputWrapper.java:91) at weblogic.servlet.internal.ChunkWriter.write(ChunkWriter.java:37) at java.io.Writer.write(Writer.java:150) at java.io.PrintWriter.write(PrintWriter.java:230) at java.io.PrintWriter.write(PrintWriter.java:247) at java.io.PrintWriter.print(PrintWriter.java:378) at weblogic.servlet.internal.ServletResponseImpl.sendError(ServletResponseImpl.java:420) at weblogic.servlet.internal. ServletResponseImpl.sendError(ServletResponseImpl.java:373) at weblogic.servlet.internal.MuxableSocketHTTP.dispatch (MuxableSocketHTTP.java:512) at weblogic.socket.MuxableSocket Discriminator.dispatch(MuxableSocketDiscriminator.java:281) at weblogic.socket.NTSocketMuxer.processSockets(NTSocket Muxer.java:102) at weblogic.socket.SocketReaderRequest. execute(SocketReaderRequest.java:32) at weblogic.kernel. ExecuteThread.execute(ExecuteThread.java:178) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:151)
This problem was solved with a code fix.
When multiple chunked requests are posted to a servlet a number of the requests fail with a NumberFormationException. Mostly of the time alternate requests are fulfilled and the next request fails. It seems to be occurring as the requests are being made on the same connection. The exception stack trace is:
<ExecuteThread: '11' for queue: 'default'> <kernel identity> <> <101017> <[ServletContext(id=4864139,name=387551,context-path=)] Root cause of ServletException> java.lang.NumberFormatException: at java.lang.Integer.parseInt(Integer.java:430) at weblogic.utils.http.HttpChunkInputStream.readChunkSize(HttpChunkInputStream.java:118) at weblogic.utils.http.HttpChunkInputStream.initChunk(HttpChunkInputStream.java:72)
Analysis revealed two problems in PostInputStream:
The problem was solved by a code fix to read until end of stream in PostInputStream and correctly detect end of chunk in HttpChunkInputStream.
In WebLogic Server 6.1 SP04, a password error occurred when starting the Administration Server, the Petstore server and the Example server, before the user entered a password:
Starting WebLogic Server ....
<Oct 1, 2002 9:22:10 AM EDT> <Notice> <Management> <Loading configuration file .\config\petstore\config.xml ...>
<Oct 1, 2002 9:22:13 AM EDT> <Emergency> <Security> <Authentication failure - reenter password to boot weblogic server:>
A code fix solved this problem.
In WebLogic Server 6.1 SP04, the "WebLogic Server Code Examples Index" link in the samples server index page (index.jsp) did not work. When a the user clicked the link, the following message was displayed:
"Netscape is unable to find the file or directory named
/D:/bea61. Check filename and try again.
Analysis revealed that WebLogic Server had been installed with a BEAHOME that contained a blank space.
The problem was resolved by adding double quotes to the relevant href in index.jsp to allow for space characters in BEAHOME.
An error occurred when deploying Petstore applications during an upgrade from WebLogic Server 6.1 SP04 to WebLogic Server 8.1.
Analysis revealed that deployment descriptors lacked EJB references. The missing references were caught by the WebLogic Server 8.1, but not by WebLogic Server 6.1
This problem was resolved by corrections to the Petstore deployment descriptors.
In WebLogic Server 6.1 SP04 on Unix AIX, When a user tried to start petstore with StartPetStore.sh this error resulted:
java.lang.SecurityException: Unable to locate a login configuration.
The problem was solved with a correction to StartPetStore.sh.
dmloadcf failed for dom1config for WebLogic Server Samples simpFML32
Analysis revealed that *DM_LOCAL_SERVICES contained:
*DM_LOCAL_SERVICES
REVERSE_STRING RDOM="TDOM1"
instead of:
*DM_LOCAL_SERVICES
REVERSE_STRING LDOM="TDOM1"
An error in the Tuxedo dom1config configuration file was corrected to allow Tuxedo to export the local service, REVERSE_STRING, provided by local domain TDOM1.
The documentation for the SSL Client example were incorrect. The instructions directed the user to copy the WL_HOME\lib\cacerts to JAVA_HOME\jre\lib\security\jssecacerts.
This problem was solved by correcting the instructions, adding the jssecacerts file to the sslclient sample directory, and adding sample output to the instructions for the JSSE sample.
In WebLogic Server 6.1SP03, the client for the sample web service at samples\examples\webservices\rpc\weatherEJB was built by wsgen and deployed using only the client.jar (no weblogic.jar). When the non-SSL web service was invoked by the Java client, the following exception was thrown:
<< Missing class files in servicegen client.jar. Getting Exception in thread "main" java.lang.NoClassDefFoundError: weblogic/net/http/HttpsURLConnection at weblogic.soap.http.SoapContext.lookup(SoapContext.java:87) at javax.naming.InitialContext.lookup(InitialContext.java:350) at com.verizon.client.client.main(client.java:72) >>
Analysis revealed that the weblogic.net.http.HttpsURLConnection class is necessary for minimal out-of-the-box functionality and should be included in the client.jar.
The problem was solved by adding weblogic.net.http.HttpsURLConnection to client.txt
In WebLogic 6.1 SP03, when org.apache.soap.Fault was used (to represent the contents and semantics of a <SOAP-ENV:Fault> element), the Fault.getDetailEntries() method call should result in a Vector of exceptions, when the web service operation throws an exception.
Instead, in WebLogic 6.1 SP03, this call returns a null and the client does not get to see the exception stack trace. This problem does not exist in SP02.
The client runs with the same CLASSPATH while hitting either the WebLogic 6.1 SP02 or WebLogic 6.1 SP03 server instances. The problem was reproduced with the client CLASSPATH:
CLASSPATH=.;.\soap.jar;.\xerces.jar;.\j2ee.jar
The difference in behavior is that in SP03, the content of the fault detail is wrapped in <![CDATA[ ]]>. This is done to prevent the parser from failing if the stack trace contains something like
<<no stacktrace available>>
The problem was resolved by the addition of a new servlet initialization parameter, cdata-fault-detail, which if set to false, causes fault detail to not be wrapped in <![CDATA[ ]]>
<servlet> ... <servlet-class>weblogic.soap.server.servlet.StatelessBeanAdapter</servlet-class> <init-param> <param-name>cdata-fault-detail</param-name> <param-value>true</param-value> </init-param> ...
If cdata-fault-detail to false, if the stack trace contains something like
<<no stacktrace available>>
a parser error will result.
WebLogic 6.1 SP04, did not return dateTime entries correctly when a web service generated by WebLogic Server was called. The "+" char was omitted from the time zone offset part of the dateTime entry, when the time zone offset is positive (i.e., GMT+1 = CET [time zone for Denmark]). Example:
February 3rd, 2003 09:12:04 CET should be dateTime:
<date xsi:type="xsd:dateTime">2003-02-03T09:12:04.000+01:00
</date>Weblogic sent it as:
<date xsi:type="xsd:dateTime">2003-02-03T09:12:04.00001:00
</date>The problem was resolved with a code fix.
In WebLogic 6.1 SP03, when Ant was used to generate a .war file with Web Services using this WebLogic task:
<taskdef name="wsgen" classname="weblogic.ant.taskdefs.ejb.WSGen"/>
and the Transactions.jar file had more than 155 EJBs, the wsgen failed.
The problem was resolved by a code fix to CompilerInvoker.
In WebLogic 6.1 SP04, in the weblogic.soap.WebServiceProxy class, the invoke() method did not check if certs had been set in the class.
This caused two-way authentication to fail, or alternatively if the certs are passed to the InitialContext the http protocol did not work.
The problem was solved with a code fix.
In WebLogic 6.1 SP02 WTC connection policies did not work properly in failover and failback situations when the connection policy was set to ON_DEMAND and ON_STARTUP. When the connection policy was set to ON_STARTUP, failover doesn't work. Attempts to reproduce the problem revealed related errors:
When the primary node became unavailable as configured in bdmconfig.xml, the service request failed over to the secondary server in the imported services section: <T_DM_IMPORT
ResourceName="TOUPPER"
LocalAccessPoint="WLSDOM"
RemoteAccessPointList="SIMPDOM,TESTDOM">
<TranTime>600</TranTime> <
/T_DM_IMPORT>
When SIMPDOM became unavailable, the service request was fulfilled by TESTDOM—this should not happen when the connection policy is ON_DEMAND.
Analysis indicated that the connection policy wasn't being checked. The problem was resolved with a code fix to weblogic/wtc/gwt/TuxedoConnection.java.
In the simpconv example, the Tuxedo client failed to contact WebLogic Server. The client hit the local Tuxedo server instead of WebLogic Server.
Code changes were made to the Tuxedo client so that it does not look for padding. In addition, a remote services section was added to dubb, and an export section was added to bmdconfig.xml file.
Using WTC to access Tuxedo 8 Corba objects resulted ia n JavaIDL Reader thread leak. Running a simple example application resulted in a build-up of JavaIDL Reader threads in the JVM running WebLogic Server. The threads were not destroyed until the server was shut down.
Analysis revealed the finalize() was not called at the correct time. A code fix to add a call to ORB.destroy() was implemented to resolve the problem.
In WebLogic Server 6.1 SP02, the Xalan engine in WebLogic Server produced an invalid XML file, containing an unmatched <META> tag.
A code fix to apache/xalan code solved the problem.
When creating large FML tables (on the order of 4K entries), mkfldclass[32] generated a method to instantiate each entry into a hash table. For large FML tables, this single method exceeds the size limitation in the JVM.
This problem was resolved by implementing a dynamic load field table mechanism.
In WebLogic Server 6.1 SP02 and SP03, a WebLogic Server cluster hung in session replication. The configuration included the F5 load balancer, Internet Information Server, and WebLogic Server ISAPI plug-in.
Thread dumps referred to a never-before-reported path in the RJVM subsystem.
ExecuteThread: '33' for queue: 'default'" daemon prio=5 tid=0x49edf0 nid=0x2b waiting for monitor entry [0xd527f000..0xd527fc68]^M at weblogic.rjvm.RJVMManager. findOrCreateRemoteInternal(RJVMManager.java:213)^M at weblogic.rjvm.RJVMManager.findOrCreate(RJVMManager.java:188)^M at weblogic.rjvm.RJVMFinder.findOrCreateRemoteServer (RJVMFinder.java:178)^M at weblogic.rjvm.RJVMFinder. findOrCreate(RJVMFinder.java:149)^M at weblogic.rjvm. ServerURL.findOrCreateRJVM(ServerURL.java:207)^M at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:311)^M at weblogic.jndi.Environment.getContext(Environment.java:156)^M at weblogic.jndi.Environment.getInitialContext( Environment.java:139)^M at weblogic.servlet.internal. HttpServer.lookupROIDS(HttpServer.java:751)^M at...
Analysis revealed that the ISAPI plugin directed requests to a server other than that primary or secondary. THen calls were made on the remote ROIDImpl.
This problem was resolved with a code fix in WebLogic Server 6.1 SP04.
When using high-availability multi-pools, Weblogic now correctly fails over upon hardware failure when the pools have been created with an initial capacity equal to zero. The ResourceException that was being thrown was not the type that the multipool interpreted as reason to fail over--that was the problem.
Fixed a problem receiving authentication errors when using form-based authentication and multiple locales. Credentials in languages other than English could be successfully added to the fileRealm.prorperties file but could not be used to authenticate via the servlet form-based authentication. The credentials can now be used to authenticate via the servlet form-based authentication.
When a stateless session bean is deployed with the <max-beans-in-free-pool> parameter in the weblogic-ejb-jar.xml file, this value is not respected when concurrent calls are made to stateless session bean. WebLogic Server was creating further new instances of stateless session beans than the value specified in the parameter. This has been fixed.
EJB Deployer hard wired the replicateBindings to 'true' on context object before binding home to the JNDI tree so that even if the user set the home-is-clusterable to 'False' in the weblogic-ejb-jar.xml file, announcements to the rest of the nodes in the cluster are still being attempted a NameAlreadyBoundException is being thrown. This has been fixed.
The example samples/examples/wtc/corba/simpappcns did not have a run.sh UNIX script and did not work on UNIX machines.
This problem was solved by providing ubbdomain, dom1config, and run.sh files, and instruction in the javadoc on how to build the tuxedo side. This solution provides multi-platform/machine support. The old build script assumed a single machine environment.
Messages were being lost when sent through MessagingBridge and interrupted by a server re-start. If while messages were being processed by the MessagingBridge (messages being processed from MQ Queue to WebLogic JMS Queue), and the WebLogic server was stopped and then re-started, then in some cases, some messages were lost. The number of messages lost corresponded to the BatchSize of the MessagingBridge. This problem has been fixed.
This Service Pack improves WebLogic's handling of RJVMs in multiple ways. Fixes include:
WebLogic Server now ensures that a valid connection has been fully established between servers running on local and remote Java virtual machines before it attempts to send a message to an RJVM.
Possible deadlocks resulting from establishing a valid connection between servers running on local and remote Java virtual machines have now been fixed.
Previously, it was possible for RJVMs to get into an infinite-wait state while waiting for the connection to be established because the notification of a successful connection was issued before the RJVMs went into a wait state. The fix makes it possible for a success notification to be detected, even if it happens before a wait.
Multiple threads trying to establish a connection to an RJVM at the same time now rely on the success or failure of the first thread that actually manages to establish the connection.
Previously, each thread would always attempt to establish a connection in turn, rather than using the connection established by the first thread that succeeded.
Peer WebLogic Servers running on different computers now correctly detect when a peer server with which it has previously established a connection has gone, and correctly cleans up the broken connection.
The Remote Method Invocation (RMI) layer now receives proper exceptions to failover when an attempt to get an OutputStream fails.
Previously, when two peer servers where trying to establish a connection but failed to, an exception was not thrown to the RMI layer, causing improper failovers or delays to a proper failover.
Possible deadlocks have been fixed between 2-way calls from T3JVMConnection to ConnectionManager to RJVM.
We fixed multiple muxer problems and added improvements including:
Collections in all muxers (Java and native-code) that map to sockets now have unique keys. This has solved a variety of problems, including data corruption, bad pointer references, WebLogic Server hangings and crashes.
Data structures and state machines in muxers now have proper synchronization. This fixed certain classic deadlocks caused by conflicting order of locking.
The call stacks between the muxer and the protocol layers above the muxer are now 2-way, which means a close of a socket or connection can be initiated from any point in the stack. Safeguards have been added to prevent deadlocks.
State machine transitions in the muxer have been fixed, resulting in sockets no longer remaining in a CLOSE_WAIT state.
If the application server is killed abruptly, there is a high probability of creating a distributed in-doubt transaction. In WebLogic Server 6.1 SP01, the distributed in-doubt transaction still continued to exist and needed to be resolved by manual DBA intervention. In WebLogic Server 6.1 service pack 4, the transaction log file is re-scanned and a recovery process is initiated after re-starting the application server.
If a web application that creates a file that got deleted when the server was shutdown, when running as a Windows Service, this file got deleted as expected when the server was shutdown from the command line (using the java weblogic.Admin SHUTDOWN command) or from the administration console. However, this file did not get deleted when the server was shut down by going to:
Start Menu --> Settings --> Control Panel --> Services --> Press Stop button for the service.
This capability is now implemented.
When a stand-alone java client was calling a stateless session EJB, after about 500000 iterations, the following exception was being thrown on the client side:
Exception in thread "main" java.lang.ClassCastException: Assigning instance of class java.io.ObjectStreamClass to field weblogic.rmi.internal.ClientMethodDescriptor#signature at java.io.ObjectInputStream.inputClassFields(ObjectInputStream.java:2271)This has been fixed.
In WebLogic Server 6.1 service pack 2, when the admin server was shutdown using java weblogic.Admin SHUTDOWN, the SNMP agent was not generating the serverShutDown trap. It was able to generate serverStart trap when the server started up. Now, when the admin server is shutdown, the SNMP Agent will issue a self shutdown trap.
In the WebLogic Server distribution of Xalan, when the XSLT output method was set to HTML (required):
<xsl:output method="html"/>
the spaces in HREF attributes in anchor tags are encoded to "%20". For example:
<a href="javascript: var win = openWindow()">Link</a>
erroneously outputs as:
<ahref="javascript:%20var%20win%20=%20openWindow()">Link</a>
Netscape fails to interpret the "%20" as a space, breaking the link. If the output type is changed to "XML" (not an applicable workaround in this case), the attribute outputs correctly.
The vanilla Xalan distribution (i.e. not the BEA-enhanced version) performs the transformation correctly with identical input.
WebLogic Server distribution of Xalan performed inappropriate URL encoding on the HREF attribute. This works fine for normal URLs (i.e., http://somehost/...) where spaces are not allowed, however javascript URLs (i.e. javascript: doSomething()) are also valid and should not be encoded. The XSLT transformer should not be doing anything to the URL as there are already ways to explicitly encode URL's in stylesheets.
Problem occurred in WebLogic Server 6.1 SP2, SP3, and SP4.
Problem was solved by modifying the XSLT transformer to not encode the URL. .
In WebLogic Server 6.1 service pack 1 and 2, if the server received a call from the old generation stubs, the server correctly sent peerGone to the client and logged an error. In WebLogic Server 6.1 service pack 3, the server printed a NullPointeException and the client waited until timeout. Now we have restored the earlier, correct, behavior.
Under heavy loads SocketException: Connection timed out errors occurred. Stack trace:
####<Sep 18, 2002 9:37:07 AM EDT> <Error> <Posix Performance Pack> <lpsapp01> <LPSAPP01_C> <ExecuteThread: '34' for queue: 'default'> <> <> <000000> <IOException on socket: 'weblogic.rjvm.t3.T3JVMConnection@67cf01', fd: '1046'> java.net.SocketException: Connection timed out: Connection timed out Start server side stack trace: java.net.SocketException: Connection timed out: Connection timed out at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:86) at weblogic.socket.PosixSocketMuxer.readBytesProblem(PosixSocketMuxer.java:824) at weblogic.socket.PosixSocketMuxer.
deliverGoodNews(PosixSocketMuxer.java:712) at weblogic.
socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:637) at weblogic.socket.SocketReaderRequest.execute(Socket
ReaderRequest.java:24) at weblogic.kernel.ExecuteThread.
execute(ExecuteThread.java:139) at weblogic.kernel.
ExecuteThread.run(ExecuteThread.java:120) End server side stack traceand the server instance hung with sockets in the CLOSE_WAIT state. Thread dump:
"ExecuteThread: '3' for queue: 'default'" daemon prio=5 tid=0x7f79a8 nid=0x10 waiting for monitor entry [0xa6101000..0xa6101a40] at weblogic.socket.PosixSocketMuxer.
read(PosixSocketMuxer.java:542) at weblogic.socket.
JVMSocketManager.accept(JVMSocketManager.java:185) at weblogic.t3.srvr.ListenThread$RJVMListenRequest.execute(ListenThread.java:594) at weblogic.kernel.ExecuteThread.
execute(ExecuteThread.java:139) at weblogic.kernel.
ExecuteThread.run(ExecuteThread.java:120)Thread dump analysis indicated that the thread in native AddFdToPollSet did not finish writing to PollSet Loopback FD, and release POLLSET_LOCK properly.
Problem was resolved by tracking the number of bytes written to pipe, and waiting to write more to pipe (using an array instead) until thread reader notification that it is OK to write to the pipe.
In a cluster, after Internet Explorer 10053 displayed a socket error message, the proxy plug-in inappropriately failed over—the primary server was healthy. The problem was exhibited in this configuration:
Error 10053 is a winsock error and is defined in winsock.h as WSAECONNABORTED. The error occurs when a page is reloaded before the ISAPI extension is done sending data back. When the page is reloaded, the browser closes the existing connection and then creates a new connection to resubmit the request. Same condition can be caused by using the "Stop" button in the browser before the extension is done sending data.
This is a normal event that means that the browser isn't listening any more. After the error, plug-in should simply clean up and return from HttpExtensionProc.
The inappropriate failover case has been solved by changes to the IIS plugin. Failover not longer occurs when processing fails during the sendRequst phase if timeout occurs reading POST data.
When specifying a multiple-level path at PathTrim under the ISAPI environment using WlForwardPath together such as:
WlForwardPath=/
PathTrim=/path/to/weblogicISAPI plug-in was not able to trim the specified path. This has been fixed.
In WebLogic Server 6.1 service pack 4, if Idempotent is off, failover is prevented and if ConnectTimeoutSecs=0, core dump is prevented. Retries are no longer attempted after ConnecyTimeoutSecs is set to 0 in the iPlanet config. The retries were attempted either with the default setting, which is 10, or with 0. Furthermore, when Idempotent was set to ON, the retries occurred five times, instead of two when it was set to OFF.
When using JSPs in a webapp, the .java files that get created from the JSPs live under _tmp_war (under the webapp root). If it does not exist already, the _tmp_war directory is created at the time of WebApp deployment (during the initialization period after you start the server). If the server is run as root, the _tmp_war directory gets created by, and is owned by, root. At the end of initialization, nonPrivUser was being used to switch to a nonpriviledged user and the _tmp_war directory was inaccessible by the JSP servlet and WebLogic. This has been fixed.
weblogic.log and access.log (HTTP Logs) will now be renamed based on the configuration of the log filename. Usage of % symbols in the logfile name will invoke the logic which renames log files based on the date/time when it gets rotated. The file being currently logged into will be the log filename stripped off its % symbols if they exist. Examples of valid formats:
weblogic_%yyyyMMdd%_%HH%_%mm%.log foobar_%yyyy%-%MM%-%dd%_%HH%_%mm%.log
Note: Y (capital) does not represents anything in the SimpleDateFormat. Use lower case y (small) to represent the year. Invalid formats will fall back to WebLogic Server default log file names. A string enclosed between percentage signs (%) will be decoded based on SimpleDateFormat. This format applies to the filename, not the directories.
The CookieParser.cookieToString creates the expires cookie with a SimpleDateFormat that contains a comma, ','. The comma in the expires date is causing the cookie to be parsed incorrectly when it is returned in the request. The comma is interpreted as a cookie separator and breaks the parse of the expires date. This has been fixed.
When re-directing, the location header will always use the following parameters, if they are specified:
FrontendHTTPPort
FrontEndHTTPSPort
FrontEndHostAdded a new element in the weblogic.xml file:
<!--
The wl-dispatch-policy can be used to assign the webapp to a configured execute queue by identifying the execute queue name. This webapp level param can be overridden at the individual servlet/jsp level. eg:
<servlet>
...
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>CriticalAppQueue</param-value>
</init-param>
</servlet>
-->
<!ELEMENT wl-dispatch-policy (#PCDATA)>isRequestedSessionIdValid() always returned the value, true, which means that the request session ID is valid, even if you changed the session ID in the URL.
Invalid sessions are now correctly detected and reported as invalid.
CreateSessionServlet was checking for the existence of the Cache-Control header, setting it to a valid value if it exists, or adding it to the header list if it does not exist. In both cases, it added another bogus header. This problem was fixed by setting CacheSessionCookie to true in weblogic.xml.
When WebLogic Server returned an HTTP code 204, it set the Content-length to 886 with an HTML error page. Therefore, the load runner client was failing and generating an error stating that "204 responses codes should not have a body but the Content-length was set to 886 (with an HTML error page)". This has been fixed.
There are certain environment variables that a CGI server is expected to provide to scripts that run within it. SERVER_URL, HTTP_COOKIE, and QUERY_STRING, which are present in Netscape's CGI server, were unavailable when running the same CGI program inside of WebLogic's CGI servlet. When a request was made for one of these variables, NULL was returned instead of a value. This has been fixed.
Fixed problem where an included resource was not sent to the servlet output stream when dispatched from another resource that was Forward dispatched inside a JSP BodyTag.
NOTE: The nested BodyTag tag output stream was not being flushed since the forward dispatched request caused the tag to exit - but WebLogic still presumed the output should go to the Tag's nested output stream. This was resolved by clearing out reference to the BodyTag nested output stream when the Forward request was dispatched.
When a user called login() on the LoginContext, this call was directly mapped to the LoginModule's login(), but the logout() method was not implemented. Therefore, a call to this method could not be mapped to the LoginModule's logout(). In WebLogic Server 6.1 service pack 4, LoginModule.logout() is implemented.
In WebLogic Server 6.1 SP02, "=" is included in username when parsing CN for a user in a group.
This problem was resolved by a correction to the lexing code in the LDAPRealmv2.
With WebLogic Server 6.1 SP03, LDAP was calling Group.isMember() for every member of group. In this Service Pack we restored the original behavior of an LDAP realm: now if the groupmembershipcache value is set to 0 then WebLogic checks the LDAP realm for group membership, thus preventing loading all members() if the group contains many members.
The application redeployment (delete & deploy) operation was not always successful when some of the targeted managed servers were down. For example, the JNDI entries for EJB were not registered in running servers, or "Targets" attributes in the config.xml file were lost because of a warning message. This has been fixed.
If the admin server was bounced and re-started, it re-established a connection to the managed server, but the JNDI tree did not show the managed servers. As a result, the application was getting a NameNotFoundExceptions. It would only show up in the admin JNDI tree once the managed servers were re-started. This has been fixed.
When starting a server from a directory other than the domain directory, the option -Dweblogic.RootDirectory=<root directory> can be specified. If the start script is changed to go to the root directory, it would find the application, but the config.xml path got modified to be an absolute path with the RootDirectory appended. The config.xml path no longer gets changed to an absolute path.
When there was a webservice that had a method that received a String as a parameter that is actually an XML document with CDATA sections, after invoking the method, the following response was sent:
weblogic.soap.SoapFault: Connector - Bad request to the server.
This has been fixed.
Fixed a problem using the URLConnection method to make an HTTP connection to a Web Service. Weblogic overrides java.net.HttpURLConnection with its own version which will throw an exception from the getInputStream method if a status code is greater than 400. When the exception is thrown there is no way for the WebService client to retrieve the input stream, and thus the HTTP SOAP Binding is broken. If you have this problem, set the new command line option -Dweblogic.net.http.ignore500status to true.
Integer array object passed by value from Tuxedo to WebLogic Server threw a weblogic.utils.AssertionError.
The problem was resolved with a code fix.
Added the attribute, MemberWarmupTimeoutSeconds, to ClusterMBean.The default value is 0 which results in no cluster warm-up. By default, the cluster start-up sequence remains unchanged. If a value > 0 is set, the cluster members wait for that period of time to synchronize with other members during start-up. All MessageDriven Beans are deployed after the warm-up time. Only then do we start accepting client requests. There is no separate property for delayed MessageDriven Bean deployment.
In 6.1 service pack 2, if you are using Blob/Clob, you have to set <isolation-level> to TRANSACTION_READ_COMMITTED_FOR_UPDATE. Otherwise, you will get the following exception:
java.io.IOException: ORA-22920: row containing the LOB value is not locked
If this happens, when using Blob/Clob, the container will lock all the tables within the transaction. In 6.1 service pack 3, you don't need to set <isolation-level> to TRANSACTION_READ_COMMITTED_FOR_UPDATE anymore. The container will only lock the table that contains the Blob/Clob, and the other table within the transaction will not be locked. This make Blob/Clob much easier to use.In 6.1 service pack 2, a caller's transaction was not being resumed after a transaction started on the server completed. When this happened, the caller's transaction would never complete. This problem would only occur when a remove method that had a transaction attribute that would cause the client's transaction to be suspended was called on an EntityBean in a transaction and a new transaction was started on the server to service the call. Transaction attributes that cause this behavior are NotSupported and RequiresNew. In 6.1 service pack 3, a caller's transaction is being resumed after a transaction started on the server completes.
When a BMP EJB's concurrency strategy was set to Exclusive and the transaction attribute was set to NonSupported, a different instance was assigned when the transaction timeout threshold was met. This has been fixed. In addition, a remote exception is no longer being thrown when the local transaction is rolled back.
For EJB1.1 beans in 6.1 service pack 2, in a single transaction if the persistent field of a bean is changed and then a finder is invoked which returns the same bean, the new value of persistence field is overwritten by the value retrieved from the database. In 6.1 service pack 3, changes made to the EntityBean are no longer lost in the middle of a transaction.
In 6.1 service pack 2, afterCompletion was being invoked on a StatefulSession bean while the bean method was still busy processing. This behavior is counter to the EJB 2.0 specification. In 6.1 service pack 3, serializing Business methods and EJB Callbacks are being invoked which means that afterCompletion will not be invoked on a StatefulSession bean until the bean method has completed processing.
Previously, the container checked for the CMP table by firing an SQL query (select * from tableName where 1=0). This way of checking is not efficient in the case of DB2 where the query generates a full table scan and is very slow if table has a lot of data. The container now provides an option to check the table using DatabaseMetadata. Although usually slower than checking using an SQL query, this way works well for DB2. See the <validate-db-schema-with> tag in the weblogic-rdbms-jar.xml file for more information.
Fixed a problem that was causing the following exception when using an EJB11/ CMP11 bean:
Exception in ejbCreate(): java.sql.SQLException: ORA-01461: can bind a LONG value only for insert into a LONG column
A WebLogic Server domain running Solaris simpappcns could not call a Tuxedo Corba Server domain running on NT.
simpappcns now works for multi-platform environments, for instance, Tuxedo running on Solaris, and WebLogic Server running on Windows NT.
In 6.1 service pack 2 the server was hanging when using MultiPool with more than one database under heavy load. The MultiPool request would hang because the database was not responding which resulted in the whole server locking up at weblogic.jdbc.common.internal.MultiPool.searchHighAvail(MultiPool.java:200).The cause was over-synchronization in the code which has been fixed in 6.1 service pack 3.
Added a new attribute for a JDBC connection pool: Open String Password (or XAPassword in the config.xml file). This new attribute allows for encryption of the database password in the open string for connection pools that use an XA JDBC driver that requires an open string. For more information, see Database Passwords in Connection Pool Configuration in the Administration Guide.
Improved the behavior of database passwords included in the Properties attribute of a JDBC connection pool. If you specify a database password as part of the connection properties or open string, WebLogic Server parses the values and moves them to the Password and Open String Password attributes, respectively, which are encrypted when stored in the config.xml file. For more information, see Database Passwords in Connection Pool Configuration in the Administration Guide.
The time component of an SQL DATE was not removed when the JDBC getDate() methods were used. This behavior was non-compliant with the JDBC 2.0 specification for java.sql.Date: "To conform with the definition of SQL DATE, the millisecond values wrapped by a java.sql.Date instance must be 'normalized' by setting the hours, minutes,
seconds, and milliseconds to zero in the particular time zone with which the instance is associated."
A correction was made to the WebLogic jDriver for Oracle. Hours, minutes, seconds, and milliseconds are now removed from the returned value of the JDBC getDate() methods.
In WebLogic Server 6.1 Service Pack 2, application of the HP-UX UNIX patch (PHSS_24627) caused an HP Server Bus error when WebLogic Server 6 accessed Oracle upon start-up. With the newer aCC libraries version A.03.33, using the -AA CXXFlag, the user gets a java.lang.UnsatisfiedLinkError while accessing Oracle upon WebLogic Server start-up.
This problem was solved.
In 6.1 service pack 2 on a Solaris machine, when WebLogic Server was using SSL to communicate (both as a client and a server) and was using NativeIOEnabled="true", the JVM instance consumed more and more memory and eventually hit the heap size limit. This bug was encountered at a WebLogic Integration installation which relied on SSL communication between trading partners. In 6.1 service pack 3, this problem no longer exists.
The WebLogic Server verboseToZip and logToZip utilities have corrected problems with versioning information. Manifest entries, on which WebLogic classes depend for versioning information, are now pulled from weblogic.jar. The verboseToZip output file no longer includes entries for dynamic proxy classes. If a message log contains any instance of i18n messages, then logToZip now pulls all of the i18n related files from weblogic.jar to the client jar.
A new configuration attribute, WeblogicPluginEnabled, has been added. This attribute can be configured at the server or cluster level.
When this attribute is true for a server (or cluster) that receives requests from a proxy plug-in (or HttpClusterServlet,) a call to getRemoteAddr will return the address of the browser client from the proprietary WL-Proxy-Client-IP header, instead of the web server.
For non-clustered servers that will receive proxied requests, this attribute may be set at the server level, on the Server -->Configuration-->General tab.
WeblogicPluginEnabled is duplicated in ClusterMBean and ServerMBean. ClusterMBean overrides ServerMBean. The default value is false.
The method PageContext.include(String relativeUrlPath) was not throwing any exception when the URL to be included was not found. Added a log message that appears in the context log file and indicates the parent resource and which resource could not be included. The log message appears in the mycontext.log file - where mycontext is the context-path of the webapp.
Added a new semantic-predicate to distinguish between tags with body-content set to "tagdependent" or "jsp". Added a new rule before the existing opening-tag rule in the lexer. When the tagdependent rule is invoked, it does the same as the ordinary open-tag rule, but also looks ahead and matches the content of the JSP until it finds a matching closing tag. Everything it finds is escaped for \n, \r, and \ and printed to "out". It then returns to the parent lexer rule which should immediately find the closing tag.
When the JSP parameter, precompile, was set to true in the web app (WAR) weblogic.xml, only the document root level JSPs were being recompiled each time the server restarted. The subdirectory JSPs were not being recompiled. JSPs are now recompiled, even during pre-compilations, only if they have changed.
WebLogic Server threw a NoClassDefFoundError and was unable to load a class from a JAR file with a period in its name.
WebLogic Server is now able to load a class from a JAR file with a period in its name.
A NoClassDefFoundError occurred if more than one jar file was defined in the manifest classpath entry. For example, when xalan.jar was in WEB-INF/lib of war file, this problem happened because it specified two jar files in the manifest classpath entry.
WebLogic Server no longer throws a NoClassDefFoundError under these circumstances.
weblogic.deploy was always using the default .wlstaging directory, even if the application was originally deployed using a path other than .wlstaging (i.e., the config.xml was hand-edited). This resulted in update not working for applications that were installed any other way than by using weblogic.deploy. This has been fixed.
You can now correctly use the protocol attribute of the wsgen Ant task to specify that you want to use HTTPS (rather than the default HTTP) when invoking a WebLogic Web service.
You must, however, perform the following additional steps if you want to use HTTPS:
System.setProperty( "java.protocol.handler.pkgs", "weblogic.net" );
-Dweblogic.security.SSL.ignoreHostnameVerification=true
WebLogic Web services now support two-way SSL authentication between client applications and RPC-style Web services.
To use two-way SSL authentication, add the following Java code to your client application before you obtain the context you are using the look up your Web service:
InputStream certs[] = new InputStream[3];
certs[0]=new PEMInputStream(new
FileInputStream("sample_key.pem"));
certs[1]=new PEMInputStream(new
FileInputStream("sample_cert.pem"));
certs[2]=new PEMInputStream(new
FileInputStream("sample_ca.pem"));h.put(SoapContext.SSL_CLIENT_CERTIFICATE, certs);
Previously, due to timing problems, exceptions/errors were thrown when EJBs were deployed in a cluster and then a re-deploy or un-deploy was attempted.
It was possible that an undeploy JNDI message would arrive after local undeploy had taken place. This would cause unmarshaling errors, as the classloader for an EJB is discarded once local undeployment of an EJB is done. This unmarshal problem would result in DistributedManagement exceptions popping up in log files, and the EJB could never be un-deployed from a cluster.
Similarly it was possible that a JNDI binding announcement would arrive before local deployment was successful, resulting in same unmarshaling/ de-serialization errors (as EJB classes required to unmarshal are not there yet).
Fixes in 6.1 Service Pack 2 take care of both these problems and remove any timing dependencies in local deploy/undeploy and JNDI Announcements. Now you can successfully deploy/undeploy/redeploy EJBs in a cluster without any exceptions and problems due to race conditions.
Broken links are now fixed in the following examples under wlserver6.1\samples\examples\jsp\:
SimpleSession.jsp
URLEncode.jsp
For SimpleSession the link on Session Timeouts was missing.
For URLEncode the link Writing Web Application Deployment Descriptors was missing.
The RMI-IIOP C++ examples have been fixed to work on UNIX platforms. They are located in the following subdirectories:
/samples/examples/iiop/ejb/entity/tuxclient
/samples/examples/iiop/ejb/stateless/server/tux
/samples/examples/iiop/ejb/stateless/tuxclient /samples/examples/iiop/rmi/server/tux
/samples/examples/iiop/rmi/tuxclientJMS default connection factories are now properly bound as a function of the JMSDefaultConnectionFactoriesEnabled property in the config.xml file. Previously, if no other JMS objects (JMSConnectionFactory, JMSServer) were defined on a given WebLogic Server, then the default connection factories were not bound into JNDI.
Fixed a problem that occurred when trying to simultaneously deploy instances of different message driven beans that subscribe to the same JMS topic
Previously, one or both beans would stop working.
Introduced a -delay option to the beasvc.exe utility which ensures that Managed Servers only start up provided that an Administration Server is already running. The new -delay option lets users delay the Managed Server's JVM thread execution for a specified number of milliseconds.
Previously, a Managed Server failed to start up because it depended on a running Administration Server.
Note: For information about related changes in WebLogic Server 6.1 SP04, see Change in Behavior of -delay Argument for beasvc.exe.
Fixed a problem where a Java client talking to a Weblogic cluster performed more slowly on a 3-server cluster than on a 2-server cluster. Moreover, performance would keep degrading with addition of more servers until the client ensured that there were at least as many socket reader threads on client as the number of servers in the cluster. This involved configuring Execute Thread count and Percent Socket readers client-side properties.
This fix removes the dependency of such a configuration, as the number of servers can grow or shrink dynamically. Now, WebLogic Server creates new threads for socket reading on fly making sure there is one thread per outgoing socket from client. This means customers don't have to tweak those properties for the client for optimal performance when a WebLogic client talks to a WebLogic cluster.
Previously, if an entry was added to the manifest Class-Path for a
.war file, it would be loaded by the web applications's ClassLoader.
With this fix, the application's ClassLoader now loads it. The net
effect is that all web applications now share instances of classes loaded from the manifest Class-path, whereas before they all got their own copies.The Netscape Enterprise Server Plug-In (NSAPI plug-in) enables requests to be proxied from Netscape Enterprise Server (NES, also called iPlanet) to WebLogic Server. The plug-in enhances an NES installation by allowing WebLogic Server to handle those requests that require the dynamic functionality of WebLogic Server.
Previously, reading the HTTP header in the NSAPI plug-in resulted in an unexpected EOF: "PROTOCOL_ERROR [line linenumber of filename]: unexpected EOF reading HTTP headers at line linenumber.
The underlying problem proved to be with parsing large cookies.
This problem is now fixed.
You can now configure Weblogic 6.1 to restrict the number of client
connections. There are two methods:1. Edit the config.xml file to set the weblogic.system.openSockCount parameter, which limits the number of permitted connections:
<Server ListenPort="7001" Name="myserver" NativeIOEnabled="true" TransactionLogFilePrefix="config/mydomain/logs/" MaxOpenSockCount=1000>
2. Use weblogic.Admin to set the socket count or write a JMX Java client to do so and utilize the API in weblogic.management.configuration.ServerMBean, as in this code fragment:
/**
* Returns the maximum number of open sockets allowed
* in server at a given point of time. When max threshold is reached,
* server stops accepting any more new requests until no of sockets
* drops below threshold.
*
* @default java.lang.Integer.MAX_VALUE
* @legalMin 0
* @legalMax java.lang.Integer.MAX_VALUE
*
* @configurable
*
* @oldprop weblogic.system.openSockCount
*/
int getMaxOpenSockCount();
/**
* Sets the maximum number of open sockets allowed
* in server at a given point of time. When max threshold is reached,
* server stops accepting any more new requests until no of sockets
* drops below threshold.
*
* @default java.lang.Integer.MAX_VALUE
*
* @legalMin 0
* @legalMax java.lang.Integer.MAX_VALUE
*
* @configurable
*
* @oldprop weblogic.system.openSockCount
*
*/
void setMaxOpenSockCount (int sockCount);The IndexDirectoryEnabled property now works correctly for managed servers: both directories and files will be listed.
Previously, if IndexDirectoryEnabled was set to "true" for a particular web application and that web application was requested on a managed server, directories were not listed, only files. Also, if files were added or removed from the web application, the changes were not reflected when browser page was updated.
Fixed a problem that occurred when redeploying a web application with a different name. Previously, when a web application was already deployed through the Administration Console and then mbeans were used to programmatically deploy the same .war application under a different name, WebLogic Server would go into an infinite loop.
You can now configure the lifetime of HTTP persistent connections, through the new client-side properties http.keepAliveCache.lifeTime and http.keepAliveCache.proxyLifeTime. Previously, the lifetime was hardcoded on the client side. This value overrode the server-side keepAlive value and led to scalability problems.
A web application with a configured error handler now redirects to this error handler when JSP1 forwards to JSP2 where JSP2 throws an exception.
Previously, the server returned a blank page and showed a status code of 200. The server logged the exception, but the client did not see it.
Fixed a problem where the post data from a request was lost after a forward() (one servlet forwards the request with post data to another) when a web application had <charset-params> defined in its weblogic.xml or <context-param> defined in its web.xml, the post data from a request is lost after a forward().
Fixed a problem where the getParameter() method was not returning the first of multiple values when including a JSP.
Previously, the second value was being returned instead of the first.
The servlet error java.lang.NullPointerException at servlet.internal.ChunkOutput.clearBuffer
no longer occurs when trying to send a SOAP request.
In 6.1 SP1, the default encoding used for servlets and JSPs was the JVM default. As of 6.1 SP2, the default encoding has been changed to ISO8859_1. This change is in accordance with the latest servlet specification. Servlet Specification 2.3 SRV 4.9 states that the default encoding should be ISO8859_1.
Multiple server definitions with the same name are now disallowed. If you have started a server and then attempt to start up the second server with the same name, the server startup aborts, with this error message:
"Server: <yourservername> already exists, make sure that you do not have duplicate copies of this Server name in your XML config file"
Fixed a problem where precompiled JSP's on a Managed Server would recompile even without if the pages hadn't been modified. As a result it took a long time to start up the Managed Server.
With this fix, if classes are already compiled on an Administration Server, when the Managed Server starts up the classes are shipped and their timestamps are preserved, to the Managed Server will not try to recompile them.
Fixed a problem where web applications could not be deployed when network cards were disabled.
Previously, WebLogic Server would try to validate with the DTD at http://www.bea.com/servers/wls610/dtd/weblogic-web-jar.dtd. When it cannot reach www.bea.com, it failed. Now, when there is no network access, the server find weblogic-web-jar.dtd in weblogic.jar and continues.
It is no longer true that when using the wsgen Ant task to assemble a stateless session EJB into an rpc-style Web Service, wsgen fails with a parsing error if the package level of the EJB contains only one level, such as:
package mytest;
When using Remote2Wsdl to manually assemble Web services, you can now specify the context and jndi_name part of the URL equivalent to the location attribute of the <soap:address> element of the WSDL. This means that you can now successfully invoke a method on the Web service proxy obtained from the WSDL.
The built-in SAX parser now correctly parses deployment descriptor files that are written using any character set.
Warning: Prior to this fix, WebLogic Server would have failed to detect encoding problems in your .xml files for English-only applications. Consequently, English-only applications that ran without fail in the past may now fail with this Service Pack 2 fix; WebLogic Server will report an encoding-not-supported error.
If WebLogic Server reports this error, check the specified .xml file for the correct encoding name and syntax.
The following entry in the ejb-jar.xml file no longer causes the entire file not to load:
<message-driven-destination>
<destination-type>javax.jms.Topic</destination-type>
<subscription-durability>Durable</subscription-durability>
</message-driven-destination>Added new JTA example that uses both Oracle's thin driver and JDriver. This example involves two database instances. For each database, the user must set up a single table and create a new transactional connection pool and a new transaction datasource. This example uses J2EE 1.3 features which use non-final API specifications.
Clarified the instructions, syntax, and examples for specifying the cluster address and the listen port when invoking the example clients. Two files changed:
...\samples\examples\cluster\ejb\package.html ...\samples\examples\cluster\rmi\package.html
To get the proper transaction semantics, applications should always use an XA connection factory when inside an EJB. Furthermore, the default connection factory used by Message Driven Beans (MDBs) is now an XA connection factory. To configure user-defined connection factories used inside of an EJB as XA, use the Administration Console to select the XA Connection Factory check box (XAConnectionFactoryEnabled="true") under the Configuration-Transactions tab under the Connection Factories node.
The behavior of the pro-active assignment of messages performed by session pool connection consumers has been corrected. Regardless of the messagesMaximum setting on the connection factory, a connection consumer will consume at most the connectionConsumer.messagesMaximum setting to any given session.
Fixed the JTA race condition that caused the following error if multiple clients used the same resources simultaneously:
Unable to create resource runtime mbean
Improved JTA resource health monitoring. There is now a distinction between an unhealthy/blocked transaction and an unhealthy resource. Once a resource is marked dead, a general mechanism informs the resource provider so that it can refresh itself. Hard-coded constants, such as the two-minute interval (after which an unresponsive resource is declared unhealthy), are now configurable.
Fixed a password-related problem that arose when migrating to WebLogic Server 6.1 from WebLogic Server 5.1 SP7 or later. Previously, if you had LDAP configured in ldaprealm.properties, after running the weblogic.properties file conversion, you had to add the password for the LDAP server to the config.xml file manually. This is no longer required.
When the connection leak detector was in effect, ManagedConnections were automatically destroyed in the time specified by connection-cleanup-frequency and connection-duration-time elements in the weblogic-ra.xml deployment descriptor file. However, if the resource adapter itself recognized that the ManagedConnection was currently active, it had no way to abort the ManagedConnection destruction.
The resource adapter can now abort the automatic destruction of a recognized active ManagedConnection by throwing javax.resource.spi.IllegalStateException from a ManagedConnection.cleanup() method call.
Introduced a switch in the weblogic.xml file that redirects the client using the absolute URL. For example:
<container-descriptor> <redirect-with-absolute-url>true</redirect-with-absolute-url>
</container-descriptor>If set to true, the absolute URL is used.
When launching the Admin startup script, the Administration Server was started but did not detect running Managed Servers. Now, when the Administration Server starts up, it always loads the root directory from the properties directory (-Dweblogic.RootDirectory) or uses the default directory (current directory).
When the deployment descriptor converter is run to generate a config.xml file from the weblogic.properties file that has the property weblogic.security.realmClass=weblogic.security.LDAPRealm set, a Password attribute now gets created in addition to the ConfigurationData for the CustomRealm. Values for both ConfigurationData and Password are based on the information contained in the ldaprealm.properties file. When the config.xml gets saved, the Password gets encrypted.
This is a known issue with the conversion utility for customers migrating from earlier releases of WebLogic Server as well as those users following the migration tutorial.
The JDK automatically specified by the conversion process under the compileCommand tag in the weblogic.xml is set to JAVA_HOME\javac. This setting is no longer missing the bin subdirectory, which is set to JAVA_HOME\bin\javac. A corrected version of the conversion utility has been posted at http://developer.bea.com/tools/techguides.jsp.
You can now use the WebLogic Web Service client API to invoke a Microsoft-hosted Web service, as long as you add the following lines to your Java client program:
CodecFactory factory = CodecFactory.newInstance();
SoapEncodingCodec codec = new SoapEncodingCodec();
codec.writeQualifiedName( false );
factory.register( codec );The EJB Deployment Descriptor Editor had problems creating description folders for new WebLogic EJBs. Also, it was not possible to configure a new entity descriptor, stateless session descriptor or stateful session descriptor for a newly configured/cloned WebLogic EJB. These problems have been fixed.
WebLogic Server now supports "javax.resource.spi.security.GenericCredential" credential-interface or the "Kerbv5" authentication-mechanism-type. Previously, specifying either value for the <authentication-mechanism> in the ra.xml file for the resource adapter being deployed resulted in a failed deployment.
There were problems enabling OS authentication and using Oracle 8.1.6/oci8 with the jDriver. This has been fixed on NT and HP-UX, but still is an issue on Solaris. We have added an error message that reports this problem: OS level authentication is not currently supported due to a defect in OCI 8 libraries.
The following error occurred when the server and serverName properties in a JDBC connection pool were specified with the same value:
<Cannot startup connection pool "jtaXAPool" server and serverName properties must have the same value>
This problem occurred when the XA driver required the server or serverName property to be set. It was occurring with the WebLogic jDriver for Oracle, but not the Oracle thin driver, or the Cloudscape driver. It has been fixed.
If a pre-6.0 WebLogic Server was shut down when it had active database operations, after upgrading to 6.1 some durable consumers may have received messages that were sent to the topic after the durable subscriptions were created. There was a race condition between the scavenger (which updates the database periodically) and Ctrl+c killing the pre-6.0 server. This has been fixed.
JMS provides better performance by not synchronizing writes to the file stores. Synchronous writes are configurable via the command line using properties and are enabled by default.
Dweblogic.JMSFileStore.SynchronousWritesEnabled=(false|true)
Dweblogic.JMSFileStore.<store name>.SynchronousWritesEnabled=(false|true)
The first property applies to all JMS file stores running on the server. The second more specific property takes precedence over the first. The order where the properties are specified makes no difference.
The returned values and exceptions from getXXX() in MapMessage now return the correct values, as follows:
If the value for the field does not exist, then getByte() should return NumberFormatException.
If the value for field can not convert, then getByte() should return MessageFormatException.
If the value for the field does not exist, then getBoolean() should return false.
If the value for the field can not convert, then getBoolean() should return MessageFormatException.
A detailed log message was added for failures of the first SQL query, which describes the likely problem and provides a work-around. The work around ensures that the connection pool being used has permission to access the given tables. It also fully qualifies the table names by configuring a table name prefix in the JMS JDBC store that includes the schema and catalog names: ([schema.[catalog.]]prefix).
When setting the message listener on a subscriber, JMS now remembers the context classloader at the time of setting so that when it calls onMessage on that message listener it can set the context classloader appropriately. This allows EJB to send messages to a web application subscriber that contains classes only present in the EJB.
There is a new configuration option for "acknowledge" to specify the new or old behavior. This has been added because JavaSoft has proposed changing the meaning of "acknowledge" based on the description in the JMS 1.0.2 specification as opposed to the one specified in the Javadoc, as follows:
"Section 4.4.13: Acknowledging a consumed message automatically acknowledges the receipt of all messages that have been delivered by its session."
Fixed a problem migrating text messages generated using WebLogic Server 6.0 to WebLogic Server 6.1. The messages could not be received and the following message was thrown:
The corresponding file block will be zeroed out on disk, and this corruption will no longer be reported in the future. java.io.StreamCorruptedException: Unknown object stream version.
When you were using the conversion utility, if a weblogic.properties file included the property weblogic.httpd.register.Name=weblogic.servlet.FileServlet and the servlet did not have initial arguments associated with it (it did not have the property weblogic.httpd.initArgs.file=arg1=value defined in the same weblogic.properties file), then the conversion utility was throwing a Null pointer exception. This has been fixed.
If the username property is set from the weblogic.Admin or weblogic.Server command lines, the username must be the system password. Note however, that the username syntax is retained to prevent breaking a user's scripts. The weblogic.management.password property value must be the system password and the username may not be modified in the config.xml file.
According to the JTA spec documentation of setTransactionTimeout():
"seconds: The value of the timeout in seconds. If the value is zero, the transaction service restores the default value."
If the value was zero, WebLogic Server was not resetting the default value. This has been fixed.
When using IIS to browse and call a regular JSP page that calls a Java Bean and getting a ResultSet reference, there were problems when submitting through the FORM POST method. The HTML stream was getting truncated when it came back to IIS--in other words, the page was only partially painted. This has been fixed.
Fixed a problem with large deployments of WebLogic Server, wherein for a period of time a cluster node behaves as if it is the only one member in the cluster when it's not. Now, using ListenDelaySecs, you can delay the http request handling until it finds the other members. For example:
<Server> ListenDelaySecs="30" </Server>
Delay the http listen thread for a configurable amount of time so that the new node has time to acknowledge the existence of other cluster members.
Fixed problems compiling JSPs when debugging was turned on. Now you can specify compiler flags in weblogic.xml. For example:
<!-- weblogic.xml: weblogic-specific web app descriptor --> <weblogic-web-app>
<session-descriptor>
</session-descriptor>
<jsp-descriptor>
<jsp-param>
<param-name>compileCommand</param-name> <param-value>jikes</param-value>
</jsp-param>
<jsp-param>
<param-name>compileFlags</param-name>
<param-value>+E -nowarn</param-value>
</jsp-param>When the web.xml had the setting inputCharset./A*=Shift_JIS inputCharset./B*=EUC-JP, and two clients simultaneously accessed the JSP/Servlet, WebLogic Server failed to handle these string correctly. It was possible to get the correct result from one client, but not from the other. This has been fixed.
The WSDL of a WebLogic Web Service is now generated by a JSP, which by default dynamically sets the host and port of the WebLogic Server instance that hosts the service. You can specify that the host and port be hard-coded in the WSDL by explicitly specifying their values when you assemble the Web service using the wsgen Ant task.
Previous releases of the XML subsystem included an error in Apache's implementation of the javax.xml.*.parse(File) method, included in the xmlx.jar file. Because WebLogic Server no longer includes this JAR file in the product and WebLogic Server's own implementation of the method has always been correct, this problem does not apply to the current release.
Generated custom parsers no longer convert newline characters that are embedded in attributes and tag bodies into a single space character.
Note: The ability to generate custom parsers is deprecated in this release of WebLogic Server. Instead, use WebLogic Server's high-performance parser.
The problem was not exhibited when:
or when:
When the hang occurs after a restart, all the threads in the default Group hang with the following stack trace:
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:415)
at weblogic.wtc.jatmi.TuxXidRply.get_specific_reply (TuxXidRply.java:203)at weblogic.wtc.gwt.TuxedoXA.internalCommit(TuxedoXA.java:259)
at weblogic.wtc.gwt.TuxedoXA.commit(TuxedoXA.java:328)
at weblogic.wtc.gwt.OatmialCommitter.execute(WTCStartup.java:2767)at...The problem was solved by modifying the weblogic.wtc.gwt.WTCStartup method to sleep for one second after each Kernel.execute(myCommitter).
In WebLogic Server 6.1 SP02, WebLogic Tuxedo Connector did not properly translate local resource name to remote service name.
A correction to the translation code solved the problem.
The Xerces parser always attempted a call to System.getProperty(). This would throw an exception in an Applet, which does not have permission to retrieve properties. The following partial exception could be observed in an Applet making a JMS call:
----------- Linked Exception -----------
java.rmi.MarshalException: failed to marshal
connectionCreate(Lweblogic.jms.dispatcher.DispatcherWrapper;); nested
exception is:
java.rmi.UnexpectedException: Failed to parse descriptor file; nested
exception is:
java.security.AccessControlException: access denied
(java.util.PropertyPermission weblogic.apache.xerces.maxentityrefs read)
[...]The code was modified so that the parser does not attempt to read system properties with Applet clients.
In an environment with multiple clusters using the same multicast address, large log files resulted, causing overly frequent file rollover.
The debug messages are similar to:
####<Jul 23, 2002 4:06:26 PM EDT> <Debug> <Cluster> <ustrntda01> <wts-cluster_test> <ExecuteThread: '9' for queue: 'default'> <> <> <000000> <dropped fragment from foreign domain/cluster domainhash=95475927 clusterhash=-1674453961>
The problem occurred because, in weblogic.cluster.ClusterDebug.java, the flag controlling whether or not debug messages are logged was set to true. The problem was solved with a code fix.
HTTP session failover resulted in a ClassCastException, when the Managed Server hosting the session was shut down. Failover was successful when error message was ignored.
This problem was reliably reproduced in this configuration:
1) Two clustered server instances, running 6.1 SP02.
2) Cluster hosted a WLP 4.0 sSP002 portal application.
3) One IPlanet web server with WebLogic Server plug-in pointing to the two-node cluster.
The problem was not consistently reproducible in other configurations.
This problem was associated with a problem in the WebLogic Server shutdown sequence.
This problem was resolved by a new service to shutdown RMIServerService.
Failover did not work for a stateful session bean in a cluster. The request URL contained the local server name instead of the cluster DNS name.
The following exception occurs: java.rmi.NoSuchObjectException: Unable to locate EJBHome: 'statefullCluster' on server: 't3://172.23.135.83:7600 at weblogic.ejb20.internal.HomeHandleImpl.getEJBHome(HomeHandleImpl.java:80) at weblogic.ejb20.internal.HandleImpl.getEJBObject(HandleImpl.java:204) at com.bea.cluster.testClusterEJBServlet.doGet(testClusterEJBServlet.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2637) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2359) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
Problem was solved by modifying the getURL() method in weblogic.ejb20.internal.BaseEJBHome.java to provide the cluster address as the host portion for the URL.
A stack trace resulted from a error looking up a session. A secondary server instance was being shutdown. While making a log entry for a request it served, the HTTP server tried to get the user information from the session. As a result it tried to look up the secondary server even though it was down, resulting in this stack trace.
<Dec 26, 2002 7:17:55 PM EST> <Error> <HTTP Session> <Error looking up session for id:2LcR6Ool2IC5qNtFZhThJClYVYEXt9KWG2ciXmAXZ4XiBAHPiHx4!-1379505194!stcasfi01b.usa-ed.net!8001!7002!-1127797657!stcasfi02b.usa-ed.net!8001!7002 java.rmi.ConnectIOException: Server is being shut down Start server side stack trace: java.rmi.ConnectIOException: Server is being shut down at weblogic.rjvm.RJVMImpl.dispatchRequest(RJVMImpl.java:692) at weblogic.rjvm.RJVMImpl.dispatch(RJVMImpl.java:666) at...
The primary server correctly selected a new secondary from the available server list, and no session data was lost.
This problem was resolved with a code fix. Now, the server obtains user information from ThreadLocal, instead of the session.
In WebLogic Server 6.1 SP04, session replication stopped working after a failure to replicate a non-serialized object. Invocation of a JSP that tried to set non-serialized data into the session object, resulted in the expected exception:
<Mar 19, 2003 2:58:23 PM PST> <Error> <Cluster> <All session objects should be serializable to replicate. Please check the objects in your session. Failed to replicate non serializable object>
Then, for all subsequent requests, sessions were not replicated, and this exception occurred:
<Mar 19, 2003 2:58:48 PM PST> <Debug> <Cluster> <Unable to create secondary for -8956818414963087828>
The problem was solved with a code change. Now, when a non-serializable object is encountered, the method returns, instead of trying other secondaries.
In WebLogic Server 6.1 SP03 the Messaging Bridge Adapter threw a NullPointerException in unregisterResource during shutdown. This occurred if messages have been sent but not consumed before the shutdown of the server has been initiated. The problem did not occur if Messaging Bridge is not deployed and the Adapter is.
The configuration was: jms-xa-adp.rar Messaging Bridge Adapter and a Messaging Bridge between MQSeries 5.2 and JMS
The problem was corrected with a code fix to check wrappedXARes beforing attempting to unregister.
In WebLogic Server 6.1 SP03, JCA-Connection.close throws java.lang.reflect.UndeclaredThrowableException instead of ResourceException
A code fix was implemented to ensure that the resource adaptor's original exception is passed.
In WebLogic Server 6.1 SP03 and SP04, RAR deployment failed after any of its descriptor parameters were changed in console.
Analysis revealed that any descriptor change in console caused reset of pool parameters if they had not been changed from default values. Pool parameters were inappropriately defined:
<pool-params>
<initial-capacity>0</initial-capacity>
<max-capacity>0</max-capacity>
<capacity-increment>0</capacity-increment>
<shrinking-enabled>false</shrinking-enabled>
<shrink-period-minutes>0</shrink-period-minutes>
</pool-params>
This caused deployment failure due to max capacity value 0 which is prohibited. No activities could be performed on RA after that.
In 6.1, ResourceAdapterComponentMBean was used when getting descriptor values. However, ResourceAdapterComponentMBean constructor did not automatically have defaults set (the way ConnectorComponentMBean does) and also did not set defaults manually. The fix was to set them manually.
A customer with large application (40 MB) migrating from 6.1 SP01 experienced network overload and slow WebLogic Server startup, as a result of WebLogic Server copying the application to Managed Servers at startup.
A code change was made to address this problem. Now, unchanged applications are not copying to Managed Servers at startup.
Use the forceApplicationCopy parameter to cause applications to be copied to Managed Servers at startup, whether changed or unchanged. See New Parameter for Forced Application Update.
When the "Auto Deployment Enabled" attribute on the Domain -> Configuration -> Applications page was turned off, application components were still deployed automatically when application file was copied to the applications directory.
Investigation revealed that the "Auto Deployment Enabled" attribute is not used in WebLogic Server. Instead, auto deployment is controlled by the DomainMBean.setProductionModeEnabled property, which is set at startup on the command line.
The AutoDeployedEnabled attribute has been removed from the Administration Console.
In WebLogic Server 6.1 SP03, an InstanceNotFoundException occurred when creating a JMS Topic at runtime in a cluster. The Topic was created with JMSHelper.createPermanentTopicAsync in a startup class targeted to a Managed Server in a cluster. After the Topic was created, when the user clicked Destination Link for the JMS Server in the Administration Console, this message was displayed :
java.lang.reflect.UndeclaredThrowableException: javax.management.InstanceNotFoundException: mydomain:Name=testTopic12,Type=JMSTopic at com.sun.management.jmx.MBeanServerImpl.getMBean(MBeanServerImpl.java:1680) at com.sun.management.jmx.MBeanServerImpl.getAttribute(MBeanServerImpl.java:1152) at weblogic.management.internal.MBeanProxy.getAttribute(MBeanProxy.java:254) at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:187)
In WebLogic Server 6.1 SP02, in a configuration with an Administration Server and three Managed Servers, a deadlock when one of the Managed Servers was restarted.
Analysis revealed that lookupServerRuntime() on a Managed Server resulted in unnecessary getMBean() calls to the Administration Server.
The problem was resolved with a code fix.
In WebLogic Server 6.1 SP03, on Solaris Sparc 2.8, the domain log file did not rotate by time. Under Windows 2000, 3 log files were created, then rotation stopped. When old log files were deleted, rotation started again. For Windows 2000, log rotation worked after an upgrade from SP01 to SP03, but not with the fresh installation of SP03. The configuration for the domain log is:
<Log FileName="config/mydomain/logs/wl-domain.log" FileTimeSpan="1" Name="mydomain" RotationType="byTime" RotationTime=10:00/>
The problem was solved with a code fix.
In WebLogic Server 6.1 SP03 and SP04, the Administration Console option:
Web Application->webapp1->Monitoring->Monitor all Active Web Applications...
did not work for a web application inside an .ear file.
The problem was resolved with a code fix.
A configuration with one Administration Server and five Managed Servers, running under WebLogic Server 6.1 SP02, Solaris 2.8, and JDK1.3.1_04, an attempt to deploy an EAR with 3 EJB components using weblogic.deploy utility from a different machine caused the Administration Server to hang. The thread dump reported a deadlock. The stack trace contained:
Execute thread 4(admin_rmi queue) holds lock of the com.sun.management.jmx.MBeanServerImpl and waiting to acquire lock on weblogic.logging.LogManager. Execute thread 8(default queue) holds lock of the weblogic.logging.LogManager and waiting to acquire lock on com.sun.management.jmx.MBeanServerImpl.
Analysis revealed a deadlock in the LogManager and FileStreamLogger.
A code fix resolved the error.
In WebLogic Server 6.1 SP02, invocation of MBeanHome.deleteMBean() resulted in a null point exception.
The configuration was four managed servers, each on a different physical machine, with a JMX client running against each (on one-to-one basis). The JMX clients encounter NullPointerException when doing a MBeanHome.deleteMBean.
Analysis revealed that the problem was related to the asynchronous deletion of multiple Managed Servers. One Managed Servers deleted its references in other mbeans before deleting itself, while another Managed Servers does the same thing, resulting in null pointer exception.
The problem was resolved by implementing try/except blocks around the code that obtains the metadata for an MBean (i.e., mbean.getMBeanInfo()). When deleting an MBean, a list of current MBeans in the MBeanServer is first obtained, then references to the bean being deleted are removed. The problem is, is that other delete threads are doing the same thing and thus may delete a bean in our (static) list, so when we go to get the meta-data on the bean to update it, we NPE. This patch ignores that NPE and we go to the next one in our list.
In WebLogic Server 6.1 SP02, a Java deadlock was detected in an Administration Server. The thread dump indicated a java level deadlock as follows, where Thread 8 holds the lock on RemoteMBeanServerImpl and tries to obtain one on LogManager, which is held by Thread 6 who is in turn waiting on RemoteMBeanServerImpl.
Java Stack for "ExecuteThread: '8' for queue: '__weblogic_admin_rmi_queue'":
at weblogic.logging.LogManager.addSubsystem(LogManager.java:
58) - waiting to lock <f55b6358> (a weblogic.logging.Log
Manager) at weblogic.logging.LogOutputStream.getLogManager
(LogOutputStream.java:32) at weblogic.logging.LogOutput
Stream.error(LogOutputStream.java:63) at weblogic.management.
internal.Helper.error(Helper.java:1391) at weblogic.
management.internal.Helper.error(Helper.java:1404) at weblogic.management.internal.ConfigurationMBeanImpl.
postDeregister(ConfigurationMBeanImpl.java:900) at com.sun.
management.jmx.MBeanServerImpl.postDeregisterInvoker
(MBeanServerImpl.java:2314) at com.sun.management.jmx.MBean
ServerImpl.unregisterMBean(MBeanServerImpl.java:967) - locked <f550eec8> (a weblogic.management.internal.RemoteMBean
ServerImpl) at weblogic.management.internal.RemoteMBeanServer
Impl.unregisterMBean(RemoteMBeanServerImpl.java:213) at ..Java Stack for "ExecuteThread: '6' for queue: 'default'":
at com.sun.management.jmx.MBeanServerImpl.getMBean(MBean
ServerImpl.java:1672) at com.sun.management.jmx.MBeanServer
Impl.getAttribute(MBeanServerImpl.java:1150) at weblogic.
management.internal.MBeanProxy.getAttribute(MBeanProxy.java:254) at weblogic.management.internal.MBeanProxy.invoke
(MBeanProxy.java:187) at $Proxy7.isStdoutEnabled(Unknown Source) at weblogic.logging.ConsoleLogger.isLog(Console
Logger.java:81) at weblogic.logging.ConsoleLogger.log
(ConsoleLogger.java:70) at weblogic.logging.LogManager.log(Log
Manager.java:260) - locked <f55b6358> (a weblogic.logging.LogManager) at weblogic.logging.MessageLogger.log(MessageLogger.java:17) at weblogic.t3.srvr.T3SrvrLogger.logRemovingClientContextSoftDisconnect(T3SrvrLogger.java:1204) at weblogic.t3.srvr.ClientContext.dieIfTimedOut(ClientContext.java:512) at ...The problem was solved by a code change to remove unnecessary locks in LogManager.
The ClusterMBean.setClusterAddress()method accepted an illegal value and did not throw an IllegalArgumentException.
The problem was resolved by checking that the cluster address is during server startup.
The ClusterMBean.setMultiCustAddress() method accepted an illegal value and did not throw an IllegalArgument Exception.
The problem was resolved by a code change.
In WebLogic Server 6.1 SP03, stopping a Managed Server after its Administration Server was shutdown caused an exception. The problem occurred with this sequence of actions:
This exception resulted:
Unexpected Exception Start server side stack trace: java.rmi.ConnectException: Unable to get direct or routed connection to: '-19546889165621794S:dwarkamai:[7001,7001,-1,-1,7001,-1,-1]:OAMdomain:adminServer' at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:109) at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:127) at...
The shutdown command from weblogic.Admin was successful.
The problem was solved by catching the exception that occurs when shutting down Managed Server when Administration Server is down.
In WebLogic Server 6.1 SP02 a Java client accessing a DataSource via the Apache plug-in received a TunnelDeadResponse .
WebLogic Server was running under running under Windows2000, and had patch CR061847. The plug-in was running under Solaris.
The exception was:
<May 31, 2002 4:16:35 PM PDT> <Error> <HTTPClientJVMConnection> <java.net.ProtocolException: Tunneling result not OK, result: 'DEAD', id: '2' at weblogic.rjvm.http.HTTPClientJVMConnection.receiveAndDispatch (HTTPClientJVMConnection.java:413) at weblogic.rjvm.http.HTTPClientJVMConnection.execute (HTTPClientJVMConnection.java:296) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)>
When the plug-in was removed, the exception did not occur.
Analysis revealed that WebLogic Server could not find an RJVM for the host/port combination, although one existed, because the rjvm manager's synonym cache did not maintain the port information. When WebLogic Server failed to find a match in the cache when bootstrapping, it created a new RJVM.
After bootstrapping, WebLogic Server identified the new RJVM as a duplicate, and attempted to close it. In some cases, the message was not delivered to the server if queued. This caused the server to timeout on the RJVM and send a DEAD response.
This problem was resolved by a code change to make the synonym cache maintain port information.
In WebLogic Server 6.1 SP03, Node Manager threw NumberFormatException when a client socket connects and then closes:
<Oct 28, 2002 3:38:18 PM CST> <Info> <NodeManager@localhost:5555>
<SecureSocketListener: listening on localhost:5555>
java.lang.NumberFormatException: null
at java.lang.Integer.parseInt(Integer.java:382)
at java.lang.Integer.parseInt(Integer.java:463)
weblogic.nodemanager.SocketInputHandler.run(SocketInputHandler.java:109)
There were no discernible side effects. Node Manager could still start and stop Managed Servers after the error.
A code fix was implemented to handle exceptions on sockets that are opened and closed with out any transfer of data.
In WebLogic Server 6.1 with or without SP02, setInstanceFollowRedirects() does not work.
JDK1.3.1 introduced the following methods in java.net.HttpURLConnection: getInstanceFollowRedirects() and setInstanceFollowRedirects().
These methods can be used to disable URL redirects for a specific HttpURLConnection. HttpURLConnection was ignoring the flag set by setInstanceFollowRedirects().
The problem was solved by a code fix to HttpURLConnection's redirect logic to ensure process redirects in accordance with the setting of InstanceFollow
Redirects.During load testing of a 35-plus node cluster, a null pointer exception was encountered at weblogic.utils.collections.NumericValueHashtable.
containsKey(NumericValueHashtable.java:138)<May 9, 2002 5:08:22 PM BST> <Error> <Management> <InvocationTargetException getting attribute SecondaryDistributionNames on MBean bluemartini:Location
=WebConnectaw01,Name=WebConnectaw01,ServerRuntime=WebConnectaw01,Type=ClusterRuntime. Method: public java.lang.String[] weblogic.cluster.ClusterRuntime.getSecondaryDistributionNames() java.lang.NullPointerException at weblogic.utils.
collections.NumericValueHashtable.containsKey(NumericValueHashtable.java:138) at weblogic.cluster.replication.
ReplicationManager.getSecondaryDistributionNames(ReplicationManager.java:1245) at weblogic.cluster.ClusterRuntime.getSecondaryDistributionNames(ClusterRuntime.java:100) at java.lang.reflect.Method.invoke(Native Method) at weblogic.management.internal.DynamicMBeanImpl.getAttribute(DynamicMBeanImpl.java:511) at weblogic.management.internal.
DynamicMBeanImpl.getAttribute(DynamicMBeanImpl.java:477) at com.sun.management.jmx.MBeanServerImpl.getAttribute(MBeanServerImpl.java:1181) at com.sun.management.jmx.MBeanServer
Impl.getAttribute(MBeanServerImpl.java:1151) at weblogic.management.internal.RemoteMBeanServerImpl_WLSkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServer
Ref.invoke(BasicServerRef.java:298) at weblogic.rmi.
internal.BasicServerRef.handleRequest(BasicServerRef.java:267) at weblogic.rmi.internal.BasicExecuteRequest.execute
(BasicExecuteRequest.java:22) at weblogic.kernel.Execute
Thread.execute(ExecuteThread.java:139) at weblogic.kernel.
ExecuteThread.run(ExecuteThread.java:120)Analysis determined that the getSecondaryDistributedNames() method should allow for null value from getOtherHost(). Problem resolved.
In WebLogic Server 6.1 SP02 and patch CR061847, a Java swing client obtaining context and accessing a JDBC data source received a TunnelDeadResponse. The client gets an initial context, gets a connection via a datasource, closes the initial context, closes the connection, and then repeats this sequence of processing. This error results:
On the server, this exception was thrown:
####<Nov 21, 2002 12:24:20 PM CST> <Debug> <HTTPServerJVMConnection> <hpwlinc03> <admin> <ExecuteThread: '14' for queue: 'default'> <> <> <000000> <Closing JVM socket: 'weblogic.rjvm.http.HTTPServerJVMConnection@4cfbd8 - id: '0', closed: 'true', lastRecv: '1037903025816''> java.lang.
Throwable: Stack trace at weblogic.rjvm.http.HTTPServer
JVMConnection.close(HTTPServerJVMConnection.java:383) at weblogic.rjvm.ConnectionManager.removeConnection(ConnectionManager.java:879) at weblogic.rjvm.ConnectionManager.
shutdown(ConnectionManager.java:508) at weblogic.rjvm.
ConnectionManagerServer.shutdown(ConnectionManagerServer.java:443) at weblogic.rjvm.RJVMImpl.peerGone(RJVMImpl.java:804) at weblogic.rjvm.RJVMImpl.gotExceptionReceiving
(RJVMImpl.java:533) at weblogic.rjvm.ConnectionManager.got
ExceptionReceiving(ConnectionManager.java:736) at weblogic.rjvm.http.HTTPServerJVMConnection.checkIsDead(HTTPServerJVMConnection.java:238) at weblogic.rjvm.http.HTTPServer
JVMConnection$TunnelScavenger.trigger(HTTPServerJVMConnection.java:405) at weblogic.time.common.internal.
ScheduledTrigger.executeLocally(ScheduledTrigger.java:238) at weblogic.time.common.internal.ScheduledTrigger.
execute(ScheduledTrigger.java:229) at weblogic.kernel.Execute
Thread.execute(ExecuteThread.java:139) at weblogic.kernel.
ExecuteThread.run(ExecuteThread.java:120)The client threw this exception:
<Nov 21, 2002 12:24:18 PM CST> <Error> <HTTPClientJVM
Connection> < java.net.Protocol Exception: Tunneling
result not OK, result: 'DEAD', id: '0' at weblogic.rjvm.
http.HTTPClientJVMConnection.receiveAndDispatch(HTTPCli entJVMConnection.java:413) at weblogic.rjvm.http.HTTPClient
JVMConnection.execute(HTTPClientJVMConne ction.java:296) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.
java:120)Diagnosis revealed that a timeout occurred after WebLogic Server failed to find an RJVM for host/port combination, although it existed. The RJVM's synonym cache did not maintain port information. The problem was solved with a code fix to maintain port information in the RJVM's synonym cache.
In the Solaris distribution with Performance Pack, log messages showed an incorrect value for the file descriptor soft limit. The value of file descriptor hard limit was shown for both the soft limit and hard limit.
This is the error in weblogic.log:
####<Mar 5, 2002 5:07:27 PM PST> <Info> <Posix Performance Pack> <bolinas> <myserver> <ListenThread> <system> <> <000000> <System has file descriptor limits of- soft: '1024', hard: '1024'>
####<Mar 5, 2002 5:07:27 PM PST> <Info> <Posix Performance Pack> <bolinas> <myserver> <ListenThread> <system> <> <000000> <Using effective file descriptor limit of: '1024' open sockets/files.>
This error was exhibited under Solaris 2.6 and Solaris 2.8.
The error was corrected by a syntax correction to associated script template. The incorrect syntax:
[ !$? -a "$maxfiles" != 1024 ];
was replaced by:
[ ! $? -a "$maxfiles" != 1024 ];
Session data was replicated across two separate WebLogic Clusters, hosted in a common domain, when each cluster used the same name for the session cookie.
Problem was solved by implementing a check to verify that the secondary host/port is in the same cluster as the primary host for the session.
In a multi-tier implementation, after ten hours of stress testing, the web tier hung. This occurred while the web tier (consisting of servlets, jsps, and custom classes that implement a custom cache) was communicating with the EJB tier (all stateless session beans), after the EJB tier closed the Connection Manager, due to missed RJVM heartbeats.
Before the web tier hangs the following are the exceptions are thrown in the ejb tier. <Sep 24, 2002 8:43:58 AM PDT> <Info> <RJVM> <Failure in heartbeat trigger for RJVM: '7831636024374910916S:10.10.10.187:[8001,8001,8002,8002,8001,8002,-1]:webserver:sourcingWebserver' java.rmi.ConnectException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl@3bedf2 - id: '7831636024374910916S:10.10.10.187:[8001,8001,8002,8002,8001,8002,-1]:webserver:sourcingWebserver' connect time: 'Tue Sep 24 06:15:16 PDT 2002'' has already been shut down at weblogic.rjvm.ConnectionManager.getOutputStream(ConnectionManager.java:1348) at weblogic.rjvm.ConnectionManager.createHeartbeatMsg(ConnectionManager.java:1306) at weblogic.rjvm.ConnectionManager.sendHeartbeatMsg(ConnectionManager.java:497) at weblogic.rjvm.RJVMImpl$HeartbeatChecker.trigger(RJVMImpl.java:1032) at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:238) at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:229) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
Problem was solved by adding logic to assure that pending responses are notified of peer gone events.
In WebLogic Server 6.1 SP03 on a Sunblade 100 single-CUP Solaris machine, two independent server instances could not look up InitialContext on each other. After one server instance looked up InitialContext, when a second server instance on the the same machine tried to look up InitialContext on the same machine this exception resulted:
<2002/10/09 4:23:56:JST> <Debug> <ConnectionManager> <Attempt to sendMsg using a closed connection> javax.naming.CommunicationException. Root exception is java.rmi.ConnectException: Attempt to sendMsg using a closed connection at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:85) at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:262) at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:229) at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35) at $Proxy45.lookup(Unknown Source) at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:341) at javax.naming.InitialContext.lookup(InitialContext.java:345) at com.bea.samples.servlet.TestServlet.service(TestServlet.java:40) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2546) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2260) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
The problem was not replicated on Sun Enterprise. The problem did not occur on Sun Blade, if the lookup was done using an IP address instead of localhost.
Analysis indicated that client RJVM tried to close duplicate T3JVMConnections. It issued a CMD_REQUEST_CLOSE to the server and closed the RJVM. However, if the server queued this message, then the RJVM was marked as closed.
The problem was solved by a code change to prevent RJVM shutdown when detecting duplicate connections and CMD_REQUEST_CLOSE does not get delivered to server.
Running under Windows XP resulted in a java.lang.UnsatisfiedLinkError: no muxer in java.library.path error.
This is because WebLogic Server does not correctly report Windows XP as the host operating system. With JDK 1.3.1_03, os.name is returned "Windows 2000".
Modification of a method in the SocketMuxer resolved the problem..
After starting Managed Servers with Node Manager, information about communications between the Administration Server and Managed Servers, such as the network channel used and the JVM ID, could not be viewed by right-clicking the server name in the left pane of the Administration console and selecting "View connections".
Analysis revealed that the getConnections() method of ServerRuntimeMBean was returning zero connection object instances, due to an underlying bug in ConnectionManagerServer.
The problem was resolved by a a code fix to ensure that connection manager reports on connections for which the RJVM is null.
WebLogic Server muxer libraries did not have build dates, making it difficult to determine which version of a library was in use. Although NTSocketMuxer had the build date/time embedded, PosixSocketMuxer did not.
Problem solved by adding build date/time to PosixSocketMuxer. Now, the following message will be displayed when the muxer initializes:
<Oct 15, 2002 3:44:04 PM PDT> <Info> <socket> <000406> <PosixSocketMuxer was built on Oct 15 2002 15:05:11>
Under OS/390 Linux (SuSE Linux Kernel 2.2), libmuxer.so threw this error:
java.lang.UnsatisfiedLinkError: /opt/weblogic6/lib/linux/s390/libmuxer.so: /opt/weblogic6/lib/linux/s390/libmuxer.so: ELF file machine architecture not s390 at java.lang.ClassLoader$NativeLibrary.
load(Native Method) at java.lang.ClassLoader.loadLibrary0
(ClassLoader.java:1799)The problem was resolved by providing binaries for the Linux Kernel 2.2.
Deployment of an EJB with a custom call router in the jar failed with IllegalArgumentException. The class failed to load because the classForName() method of the ReplicaAwareInfo class looked for classes in the system classloader instead of the ContextClassLoader on the current thread.
Stacktrace:
java.lang.reflect.InvocationTargetException: java.lang.
IllegalArgumentException: Class weblogic.qa.tests.cluster.
ejb.callrouter.BaseCallRouterImpl not found at weblogic.rmi.
cluster.ReplicaAwareInfo.classForName(ReplicaAwareInfo.java:172) at weblogic.rmi.cluster.ReplicaAwareInfo.getCallRouter
(ReplicaAwareInfo.java:132) at weblogic.rmi.cluster.Basic
ReplicaHandler.newReplicaList(BasicReplicaHandler.java:78) at weblogic.rmi.cluster.BasicReplicaHandler.<init>(Basic
ReplicaHandler.java:72) at java.lang.reflect.Constructor.
newInstance(Native Method) at weblogic.rmi.cluster.Replica
AwareInfo.instantiate(ReplicaAwareInfo.java:186) at weblogic.rmi.cluster.ReplicaAwareInfo.getReplicaHandler(ReplicaAwareInfo.java:117) at weblogic.rmi.cluster.ReplicaAware
RemoteRef.initialize(ReplicaAwareRemoteRef.java:79) at weblogic.rmi.cluster.ClusterableRemoteRef.initialize(ClusterableRemoteRef.java:28) at weblogic.rmi.cluster.Clusterable
RemoteObject.initializeRef(ClusterableRemoteObject.java:275) at weblogic.rmi.cluster.ClusterableRemoteObject.onBind
(ClusterableRemoteObject.java:150) at weblogic.jndi.
internal.BasicNamingNode.bindHere(BasicNamingNode.java:346) at weblogic.jndi.internal.ServerNamingNode.bindHere(Server
NamingNode.java:105) at weblogic.jndi.internal.BasicNaming
Node.bind(BasicNamingNode.java:281) at ...Problem was resolved by setting the context classloader to the application classloader while calling deploy() on ClientDrivenBeanInfoImpl and checking in the context classloader to load the call router class.
A new ability to throttle incoming request traffic by configuring the maximum length of an execute queue has been provided. The maximum length of an execute queue can be set with the new -D flag, weblogic.kernel.allowQueueThrottling.
This capability is provided to help customers throttle "slow moving resource intensive" requests on a custom queue. Queue throttling is supported for custom application queues, not for default or WebLogic Server internal queues.
When the configured queue length is exceeded calls to Kernel.execute() will result in client receiving a recoverable remote exception, and a 503 response.
A high volume of assertion failed errors occurred in PosixSocketMuxer.cleanup(), accompanied by a steady growth in the number of sockets in the CLOSE_WAIT state. ulimit was reached, and server instance restart was required.
Problem was solved by implementing logic that checks if fdr.sock is null before throwing an assertion error in cleanup.
Erroneous failure duration was reported in t3.srvr.ListenThread calling logListenFailed(). This was a numeric error in a message generated when the server failed to listen due to an underlying IOException. Example of the message:
<Jun 11, 2002 2:37:33 PM PDT> <Critical> <WebLogicServer> <Failed to listen on port 7772, failure count: 3, failing for 1,023,831,450 seconds, java.net.SocketException: File table overflow>
The problem was fixed by correcting a typographical error in t3.srvr.ListenThread.
JSPs were recompiled unnecessarily for the e2e sample. The JSPs in e2edomain always got recompiled when running b2c and b2b examples. The time stamps of those JSPs were properly backdated, however.
This problem resulted from a bug in the JspStub.getClassLoader method. Problem resolved by fixing the bug.
WebLogic Server 6.1 SP04 failed to start if the "Enable Post-Bind UID" option for a Unix Machine was checked. (This attribute can be configured in the Machines node of the Administration Console; its purpose is to return the Unix UID a server instance running a UNIX machine will run under after it has carried out all privileged startup actions).
The problem was corrected with a code fix.
In WebLogic Server 6.1 SP02, hangs occurred frequently because socket reader threads were blocked. The thread that owned the POLL lock was attempting to close an SSL socket, but could not progress because it could not obtain the lock on the output stream required in the sendRecord() method.
Stack trace:
"ExecuteThread: '23' for queue: 'default'" daemon prio=5 tid=0x6d6c40 nid=0x24 waiting for monitor entry [0xe4e81000..0xe4e81a28] at weblogic.security.SSL.SSLSocket.sendRecord(SSLSocket.java:1049) at weblogic.security.SSL.SSLSocket.sendAlert(SSLSocket.java:1007) at weblogic.security.SSL.SSLSocket.close(SSLSocket.java:1153) at weblogic.security.SSL.SSLSocket.close(SSLSocket.java:1141) at weblogic.socket.SocketMuxer.closeSocket(SocketMuxer.java:236
A code fix was implemented to ensure that SSL sockets do not write data to sockets on close for abortive shutdowns.
Thread dumps failed because the JVM_DumpAllStacks symbol had not been globally declared for Hotspot client and Version 1.3.1_x virtual machines.
Thread dumps using weblogic.Admin are now possible with 1.3.1_X hotspot client/server JVMs.
An EmptyStackException was thrown by a Managed Server when the Controller servlet was being deployed.
The following error is thrown by a managed server when the Controller servlet is being deployed:
[WebAppServletContext(35527,btn,/btn)] Servlet failed with Exception> java.util.EmptyStackException at weblogic.utils.
collections.Stack.pop()Ljava.lang.Object;(Unknown Source) at weblogic.kernel.ResettableThreadLocalStack.pop()Ljava.lang.Object;(Unknown Source) at weblogic.jndi.internal.
ThreadEnvironment.pop()Lweblogic.jndi.Environment;(Unknown Source) at weblogic.jndi.internal.WLContextImpl.close()V
(Unknown Source) at weblogic.jndi.factories.java.ReadOnly
ContextWrapper.close()V(Unknown Source) at be.btn.util.
JndiUtil.getEnv(Ljava.lang.String;)Ljava.lang.Object;(Unknown Source) at be.btn.web.HttpControllerServlet.init()V(Unknown Source) at javax.servlet.GenericServlet.init(Ljavax.servlet.
ServletConfig;)V(Unknown Source) at weblogic.servlet.
internal.ServletStubImpl.createServlet()Ljavax.servlet.Serv let;(Unknown Source) at weblogic.servlet.internal.
ServletStubImpl.createInstances()V(Unknown Source) at...The problem was related to the btn.utils.JndiUtils.getEnv() method—it closed the context that it got on lookup—java:com/env—so javaURLContextFactory was not pushing the environment.
Problem resolved.
There was an interoperability issue between WebLogic Server 6.1 SP02 and WebLogic Server 7.0 SP01. An MDB in WebLogic Server 6.1 called an EJB in WebLogic Server7.0. The EJB is timed out and threw a weblogic.transaction.TimedOut
Exception, which is new in WebLogic Server 7.0 and not available in WebLogic Server 6.1. The WebLogic Server 6.1 MDB onMessage() method caught the exception, and threw a ClassNotFoundException when the code Exception.
printStackTrace() was executed.The problem was solved by adding a weblogic.transaction.Timed
OutException class to prevent ClassNotFoundException when interoperating with WebLogic Server 7.0 servers.In WebLogic Server 6.1 SP03 and later, WebLogic Server native libraries on HPUX were not being compiled using cfront, instead of aCC. aCC is the ANSI C compiler which replaced cfront in 1998.
As a result incompatible runtime libraries were loaded(libC.2 from cfront compilation, and libCsup.2 from SUN's Java, compiled with aCC). Incompatible runtime libraries can cause crashes.
The problem was solved by changing WebLogic Server builds to use aCC for hpux11
In WebLogic Server 6.1 SP04,when FailureIsFatal option for a startup class is true and and the startup class fails, WebLogic Server was not shutdown as expected.
The StartupClassRunner is invoked before and after applications are deployed . Analysis revealed that if a startup class failed before application deployment, and was marked failureIsFatal, the fatalException was lost.
The problem was solved by a code fix to ensure that the fatalException is not lost, and the the server instance is shutdown appropriately.
The change associated with "CR092933" which enables thread dump redirection in 1.3.1_x versions of Sun JDK, did not work in NT Services because the stdio handles were invalid.
The problem was resolved by a code change, to create stdio handles in beasvc.
A customer used a custom realm that makes an outbound RMI call. This happens from BootServicesImpl.invoke() from within the RJVM layer on a reader thread. when many such calls are made, reader threads were blocked making outbound calls leaving no threads for reading the response.
The problem was solved by moving BootServices into the RMI layer so that it can dispatch to the default execute queue.
In WebLogic Server 6.1 SP04, under load test, PosixMuxer threw the following exceptions
<Nov 21, 2002 9:38:29 AM EST> <Error> <socket> <000421> <Uncaught Throwable in processSockets java.io.IOException: unexpected exception in poll: (4) Interrupted system call java.io.IOException: unexpected exception in poll: (4) Interrupted system call at weblogic.socket.PosixSocketMuxer.poll(Native Method) at...
The problem was solved with a code change to restart poll if interrupted.
Use of URLClassLoader on the client on a remote method call resulted in a NoClassDefFoundError.
c:\java\java131_07\bin\java -classpath ".;client.jar;C:\home\ravia\weblogic\dev\src700\3rdparty\weblogicaux.jar" URLTest qa146 9901 ejb20-statefulSession- TraderHome installadministrator installadministrator java.lang.NoClassDefFoundError: weblogic/rmi/extensions/server/Stub at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:488) at...
Analysis revealed that when creating AugmentableSystemClassLoader, it was always set to SystemClassLoader. This caused the client to use its system classloader, resulting in the NoClassDefFoundError.
The problem was solved by setting ThreadContextClassLoader as parent for AugmentableSystemClassLoader.
After an upgrade from 6.1 SP02 with cr058358_61sp2.jar to SP03, a degradation in deployment performance occurred on a Managed Server. Degradation was not exhibited on the Administration Server.
The problem was related to the weblogic.j2ee.Component.getModuleMBean() method , which was implemented for CR058358. Because ApplicationDescriptorMBean is only registered in the Administration Server, any requests to that mbean from a Managed Server resulted in RMI calls to the Administration Server.
Problem was solved by building a local cache mbean (ApplicaitonDescriptorMBeanImpl_Cached) on the Managed Server. Now, the first method request goes to the Administration Server to retrieve the information and save locally. Subsequent requests are served locally, and the cache is invalidated when the application is undeployed.
Executing weblogic.refresh on Windows 2000 to update files (JSP or HTML) to WebLogic Server Administration Server and Managed Server running on Linux caused a java.util.zip.ZipException.
The ZIP exception happens when WebLogic Server is configured as an Administration Server or Managed Server and the Web Application for which the weblogic.refresh is done is targeted to the Managed Server.
When the Managed Server tries to get the refreshed files from the Administration Server, exceptions are thrown by both server instances.
Exhibited in this configuration:
Problem diagnosis revealed an error in the file location path for the refreshed file from Managed Server to Administration Server, The problem was corrected by a correction to FileDistributionServlet.doGetMultipleJspRefreshRequest.
In WebLogic Server 6.1 SP04, deployment failed for a web application with a short name, such as like ab.war or i.war. This error occurred:
java.lang.IllegalArgumentException: Prefix string too short at java.io.File.createTempFile(File.java:1232 at weblogic.j2ee.Component.retrieveComponent(Component.java:296 at weblogic.j2ee.Component.<init>(Component.java:188)at weblogic.j2ee.WebAppComponent.<init>(WebAppComponent.java:45at weblogic.j2ee.Application.addComponent(Application.
java:149)at weblogic.j2ee.J2EEService.addDeployment
(J2EEService.java:117)...The bug was corrected.
In WebLogic Server 6.1 SP04, when custom InitialContextFactory was set to weblogic.jndi.Environment, getInitialContext() instead used DEFAULT_INITIAL_CONTEXT_FACTORY .
The problem was corrected by a code fix to ensure that the weblogic.jndi.Environment object considers InitialContextFactory, if specified.
WebLogic Server EJB did not provide the ability to write a finder method on a byte [] field. This was non-compliant with the J2EE EJB-QL definition: "The allowable types in EJB QL are the abstract schema types of entity beans and dependent objects, the defined types of cmp-fields, and the entity object types of remote entity beans." This problem was identified in WebLogic Server 6.1 SP01. This error occurred at build time:
ejbc:
[java]
[java] ERROR: Error from ejbc: Error while reading 'META-INF/weblogic-cmp-rdbms-jar.xml'. The error was:
[java]
[java] invalid query: In EJB containerManaged, for a query defined in the ejb-jar.xml file with a method signature, findFk(byte[]), we failed to find a corresponding method in the remote home interface, local home interface, or bean class that matches this signature. Note that class parameters such as java.lang.String must be fully qualified, thus 'String' would not match 'java.lang.String'.[java]
This problem has been fixed. WebLogic Server EJB now supports finder methods on a byte [] field.
In WebLogic Server 6.1 SP02, the following error was thrown when the EJB Container tried to verify the existence of database tables and columns that did not exist:
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Table: Cmp_Birthday Full Table Check failed, but table all columns were found! ] at weblogic.ejb20.utils.TableVerifier.verifyTableAndColumnsExist(TableVe rifier.java:371) at weblogic.ejb20.utils.TableVerifier.verifyTableExistsAndCreateMaybe(Ta bleVerifier.java:391)
The problem was solved with a code fix.
When hot deploying an EJB, compilation errors were not helpful. For instance:
<30 avr. 02 11:03:14 BST> <Error> <Management> <Error deploying application.\config\mydomain\applications\ldapprofile.jar:java.lang.reflect.UndeclaredThrowableException>
Error reporting is now improved for hot-deployed EJBs. Now, run-time exceptions and errors are reported similarly to the method used in standalone ejbc. The server log and stdout will provide information to help the user understand the failure. For instance:
<Oct 1, 2002 4:37:18 PM PDT> <Error> <J2EE> <Error deploying application ldapprofile: Unable to deploy EJB: ldapprofile.jar from ldapprofile.jar: java.lang.NoClassDefFoundError: com/bea/p13n/property/EntityPropertyManager at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:486) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at weblogic.utils.classloaders.GenericClass
Loader.findLocalClass(GenericClassLoader.java:394) at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:157) at java.lang.ClassLoader.loadClass(ClassLoader.java:297) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at............In 6.1 SP03, using a cmp-ejb with cmr-fields only generated incorrect SQL insert statements. This problem was exhibited with MS-SQL Server 2000 with Automatic-Primary-Key-Generation-TPYE : SQL_SERVER. The Container Generated SQL-Statement:
Insert into tblLicence(, 5 , 7) values (,licCompID,licOrgID)
where compID and orgID are foreign keys in the table which corresponds to this entity bean. After adding an cmp-field, the unmodified (empty) ejbCreate-Method generates the correct SQL:
Insert into tblLicence(licArchivNR,licCompID,licOrgID)values (null , 5 , 7)
The problem has been resolved, the container no longer generates an incorrect SQL Insert statement when the bean has only (pk) field and cmr fields.
In 6.1 SP03, deploying a version 5.1 EJB jar using the Administration Console resulted in a ProcessorFactoryException:
Unable to deploy EJB: TxRolledbackExceptionBean.jar from TxRolledbackExceptionBean.jar:
The XML parser encountered an error in your deployment descriptor. Please ensure that your DOCTYPE is correct. You may wish to compare your deployment descriptors with the WebLogic Server examples to ensure the format is correct. The error was:
weblogic.xml.process.ProcessorFactoryException: The public id, "-//BEA Systems, Inc.//DTD WebLogic 5.1.0 EJB//EN ", specified in the XML document is invalid. Use one of the following valid public ids:
"-//BEA Systems, Inc.//DTD WebLogic 5.1.0 EJB//EN"
"-//BEA Systems, Inc.//DTD WebLogic 6.0.0 EJB//EN"
This problem occurred because WebLogic Server 5.1 supported white space in the DTD declaration for deployment descriptors.
The problem was solved by a code change to trim the extra spaces in the key string before searching for the parser in the hash table with this key.
For a stateless session bean, when the weblogic-ejb-jar.xml contains:
<stateless-bean-is-clusterable>False</stateless-bean-is-clusterable>
and the bean was deployed on a cluster, this error was generated:
<Mar 14, 2003 3:35:00 PM PST> <Error> <Cluster> <Conflict start: You tried to bind an object under the name ejb20-statelessSession-TraderHome_EO in the JNDI tree. The object you have bound from 172.17.24.112 is non clusterable and you have tried to bind more than once from two or more servers. Such objects can only deployed from one server.>
This problem was resolved by a code fix to ensure that JNDI bindings for non-clustered stubs are note replicated.
In WebLogic Server 6.1 SP03, the EJB container breaks the EJB2.0 contract: "Tx not set to rollback when using BMT and exception is thrown".
Problem was exhibited with an MDB with BMT where the onMessage method throws an exception. The container did not handle the exception in accordance with the EJB2.0 specifications (Section 18.3.2 Table 18.) The container should log the exception (done) delete the bean instance (done), and mark the transaction for rollback (NOT done). As a result a transaction remained associated with the thread.
A code fix was implemented to resolve this problem.
WebLogic Server 6.1:SP03: [EJB] : When calling context.getCallerPrincipal() from ejbStore() using UserTransaction context, the following exception is thrown:
<Oct 24, 2002 5:52:24 AM PDT> <Info> <EJB> <Exception from ejbStore:javax.ejb.EJBException: ejbStore: nulljavax.ejb.
EJBException: ejbStore: null at AccountBean.ejbStore(Account
Bean.java:99)atAccountBean_t4qrab_Impl.ejbStore
(AccountBean_t4qrab_Impl.java:131)at weblogic.ejb20.manager.
DBManager.storeBean(DBManager.java:266) at weblogic.ejb20.
manager.DBManager.beforeCompletion(DBManager.java:397) at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManager.java:494) at weblogic.transaction.internal.
ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:551) at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:88)at weblogic.transaction.
internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:979)at weblogic.transaction.
internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1503) at weblogic.transaction.internal.
ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:215) at weblogic.transaction.internal.Server
TransactionImpl.commit(ServerTransactionImpl.java:189)at weblogic.transaction.internal.CoordinatorImpl.commit(CoordinatorImpl.java:68) at weblogic.transaction.internal.
CoordinatorImpl_WLSkel.invoke(Unknown Source)at weblogic.rmi.
internal.BasicServerRef.invoke(BasicServerRef.java:305)at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274) at weblogic.rmi.internal.BasicExecute
Request.execute(BasicExecuteRequest.java:22) atweblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(Execute
Thread.java:120)><Oct 24, 2002 5:54:53 AM PDT> <Info> <Management> <Configuration changes for domain saved to the repository.>This problem was a result of changes introduced in SP03 to comply with section 21.2.5.1 of the EJB specification. The problem was corrected.
In SP03, BEA tests of ejb20.locks.ExclusiveLockManager indicated a memory leak. The memory leak appears as a result of deploying and undeploying.Analysis revealed that the timer/trigger in DiskSwap was not cancelled when an EJB was undeployed, leaving a reference in TimeGenerator, and that ExclusiveLockManager buckets were not being garbage collected.
Problem was solved by code fix to cancel the time/trigger appropriately and ensure proper garbage collection.
The default pool-size for MDBs was larger than the thread pool size default, resulting in MDB instances consuming the entire default thread pool and blocking waiting for non-MDB work to complete—leaving no threads left to do the unblocking work.
Problem was resolved by, when an MDB is assigned to the main thread pool, limiting MDB pool size to a percentage of ((thread pool size) - (socket reader threads)).
The Administration Console reported incorrect value for the number of waiters for Entity beans. After clients had timed out, the console reported that there were waiters.
The problem was resolved by by a correction to ExclusiveLockManager to decrement the waiterTotalCount when it is done waiting.
In SP03, JMSConnectionPoller did not close its initial contexts. When an MDB used external InitialContextFactory for lookups and the JMS provider was not accessible, the connections and other resources accumulated rapidly.
The problem was corrected with a code fix to close the context when it is done for active memory clean up.
In SP03, under heavy loads, an MDB threw an IllegalStateException when resuming a transaction after invoking a business method; the JVM crashes when the transaction is being resumed.
This behavior was exhibited with these application characteristics: a client sends messages to a Queue and an MDB listens on it. The tx.attribute for this MDB is "Required". The create method of the MDB is doing a home.create for creating some BMT SLSBs and the onMessage method is invoking the business method for this SLSB. The business method of this SLSB is sends messages to two different queues.
The following error was observed:
<EJB Exception during invocation from home: com.gfs.corp.batch.cost.costupdate.ejb.NextOrderCostUpdateProcessorEJB_xtvwzj_LocalHomeImpl@54b120 threw exception: java.lang.StackOverflowError> java.lang.StackOverflowError <<no stack trace available>>
The local interface was not handing exceptions properly.
The problem was solved by a code fix to correct the error handling so that the container properly rolls back the transaction when exception occurs.
In SP04, runtime monitoring of the entity beans in reported an incorrect value for the use the cached beans current count—the value exceeded the max beans in cache specified in the deployment descriptor and also the cached beans current count.
The value reported was incorrect, and new beans were being created inappropriately.
A code correction was made to release beans to the pool after removal from cache.
The idle-timeout-seconds element in weblogic-ejb-jar.xml determines how long the EJB container waits before passivating stateful session beans, that is, removing them from cache and writing them to disk. The EJB container also used to use this element to determine how long to wait before removing passivated EJBs from the disk. Some users wanted stateful session beans to remain on disk longer than idle-timeout-seconds. In other words, they want to specify how long stateful session beans stay idle in the cache and how long they stay idle on disk using two different elements.
A new element has been added, session-timeout-seconds, which specifies how long the EJB container waits before removing an idle stateful session bean from disk.
In WebLogic Server 6.1 SP03 and SP04, read-only EJBs with a many:one container-managed relationship CMR caused a LockTimedOutException.
avant getCustomerVO.getCountryVO() [ExclusiveLockManager$Lock
Bucket] : ** LOCK ACQUIRE --> WAITING -- ejb-name: Country primary key: 002 lockClient: Name=[EJB charu.ejbrelations
final.CountryBean.getCountryVO()],Xid=11:1d0d46b2(3053175),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=30,activeThread=Thread
[ExecuteThread: '2' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[mydomain+myserver]=(state=
active),properties=({weblogic.transaction.name=[EJB charu.ejbrelationsfinal.CountryBean.getCountryVO()], LOCAL_ENTITY_TX=true}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=myserver+172.23.135.56:7011+mydomain+, Resources={})]) wait (MS): 30000 [ExclusiveLockManager$LockBucket] : ** LOCK TIME OUT AFTER WAITING -- ejb-name: Country primary key: 002 lockClient: Name=[EJB charu.ejbrelationsfinal.CountryBean.get
CountryVO()],Xid=11:1d0d46b2(3053175),Status=Marked rollback. [Reason=weblogic.transaction.internal.TimedOut
Exception: Transaction timed out after 29 seconds Name=[EJB charu.ejbrelationsfinal.CountryBean.getCountryVO()],Xid=11:1d0d46b2(3053175),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=29,seconds left=30,active
Thread=Thread[ExecuteThread: '2' for queue:'default',5,Thread Group for Queue: 'default'],SCInfo[mydomain+myserver]=
(state=active),properties=({weblogic.transaction.name=[EJB charu.ejbrelationsfinal.CountryBean.getCountryVO()], LOCAL_ENTITY_TX=true}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=myserver+172.23.135.56:7011+mydomain+, Resources={})])],numRepliesOwedMe=0,
numRepliesOwedOthers=0,seconds since begin=30,seconds left=10,activeThread=Thread[ExecuteThread: '2' for queue: 'default',5,Thread Group for Queue:'default'],SCInfo [mydomain+ myserver]=(state=active),properties=({weblogic. transaction.name=[EJB charu.ejbrelationsfinal.CountryBean. getCountryVO()], LOCAL_ENTITY_TX=true}),OwnerTransaction Manager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=myserver+172.23.135.56:7011+mydomain+, Resources={})]) wait (MS): 30000The problem was resolved by modifying the if condition check from rbd.isReadOnly() to READONLY_EXCLUSIVE_CONCURRENCY check.
When attempting to deploy two message-driven beans with the same ejb-name but different JNDI mappings on the same Weblogic Server instance, the first bean was deployed successfully, but the deployment of the second bean failed with this exception:
weblogic.management.ManagementException: - with nested exception:
[javax.management.InstanceAlreadyExistsException:
jpdomain:Location=jpserver,Name=MessageQueueHandlerBean,ServerRuntime=jpserver,Type=EJBMessageDrivenRuntime] at
weblogic.management.runtime.RuntimeMBeanDelegate.register(RuntimeMBeanDelegate.java:96) at
weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:83) at
weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:53) at
weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:63) at
weblogic.ejb20.deployer.MessageDrivenRuntimeMBean.<init>(MessageDrivenRuntimeMBean.java:18) at
weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.deploy(MessageDrivenBeanInfoImpl.java:450) at
weblogic.ejb20.deployer.Deployer.deployDescriptor(Deployer.java:1299) at
weblogic.ejb20.deployer.Deployer.deploy(Deployer.java:1005)
The problem was due to non-unique MessageDrivenRuntimeMBean names. The problem was solved by code change to ensure creation of unique names. .
In 6.1 SP04, <is-modified-method-name> was not called on CMP 2.0 beans. ejbStore was called at every bean method invocation and WebLogic Server determined afterwards if the store is to avoid. This caused performance issues in applications that frequently used <is-modified-method-name>.
The problem was solved by implementing the <is-modified-method-name> function for CMP EJB 2.0.
The ejbc compiler failed with the following error when a two-dimensional array was specified as an argument:
Unable to set the method permission for method "isAuthorized(java.lang.String,[[java.lang.String)". No matching method could be found. Please verify the method signature specified in the ejb-jar.xml file matches that of your EJB. ERROR:ejbc found errors.
The problem was solved by modifying the makeMethodParameter() method of the eblogic.ejb20.deployer.mbimpl.MethodDescriptorImpl class to generate the appropriate method parameter signature depending on the dimension of the array passed.
When a UserTransaction.commit failed in MDListener, subsequent invocations of the MDB from JMS failed in UserTransaction.begin because there was already a transaction on the thread. This series of events occurred:
This problem was solved with a code change to make MDListener suspend the current transaction before starting a new one in the event that an unexpected exception prevented the prior transaction from completing.
It was reported that jsp:setProperty parameter conversions failed.
When the jsp:setProperty action sets the values of properties in a bean, the parameters are converted per JSP.2.13.2.1 using the target property to determine the target type. The jsp file with the jsp:setProperty action fails to compile with the error messages below:
... setCount(int) in weblogic.qa.xmlbasedtests.webapp_jsp_tests.FooBean cannot be applied to (java.lang.String) ... setBool(boolean) in weblogic.qa.xmlbasedtests.webapp_jsp_tests.FooBean cannot be applied to (java.lang.String) ... setmyDouble(double) in weblogic.qa.xmlbasedtests.webapp_jsp_tests.FooBean cannot be applied to (java.lang.String) ... setFloat(float) in weblogic.qa.xmlbasedtests.webapp_jsp_tests.FooBean cannot be applied to (java.lang.String) ... setmyLong(long) in weblogic.qa.xmlbasedtests.webapp_jsp_tests.FooBean cannot be applied to (java.lang.String)
This behavior was the result of the changes associated with "CR098402". (Fixed a problem with jsp:setProperty, request-time expression in the property value was converted to String. When assigning from a value given as a request-time attribute, no type conversions are applied.)
Investigation revealed that the specification says:
"When assigning from a value given as a request-time attribute, no type conversions are applied, as indicated in Section JSP.2.13.2.3."
The code was determined to be functioning in accordance with the specification, and no changes were required to close this CR.
The WebLogic Server 6.1 SP04 upgrade installer build did not include latest beasvc.exe. For related CRs, see See CR091420, and 091420.
The SP05 upgrade installer does not exhibit this problem.
When a user transaction failed to rollback because Oracle database was down, the JDBC connections used in the transaction were not released, resulting in connection pool depletion.
This problem was exhibited under WebLogic Server 6.1 SP02, Oracle8.1.6, 8.1.7 jDriver for Oracle, and Oracle thin driver.
Analysis revealed that the internalrollback method in the JTS connection was not calling the internalclose() method, so if the rollback failed the connection leaked.
A code fix solved the problem.
In WebLogic Server 6.1 SP03, weblogic.Admin RESET_POOL did not re-initialize connections to not-reserved.
After using weblogic.Admin RESET_POOL, the log indicated that all connections were refreshed, but if they were reserved before the reset, they are still reserved after the reset.
The problem was solved with a code change to put reserved resource back on resourcesFree list and clear the associated flag.
In previous releases of WebLogic Server, if application code created JDBC objects that were abandoned without being closed, the objects would be lost but would still hold memory or open cursors, even after being garbage collected. If too many such objects were created, the server would eventually run out of memory and the database may run out of cursors.
In WebLogic Server 6.1SP5, the code was changed so that abandoned JDBC objects are closed before being garbage collected.
Note: If you immediately create a JDBC object that is identical to an abandoned object, WebLogic Server creates a clone of the original JDBC object. However, when the original leaked object is closed, the clone will also be affected.
You can avoid abandoning JDBC objects by following the best practices described in "Closing JDBC Objects" in Programming WebLogic JDBC.A StringIndexOutOfBoundsException occurred in the OCI driver. The problem occurred occasionally in multiple queries when running a CMP entity bean, always when dealing with an integral at or near (depending on the precision of the number in the database) weblogic.jdbc.pool.ResultSet.getLong(ResultSet.
java:107)The full exception is:java.sql.SQLException: java.lang.StringIndex
OutOfBoundsException - String index out of range: 0Analysis revealed that in weblogic.db.oci.OciCurser.getValue
(OciColumn,int,int,boolean,boolean), the methods new Long(string) and new BigInteger(string)' were being called without appropriate checks, resulting in the StringIndexOutOfBoundsException.A code fix solved the problem.
In WebLogic Server 6.1 SP03, connection pool reset methods were unnecessarily synchronized. The ResourceAllocator method resetThisOne()was synchronized. As a result, when all execute threads performed a testConnOnReserve, and replaced a dead connection, they queued up, instead of establishing connections in parallel.
A code fix solved the problem.
In WebLogic Server 6.1 SP04, with Oracle Thin XA with the CLASSES12.zip from Oracle 9.2, a stateless session bean calling EJB caused XAER_PROTO after "Configuration Changes saved to the repository" message appeared.
START SLEEP 2: After updating thevalue to 1...
DONE SLEEP 2: After updating thevalue to 1...
START SLEEP 2: After updating thevalue to 2...
DONE SLEEP 2: After updating thevalue to 2...
START SLEEP 2: After updating thevalue to 3...
DONE SLEEP 2: After updating thevalue to 3...
START SLEEP 2: After updating thevalue to 4...
DONE SLEEP 2: After updating thevalue to 4...
START SLEEP 2: After updating thevalue to 5...
DONE SLEEP 2: After updating thevalue to 5... Current value is 5 <
Dec 6, 2002 10:26:59 PM MST> <Info> <Management> <Configuration changes for domain saved to the repository.> SQLException -- XA error: XAER_PROTO : Routine was invoked in an improper context start() failed on resource 'OracleXA' null Current value is 0
The problem caused by a known problem in Oracle client 9.2.0.[01], that is solved in 9.2.0.2. A code change to in WebLogic Server was implemented to work-around the 9.2.0.[01] issue.
In WebLogic Server 6.1 (any SP), it was not possible to use specific Oracle objects (Array, Struct, ...) through a connection pool based on the Oracle Thin Driver. The objects returned by the Oracle thin driver were not serializable nor remote and therefore could not be passed over RMI.
A new package has been introduced : weblogic.jdbc.vendor.oracle that contains "proxies" for these objects and allow them to be passed through the connection pool.
After calling JDBCConnectionPoolRuntimeMBean.resetStatement
Profile, it was not possible to display SQL traces. Calling resetStatement
Profile()cleared the trace file, but it was not possible to do traces, even after tracing was enabled with the JdbcSqlTraceAdmin tool. It was necessary to restart the server instance to re-enable tracing.A code fix solved the problem.
A deadlock occurred between "Finalizer" and weblogic/jdbc/jta/Statement.
java.The problem was exhibited under Solaris 5.8 - WebLogic Server 6.1SP3 - java v1.3.1_03 (build 1.3.1_03-b03), Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode). This error occurred:
"ExecuteThread: '5' for queue: 'default'": waiting to lock monitor 0xe1ba8 (object 0xf1327fb0, a java.util.HashSet), which is locked by "Finalizer" "Finalizer": waiting to lock monitor 0xe1b70 (object 0xf1327fe8, a weblogic.jdbc.jta.
ResultSet), which is locked by "ExecuteThread: '5' for queue: 'default'"The problem occurred on a server instance that runs a web application that queries and updates an Oracle database. The code where the deadlock was encountered was part of a common user management interface that gathers user information when the user is logging in. It uses the oracle.jdbc.xa.client.OracleXADataSource from a connection pool configured in WebLogic Server.
Analysis revealed that connection tests were synchronized, causing waits to obtain a lock, even when none was available.
A code fix solved the problem.
Under WebLogic Server 6.1, an error code was not returned correctly when a client tried to get a connection to an unavailable database using Oracle Thin Driver.
Analysis revealed that weblogic.jdbc.common.internal.ConnectionEnv
Factory swallowed the error code.A code fix solved the problem.
When a non-zero starting index was passed to the getStatementProfiles() method, the traces returned start from the top of the .tsf file, instead at the specified starting index.
A code fix solved the problem.
In WebLogic Server 6.1 SP04, the the value returned by the JDBCStatement
Profile.getTimeTaken() method in the JDBCStatementProfile interface was always zero.A code fix to weblogic/jdbc/common/internal/ProfileStorage.java solved the problem.
weblogic.jdbc.rmi.internal.ConnectionImpl lacked connection leak profiling and connection leak detection logic.
Three events can trigger the release of a connection back to the pool.
The first two events should trigger a warning to the user to that there is a potential connection leak.
This logic was added to SerialConnection.java and ConnectionImpl.java.
Weblogic Server 6.1 SP04 did not throw an ORA-00020 message to the log when a connection pool failed to create with the given initial capacity due to not having sufficient number of processes (max_processes) for the database.
The problem was solved by a code change to log the message.
Under load conditions, when WebLogic Server was calling ResourceAllocator.markBorrowed() and JMX was calling ConnectionPoolRuntimeMBeanImpl.getConnectionDelayTime(), a deadlock condition resulted.
A code fix to ResourceAllocator.java solved the problem.
Weblogic Server 6.1 SP04 thin driver, Solaris 8, JDK 1.3.1_04, and Oracle 8.1.7.4., deadlocks occurred when connection refresh is turned on.
Customer stack trace:
"ExecuteThread: '35' for queue: 'default'" daemon prio=5 tid=0x45ac68 nid=0x30 waiting for monitor entry [0xce901000..0xce9019d8] at weblogic.jdbc.common.internal.ConnectionEnv.destroy(ConnectionEnv.java:571) at weblogic.common.internal.ResourceAllocator
Both the weblogic.jdbc.common.internal.ConnectionEnv.destroy and weblogic.common.internal.ResourceAllocator.release are synchronized methods ().
The problem was solved with a code fix to weblogic/jdbc/common/internal/ConnectionEnv.java.
In WebLogic Server 6.1 SP04, under load testing, a connection pool with the refresh minutes set to 15, and TestConnsOnReserve and TestConnsOnRelease set to false threw the following exception:
weblogic.common.ResourceException: No available connections in pool ODSConnectionPool
This problem occurred because when only a few of the connections in the pool are used, all the other connections in the pool are reserved for testing at the expiration of the refresh test minutes. At that point, if client asked for a connection the exception was thrown.
The problem was resolved with a code fix that implements two things:
In WebLogic Server 6.1 SP04, when the incorrect password is set in the connection pool properties, the following exception is thrown:
<Mar 13, 2003 10:35:45 AM IST> <Info> <JDBC> <Sleeping in createResource()> <Mar 13, 2003 10:35:46 AM IST> <Info> <JDBC Pool DemPool> <Pool DemPool is created with initial capacity 0> In the earlier versions of WLS. The exception was more descriptive. The following exception is thrown when the incorrect password is specified in sp 3. <Mar 12, 2003 9:41:38 AM IST> <Error> <JDBC> <Cannot startup connection pool "Dpool" weblogic.common.ResourceException: Could not create pool connection. The DBMS driver exception was: java.sql.SQLException: ORA-01017: invalid username/password; logon denied
The problem was resolved with a modification to weblogic/common/internal/ResourceAllocator.java.
Calling getTimeStamp(), getTime(), getDate() or getJavaDate() on weblogic.db.oci.OciCursor with a null Calendar object, resulted in creation of a new calendar.
To improve performance, now a single calendar is created and stored in the cursor the first time one of these methods is called.
Using a XADataSource on top of jDriver resulted in shrinking heap size until OutOfMemoryError was encountered.
In the weblogic.jdbc.oci.Connection class, LOB fields of result sets in a transaction are registered under a connection through the Connection.addLob() method. The registered LOBs are freed (along with the corresponding object in native jDriver library) when one of these conditions occurs:
When an XADataSource is being used, none of the above conditions apply. As a result, LOB fields of jDriver in result sets were never released in the JVM heap.
This problem was corrected by a code change in weblogic.jdbc.oci.xa.DataSrcThreadInfo.java to call closelob ().
In WebLogic Server 6.1 SP04 jDriver for Oracle 9.2 does not support the AL32UTF8 character set (unicode version 3.1). When NLS_LANG is set to AMERICAN_AMERICA.AL32UTF8, the following error is generated by weblogic.jdbc.oci.Connection.<init>(Connection.java:246):
java.sql.SQLException: Unsupported Oracle codeset: al32utf8. Set weblogic.codeset in your connection Properties to a valid JDK codeset which is compatible with the Oracle codeset defined in your NLS_LANG setting.
When NLS_LANG=AMERICAN_AMERICA.UTF8, this error occurs: ORA-01461: can bind a LONG value only for insert into a LONG column, indicating a mismatch between the character set on the client and database.
This problem was corrected by a code fix to weblogic/db/oci/OciConnection.
In WebLogic Server 6.1 SP03 and SP04, jDriver for Oracle ResultSet#getBigDecimal() method did not return correct value. For example, value of 9999999999.999999 was rounded to 9999999999.999998.
This problem was solved with a code fix.
The "Euro" currency symbol was retrieved as "?" using statement.getString() with WebLogic jDriver for MSSQL Server 2000.
The problem was solved by a code fix to use new String constructor to handle character set correctly
Oracle's SQL DATE type supports date values between 4712 B.C. and 4712 A.D., but jDriver for Oracle can not handle dates '1899-12-31' and before. Such dates that are stored by jDriver cannot be queried by other tools, like Oracle Thin Driver or SQL*Plus. This issue happens only if you use a prepared statement, and bind such date to DATE column using setDate() method.
The problem was solved by a code fix to weblogic/db/oci/OciColumn.java.
In WebLogic Server 6.1 SP02, with jDriver for Oracle, and Oracle 8.1.7, the PreparedStatement for sql UPDATE did not work after using CallableStatement on the same connection. This was a regression of "CR080931".
getUpdateCount() returned zero, and nothing was changed in the database. This occurred when setting the weblogic.oci.min_bind_size property for the jdbc connection.
props.put("weblogic.oci.min_bind_size", "660")
Analysis revealed that jDriver was using min_bind_size=33000 for the statement.
weblogic.jdbc.oci.Connection#prepareCall internally set min_bind_size to 33000.
The problem was solved with a code fix to db\oci\OciConnection.java.
In WebLogic Server 6.1 SP02, the messaging bridge did not work properly with null UserPassword. When a bridge is configured with a non-null UserName and null UserPassword, the bridge failed to start with no clear error messages.
This problem was resolved with a code fix.
In WebLogic Server 6.1 SP03., a JMS Server threw a NullPointerException under heavy loads:
<Aug 2, 2002 65438 PM EDT> <Warning> <JTA> <XA resource [JMS_JMSServer1JDBCStore] has not responded in the last 120 second(s).>
<Aug 2, 2002 65438 PM EDT> <Warning> <JTA> <Resource JMS_JMSServer1JDBCStore was not assigned to any of these servers JMSServer1 >
<Aug 2, 2002 65438 PM EDT> <Warning> <JTA> <Resource JMS_JMSServer1JDBCStore was not assigned to any of these servers JMSServer1 >
<Aug 2, 2002 65438 PM EDT> <Warning> <JTA> <Resource JMS_JMSServer1JDBCStore was not assigned to any of these servers JMSServer1 >
<Aug 2, 2002 65438 PM EDT> <Warning> <JTA> <Resource JMS_JMSServer1JDBCStore was not assigned to any of these servers JMSServer1 >
<Aug 2, 2002 65438 PM EDT> <Warning> <JTA> <Resource JMS_JMSServer1JDBCStore was not assigned to any of these servers JMSServer1 >
<Aug 2, 2002 65438 PM EDT> <Alert> <JMS> <JMSServer "JMSServer1",unhandled exception during rollback, java.lang.NullPointerException.java.lang.NullPointerException at weblogic.jms.backend.BEDurableTopicMessageInfo.rollbackReceiveTran(BEDurableTopicMessageInfo.java352) atweblogic.jms.backend.BEXATranEntrySubscribe.startRollback(BEXATranEntrySubscribe.java145)at weblogic.jms.backend.BEXATranEntry.execute(BEXATranEntry.java127) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java120)
The problem was exhibited in this configuration: 400 execute threads, 200 JMS threads, and 100 connections for the connection pool. Exception occurred under a load test while publishing approximately 10 messages (around 2K) to a durable subscriber every second to the JMS Server. There were no distributed transactions. Sybase driver was used for the connection pool for the JDBCStore.
The problem was solved by a code fix to check prepareStoreRequest before calling rollbackReceiveTran().
In WebLogic Server 6.1 SP02, JMS JDBS store creation on an AS400 machine with DB2 failed.
This problem was solved with a code fix.
A JMS selector performance enhancement has been implemented. The customer use case is publishing a message to a small subset of 20,000 subscribers, where each subscriber has a unique identifier. This was CPU-intensive, as it was necessary to evaluate the selector of every subscriber to determine which subset matches.
To improve performance under such circumstances, a limited subscriber index capability was added to JMS. With this enhancement, each subscriber informs JMS of its "uniqueness" in a way that JMS knows it can index the subscriber. The uniqueness is specified by using a JMS selector of the form:
xxxxx IS NOT NULL
Where xxxxx is an arbitrary identifier that is not a known JMS message attribute, and where multiple subscribers may specify the same value for "xxxxx". This is standard JMS syntax. WebLogic JMS sees this selector as an indication that it can optimize by indexing the subscriber.
When a message is published to a topic which has indexed subscribers, JMS now iterates over each of the message's user properties and passes the message to those indexed subscribers that match the user property name. JMS will also continue old behavior when a message is published, as it will continue to also iterate over unindexed subscribers (those with selectors that don't match the special pattern above).
In WebLogic Server SP02, a JMSException occurred when unsubscribing the Durable subscriber:
weblogic.jms.common.JMSException: Subscription clientID.vIJAY in use, uncommitted/unacknowledged messages at weblogic.jms.backend.BEConsumer.delete(BEConsumer.java:1784) at weblogic.jms.backend.BEManager.removeSubscription(BEManager.java:204) at weblogic.jms.backend.BEManager.invoke(BEManager.java:216) at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:510) at weblogic.jms.dispatcher.DispatcherImpl.dispatchAsync (DispatcherImpl.java:149) at weblogic.jms.dispatcher.Request.dispatchAsync(Request.java:734) at weblogic.jms.frontend.FEManager.removeSubscription(FEManager.java:288) at weblogic.jms.frontend.FEManager.invoke(FEManager.java:320) at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:510) at weblogic.jms.dispatcher.DispatcherImpl.dispatchAsync (DispatcherImpl.java:149) at weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncFuture
(DispatcherImpl.java:300) at weblogic.jms.dispatcher.DispatcherImpl_WLSkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:298) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:267) at weblogic.rmi.internal.BasicExecuteRequest.execute (BasicExecuteRequest.java:22) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
Analysis revealed that WebLogic Server was incrementing the unack'ed message count twice for every message and decrementing it only once. This always left the unack'ed messagecount > 0 and thus the exception when we try to unsubscribe the durable subscriber.
This problem was solved with a code fix.
In WebLogic Server SP03, retry values (min, max and increment) do not work correctly for MessagingBridge. The problem occurred with a MessagingBridge configured to send messages from one WebLogic Server JMS server to another. All run on the same WebLogic Server instance. Untargeting one of the JMS resulted in this error:
<30-Oct-02 15:13:34 GMT> <Error> <Connector> <Error granting connection request.>
Retry attempts should occur at intervals controlled by the Connection Retry parameters. However, with the following startup default values: min=15, max=60, inc=5. The observed behavior was:
<30-Oct-02 15:13:09 GMT> <Error> <Connector> <Error granting connection request.>
<30-Oct-02 15:13:14 GMT> <Error> <Connector> <Error granting connection request.>
<30-Oct-02 15:13:19 GMT> <Error> <Connector> <Error granting connection request.>
<30-Oct-02 15:13:24 GMT> <Error> <Connector> <Error granting connection request.>
<30-Oct-02 15:13:29 GMT> <Error> <Connector> <Error granting connection request.>
After one of the default parameters was changed, increments are correct. However, the max value is never reached. With the default values, the maximum reached is 55.
This problem was solved with a code fix to correct the logic for the retry values.
In WebLogic Server SP04, persistent queue messages received by MDB were not acknowledged properly, causing the Administration Console monitoring function to show "BYTES PENDING". Messages that had been received by the MDB were redelivered when WebLogic Server was shutdown and restarted.
This problem was solved with a code fix MDB acks when the EJB transaction descriptor is NotSupported.
In WebLogic Server SP02, JDBC logging threw a java.sql.SQLException: Connection has already been closed with OracleThinDriver for XA, Windows-NT, JDK 1.3.1,and Oracle 9011. After this error message, nothing got logged in JDBC log file.
This problem was solved with a code fix to prevent JDBC logging errors.
In WebLogic Server SP02 and SP04, when a durable topic subscriber was connected to a JMS server and there is a message sent to the topic, WebLogic Server increased the value of "Bytes Current Count" by message size even though the message had been received and committed by the receiver. The corresponding value of "Messages Current Count" is not affected. When the durable topic subscriber was not connected to a JMS server and there was a message sent to the topic, WebLogic Server increases both "Messages Current Count" and "Bytes Current Count". If the durable topic subscriber is connected back to the JMS server, WebLogic Server decreased both "Messages Current Count" and "Bytes Current Count" correspondingly. As a result of this inconsistency, the value "Bytes Current Count" cannot be zero even though there is no outstanding message for the durable topic subscriber.
Analysis revealed that in backend/BEConsumer.java addMessages(), bytesCurrentCount was updated inappropriately, resulting in display of incorrect statistics in the Administration Console.
The problem was solved with a code fix.
In WebLogic Server SP04, after the maximum idle time out for the messaging bridge, the messages shown below are written to the server log file. If many messaging bridges are configured, the log file grows quickly to a large size.
####<Dec 19, 2002 12:44:42 PM EST> <Info> <MessagingBridge> <dws-stage> <DwsStageServer> <ExecuteThread: '3' for queue: 'MessagingBridge'> <> <> <200027> <Bridge "DWSBackend Inbound Bridge" works in asynchronous mode and has not received messages for the predefined maximum idle time. The connections to the adapters will be interrupted and re-established.>
####<Dec 19, 2002 12:44:42 PM EST> <Info> <MessaginBgridge> <dws-stage> <DwsStageServer> <ExecuteThread: '3' for queue: 'MessagingBridge'> <> <> <200020> <Bridge "DWSBackend Inbound Bridge" is stopped.> ####<Dec 19, 2002 12:44:42 PM EST> <Info> <MessagingBridge> <dws-stage> <DwsStageServer> <ExecuteThread: '3' for queue: 'MessagingBridge'> <> <> <200033> <Bridge "DWSBackend Inbound Bridge" is getting the connections to the two adapters.> ####<Dec 19, 2002 12:44:42 PM EST> <Info> <MessagingBridge> <dws-stage> <DwsStageServer> <ExecuteThread: '3' for queue: 'MessagingBridge'> <> <> <200032> <Bridge "DWSBackend Inbound Bridge" is configured not to allow degradation of its quality of service in cases where the configured quality of service is not reachable.>
####<Dec 19, 2002 12:44:42 PM EST> <Info> <MessagingBridge> <dws-stage> <DwsStageServer> <ExecuteThread: '3' for queue: 'MessagingBridge'> <> <> <200030> <Bridge "DWSBackend Inbound Bridge" is configured to work in "Exactly-once" mode and it is actually working in "Exactly-once" mode.> ####<Dec 19, 2002 12:44:42 PM EST> <Info> <MessagingBridge> <dws-stage> <DwsStageServer> <ExecuteThread: '3' for queue: 'MessagingBridge'> <> <> <200028> <Bridge "DWSBackend Inbound Bridge" starts transferring messages.>
This problem was resolved by providing the ability to hide the log messages with DebugMessagingBridgeRuntime debug flag.
JMS messages were lost. A JMS Server had an inbound and an outbound queue. An MDB located on another server consumed messages from the inbound queue and produced messages to the outbound queue in a one-for-one relationship. This was done within a transaction initiated by the MDB. The end of the transaction is when the MDB enqueued a message on the outbound queue. If the JMS Server was killed and restarted, messages were lost. Over a load of 10,000 messages, a small number of messages were lost.
The problem was solved by a code change to force transacted XAConnection to CLIENT_ACK.
During tests, a JMS client session that never committed or acknowledged leaked memory. The test used startup classes that act as Asynchronous receivers for both queues and topics. The receiver was created using a transacted session and AUTO-ACKNOWLEDGE mode. On receipt of messages, the receiver did a Rollback on the session. Diagnostics revealed a memory leak in weblogic.jms.client.JMSSession$UnackedMessage.
The problem was solved with a code fix to weblogic/jms/client/JMSSession.java.
In WebLogic Server 6.1 SP03, in a two node cluster running under Solaris, failover of a stateless session bean was delayed by about five minutes. The server froze and the client hung.
The time to failover was reduced to 45 seconds with multiple code and configuration changes:
The stack trace is
javax.ejb.FinderException: Problem in findByNameEquals while preparing or executing statement: 'weblogic.jdbc.jts.PreparedStatement@55c5eb': java.sql.SQLException: ORA-00911: invalid character java.sql.SQLException: ORA-00911: invalid character at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134) at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289) at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:573) at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol...
THe problem was corrected with a code fix to generate the correct SQL query
In WebLogic Server SP03, ejbc failed while compiling stubs and skeletons for a .jar with 100 EJBs . The following exception occurred:
java.io.IOException: CreateProcess: c:\VisualCafe\bin\sj.exe -classpath c:\java\java130\jre\lib\rt.jar;
c:\java\java130\jre\lib\i18n.jar;c:\java\java130\jre\lib\sunrsasign.jar;c:\java\java130\jre\classes;
c:/java/java130/lib/tools.jar;D:/weblogic/dev/src/3rdparty/jconnect/jConnect.jar;D:/weblogic/src_130sj/license;D:/weblogic/dev/src/3rdparty/oracle/816/classes12.zip;
D:/weblogic/src_130sj/classes;D:/weblogic/src_130sj/lib/xmlx.jar;D:/weblogic/src_130sj/lib/ejb20.jar;D:/weblogic
/dev/src/3rdparty/weblogicaux.jar;D:/weblogic/dev/src/3rdparty/cloudscape/lib/cloudscape.jar;D:/weblogic/src_130sj/classes_ifmx4;
D:/weblogic/src_130sj/classes_mssql4;D:/weblogic/src_130sj/tools;c:/java/java130/jre/lib/rt.jar;D:\raviWork\ejb...The problem was a result of a compiler command line length limitation. It was solved by using the javac @tempfile feature, which allows file names to passed to the compiler using a temporary file.
In WebLogic Server 6.1 SP04, the Administration Console reported incorrect values for waiters for entity beans.
The problem was solved by adding a waiterCurrentCount attribute that is incremented when a client starts waiting for a lock and decremented when the lock is acquired or the client times out.
It was reported in WebLogic Server 6.1 SP03 that transaction timeouts on MDBs were not logged. When the time an MDB takes to process a message from a JMS Destination exceeds the transaction timeout limit, the transaction is rolled-back and the message is place backed on the destination for re-delivery, but no transaction-timeout or transaction-rollback messages were logged.
This problem was resolved by a code change to the MDListener code to report the transaction timeouts.
In WebLogic Server 6.1 SP02, a web application failed to obtain a remote object from a session under the following circumstances:
<Apr 21, 2003 11:42:47 AM PDT> <Error> <HTTP Session> <Error reconstructing the EJBObject put into session for name: trader java.rmi.NoSuchObjectException: Unable to locate EJBHome: 'statelessSession.TraderHome' on server: 't3://acaoclust:7001 at weblogic.ejb20.internal.HomeHandleImpl.getEJBHome(HomeHandleImpl.java :80) at weblogic.ejb20.internal.HandleImpl.getEJBObject(HandleImpl.java:179) at weblogic.servlet.internal.session.SessionData.getAttribute(SessionDat a.java:390) at jsp_servlet.__remoteejb._jspService(__remoteejb.java:119) at weblogic.servlet.jsp.JspBase.service(JspBase.java:27) at
The error occurred because the web application used the cluster URL to get the remote EJB object from the HttpSession, although EJB was deployed to a single Managed Server, not to the cluster.
A code fix solved the problem. Now the EJB Handle (HomeHandle) uses the URL of the server to which the EJB is deployed, if the EJB home is not clusterable, as specified in the EJB's home-is-clusterable deployment element in the weblogic-ejb-jar.xml file. The cluster URL is used only when home-is-clusterable is true.
In WebLogic Server 6.1 SP04, server-side ejbc compilation errors resulted when the classpath was long. This error resulted:
[EJBCompiler] : Compiling EJB sources Warning: UNIXProcess.forkAndExec native error: The parameter or environment lists are too long. <Apr 24, 2003 2:55:27 PM GMT> <Error> <J2EE> <Error deploying application applicationname: Unable to deploy EJB: monitor/EMAServerManager.jar from monitor/EMAServerManager.jar: Compiler failed executable.exec(java.lang.String[javac, -nowarn, -classpath, ................................long classpath which is not shown here............................................................)
at
weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java(Compiled Code))
at
weblogic.ejb20.deployer.Deployer.runEJBC(Deployer.java(Inlined Compiled Code))
at
weblogic.ejb20.deployer.Deployer.compileEJB(Deployer.java(Compiled Code))The problem was solved by using in-line compilation by specifying the -compilerclass option, and using noexit instead of the callcompile flag so that the compile method of the compilerclass gets called.
A Null Pointer Exception was thrown when a WebLogic Server 6.1 SP04 servlet or stateless session bean invoked a stateful session bean deployed on WebLogic Server 6.1 SP02. The stack trace is:
java.lang.NullPointerException at weblogic.ejb20.internal.HandleImpl.readExternal(HandleImpl.java:101) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.inputClassFields(ObjectInputStream.java:2263) at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:519) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1412) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.util.ArrayList.readObject(ArrayList.java:531) at java.lang.reflect.Method.invoke(Native Method) at java.io.ObjectInputStream.invokeObjectReader(ObjectInputStream.java:2214) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1411) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at
Analysis revealed that the wire format of the handle is extended after WebLogic Server 6.1 SP02 to resolve handle issues related to differences for stateful session bean handles when the stub is stamped with the handle. In the case of stateless session beans, stubs are not added with handles.
The problem was resolved by a code change to allow for the "no handle" case for stateless session beans.
In WebLogic Server 6.1 SP04, getter methods for a EJB 1.1 CMP bean did not call isModified() when delay-updates-until-end-of-tx was set to false
A session EJB called an entity EJB's getter methods. Both EJBs had container managed transaction with transaction attribute set to Required . Each call to a getter method is followed by a call to ejbStore() and delay-updates-until-end-of-tx was false . However, before calling ejbStore on the bean the container did not call the isModified method. The isModified() method was only called when the transaction committed.
ejbStore should be called from postInvoke() depending on the result of the isModified method in the bean. The problem was solved with a code fix.
In WebLogic Server 6.1 SP05, EJBC generated CMP code that caused a j ava.lang.ClassCastException: oracle.sql.BLOB error.
Analysis revealed that the CMP RDBMS code generated for the query was incorrect. Prior to WebLogic Server 6.1 SP05, server-side JDBC went through the RMI drive, to the pool driver, then on to the DBMS driver. Starting in WebLogic Server 6.1 SP05, the RMI driver is now only invoked in external clients. Server-side client code accesses the pool driver directly, which returns the DBMS driver BLOBs directly, not wrapped in an RMI wrapper. This change requires that code cast directly to oracle.sql.BLOB instead of weblogic.jdbc.common.OracleBlob .
The problem was solved by correcting the EJBC to generate code that reflects the SP05 and later behavior.
In WebLogic Server 6.1 SP02, the database was left in inconsistent state when a bean is undeployed. The problem occurred in this invocation scenario:
webApp <--> OuterBean <--> InnerBean
The beans are stateless session beans, using container-managed transactions, with trans-attribute=Required . OuterBean.m() inserts a row in a table, then calls InnerBean.m(), which inserts a row in a different table. Since the scenario happens within the context of a single transaction, both tables have the same number of rows. The beans are packaged in different jars. OuterBean caches the home of InnerBean and everything is deployed on a single server. InnerBean is untargeted from the server during the course of the test. In this case, the tables are left in an inconsistent state: OuterBean no longer inserts any rows in its table while InnerBean still does.
Analysis revealed that when InnerBean was undeployed, TxManager.undeploy rolls back in-flight transactions and marks the instance as dead, so that no further transactions can be enlisted. OuterBean and InnerBean were packaged in the same enterprise application, and calls were by reference and did go through RMI. The home and the bean are cached in OuterBean, so even after InnerBean has been undeployed, the remote methods called are serviced. After InnerBean was undeployed, when OuterBean called InnerBean. insert() , there was a transaction associated with the call—the one started by OuterBean. In the preInvoke, the TxListener is set up and the transaction is register with the TxManager. While registering with the TxManager, the instance was determined to be dead, and WebLogic Server rolled back the transaction and silently return. As no transaction is enlisted, the database connection obtained within the InnerBea n.insert() is not within the called transaction, so the rollback done in OuterBean has no effect on the row inserted by InnerBean—resulting in the situation where OuterBean no longer inserts any rows in its table while InnerBean still does. Silently returning, after rolling back the transaction because the bean is undeployed is the cause of the problem.
The problem was solved with a code change to check the deployment status in the preInvoke of the BaseEJBManager , thus preventing calls from reaching a bean that has been undeployed.
In WebLogic Server 6.1 SP02, using MDBs listening on MQSeries, the MQSeries java threads on the WebLogic Server side were not correctly closed upon on an MQSeries failure and re-start of MQSeries. With every failure/restart the number of MQSeries AsyncThreads doubled.
The problem was solved with improvements to the failure and cleanup code in JMSConnectionPoller.createJMSConnection() .
JDBC connections were not returned to the pool when a transaction was distributed over two server instances. The JDBC attribute KeepXAConnTillTxComplete was set to true. This sequence of events led to the problem:
No error messages were generated. The updates were performed and the message was placed in the JMS queue. However, some connections remained 'in use' in the EJB connection pool. After repeating the sequence of steps several times, the connection pool ran out of connections.
The problem did not occur if the actions were executed on a single server instance, or if the JMS message was placed in the queue outside the transaction scope.
The problem was solved with a code change to release the connection in the aftercompletion callback.
The message for the Exception during commit of transaction stack trace exception contained the connection pool name, but not the data source name. <Exception during commit of transaction Xid=39:74a54046e2c2bb30(5962554),Status=Rolled back. [Reason=ja vax.transaction.xa.XAException: JDBC driver does not support XA, hence cannot be a participant in two-phase commit. To force this participation, set the EnableTwoPhaseCommit property on the corresponding JDBCTxDataSource property, to true. Pool = CatPhase1]...
The stack trace content was enhanced to include the name of the data source.
When using a JDBC connection pool, issuing Statement.close() did not release all resources associated with the underlying ResultSet , which could lead to an OutOfMemoryError . This problem occurred only when closing the Statement via a connection pool. It did not occur when explicitly closing the ResultSet itself, or when closing a statement while directly using the driver.
This problem was solved with a code fix.
This Service Pack corrects an error in the leak detection code that caused the following stack trace:
[SerialConnection] : Connection Leak detected!!!!!!java.lang.Throwable: StackTrace at creation of connection: Start server side stack trace:
java.lang.Throwable: StackTrace at creation of connection: at weblogic.jdbc.rmi.SerialConnection.<init>(SerialConnection.java:47) at weblogic.jdbc.pool.Connection.writeReplace(Connection.java:1427) at java.lang.reflect.Method.invoke(Native Method)at java.io.ObjectStreamClass.invokeMethod(ObjectStreamClass.java:1615) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:303) at weblogic.common.internal.ChunkedObjectOutputStream.writeObject(ChunkedObjectOutputStream.java:115) at weblogic.rjvm.MsgAbbrevOutputStream.writeObject(MsgAbbrevOutputStream .java:82) at weblogic.jdbc.common.internal.RmiDataSource_WLSkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:398) at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:114) at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:339) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:850) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:334) at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest .java:30)at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:215) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:191) End server side stack traceIn WebLogic Server 6.1 SP04, the getConnectionsTotalCount() method of JDBCConnectionPoolRuntimeMBean did not behave as expected. Instead of returning the total number of JDBC connections in the pool since instantiation, it returned the maximum number of connections since instantiation.
The problem was resolved with a code fix the method.
In WebLogic Server 6.1 Service Packs 3 and 4, transactions involving the BigDecimal datatype threw a SQLWarning exception if the transaction obtained a local DataSource before obtaining a remote DataSource. The text of the stacktrace was:
java.sql.SQLException: java.sql.SQLWarning: Exhausted Resultset
Start server side stack trace:
weblogic.common.internal.WLSQLWarning: Exhausted Resultset
at
weblogic.jdbc.common.internal.DriverProxy.getWLSQLFromSQLException(DriverProxy.java:2
at
weblogic.jdbc.common.internal.ResultSetProxy.execute(ResultSetProxy.java:716)
at weblogic.t3.srvr.ClientRequest.execute(ClientContext.java:769)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
End server side stack traceThis problem occurred because the T3 driver always queried the remote result set for getBigDecimal() , rather than querying the cached data.
This problem was solved with a code fix.
WebLogic Server failed to check for a null pool name before creating a ConnectionLeakProfile object, causing the exception:
java.lang.NullPointerExceptionat java.lang.String.<init>(String.java:193) at weblogic.jdbc.common.internal.ConnectionLeakProfile.<init>(ConnectionLeakProfile.java:21)at weblogic.jdbc.rmi.internal.ConnectionImpl.unreferenced(ConnectionImpl .java:144) at weblogic.rmi.internal.BasicServerRef$UnreferencedExecuteRequest.execute(BasicServerRef.java:702) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:234 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:210)
This problem was solved with a code fix.
In WebLogic Server Service Pack 5, resetting a connection pool using weblogic.Admin RESET_POOL (or an equivalent API) caused an exception similar to the following if a connection was already released:
<Aug 13, 2003 1:33:11 PM EST> <Error> <HTTP>
<[WebAppServletContext(7096795,jdbc_webapp,/jdbc_webapp)] Servlet failed with Exception java.lang.Error: 1 Was already released:weblogic.jdbc.common.internal.ConnectionAfter a garbage collection, the server would then display a connection leak warning:
<Aug 13, 2003 1:33:19 PM EST> <Warning> <JDBC> <A JDBC pool connection leak was detected. A Connection leak occurs when a connection obtained from the pool was not closed explicitly by calling close() and then was disposed by the garbage collector and returned to the connection pool. The following stack trace at create shows where the leaked connection was created. Stack trace at connection create:
at weblogic.jdbc.pool.Connection.<init>(Connection.java:55)
at
[...]The code was fixed to eradicate the connection leak warning; the server still correctly displays the initial exception if a connection was already released at the time the pool is reset.
In WebLogic Server Service Pack 4, the weblogic.jdbc.jta.ResultSet.getType() method could recursively call itself and lead to a stack overflow exception:
java.lang.StackOverflowError
at weblogic.jdbc.jta.ResultSet.checkIfClosed(ResultSet.java:106)
at weblogic.jdbc.jta.ResultSet.getType(ResultSet.java:507)
at weblogic.jdbc.jta.ResultSet.getType(ResultSet.java:508)This problem was solved with a code fix.
By default, WebLogic jDriver for Oracle/XA Data Source set the value of the oracleXATrace parameter to true, rather than false. This caused the driver to create trace files of the form xa_ poolname *.trc that could grow large over time, unless you specifically disabled trace files by setting oracleXATrace="false" in config.xml .
The code was modified to set the default value of oracleXATrace to false if no value is specified.
When using a JDBC MultiPool, WebLogic Server threw a resource exception to the client and failed to serve connections from a backup pool if the initial pool was fully reserved at the time of the connection attempt. The code was modified to throw a ConnectDeadException instead, which the MultiPool interprets as a reason to fail over to the next pool in its list.
WebLogic jDriver for Oracle/XA did not properly handle the NLS_NUMERIC_CHARACTERS parameter set by an Oracle RDBMS instance. This caused a java.sql.SQLException when retrieving double or float values if a comma (`,') was used as a decimal separator in the database:
java.sql.SQLException: java.lang.NumberFormatException - '1,2'
at weblogic.jdbc.oci.ResultSet.getFloat(ResultSet.java:312)
at weblogic.jdbc.jta.ResultSet.getFloat(ResultSet.java:190)
at
weblogic.jdbc.rmi.internal.ResultSetImpl.getFloat(ResultSetImpl.java:224)
at
weblogic.jdbc.rmi.internal.ResultSetStraightReader.getFloat(ResultSetStraightReader.java:67)
at
weblogic.jdbc.rmi.SerialResultSet.getFloat(SerialResultSet.java:219)
at examples.servlets.DBAccess.service(DBAccess.java:54)
at
[...]The problem did not occur with the non-XA version of WebLogic jDriver for Oracle. This problem was solved with a code fix.
WebLogic Server Service Pack 5 threw a NumberFormatException when using BigDecimal types in an environment with Oracle's NLS_LANG setting. The problem did not occur when using Oracle's NLS_NUMERIC_CHARACTERS parameter to match American-style numeric character definitions. This problem was solved with a code fix.
A JMS deadlock was fixed by changing the BESession.java close(long lastSequenceNumber) method. The deadlock could be viewed in the partial thread dump:
ExecuteThread: '9' for queue: 'queue_1'" daemon prio=5
tid=0x2757938 nid=0x5e waiting for monitor entry [0xce97f000..0xce97fc68]
at weblogic.jms.backend.BETopic._addMessageToConsumers(BETopic.java:590)
at weblogic.jms.backend.BETopic.addMessageToConsumers(BETopic.java:296)
at
weblogic.jms.backend.BEMessageWriteListener.storeIOComplete(BEMessageWriteListener.java:85)
at weblogic.jms.store.StoreRequest.execute(StoreRequest.java:342)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
"ExecuteThread: '14' for queue: 'queue_2'" daemon prio=5 tid=0x57b200
nid=0x54 waiting for monitor entry [0xd1b7f000..0xd1b7fc68]
at weblogic.jms.backend.BESession.stop(BESession.java:386)
at weblogic.jms.backend.BESession.close(BESession.java:434)
at weblogic.jms.backend.BESession.close(BESession.java:1083)
at weblogic.jms.backend.BESession.invoke(BESession.java:1024)
at
weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:585)....When the server failed to send JMS messages, there was no error message on the client. The transaction manager had declared the messages unhealthy, and JMS was rolling back the messages when it failed to enlist resources.
The failure to enlist the transaction is now communicated back to client, which will be able to report that the commit failed.
When you removed all targets from a JMS Server having a JMS Template and then tried to re-target the JMS Server, WebLogic Server threw an exception:
<Aug 13, 2003 4:50:58 PM PDT> <Error> <JMS> <Failed to deploy JMS Server "server_name" due to weblogic.jms.common.JMSException: Error initializing JMSServer server_name.
weblogic.jms.common.JMSException: Error initializing JMSServer server_name
at weblogic.jms.backend.BackEnd.initialize(BackEnd.java:448)
at weblogic.jms.JMSService.createBackEnd(JMSService.java:906)
at weblogic.jms.JMSService.addJMSServer(JMSService.java:1273)
at weblogic.jms.JMSService.addDeployment(JMSService.java:1169)
at
weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:364)
at
weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:150)
at java.lang.reflect.Method.invoke(Native Method)
[...]This problem occurred because the JMS service exported a temporary destination factory to the RMI runtime, and the factory reference was not removed when the factory was unbound from JNDI. The code was fixed so that the reference to the temporary destination factory is now removed when the factory is unbound. Untargeting and retargeting a JMS Server having a JMS Template no longer causes an exception.
A problem in the optimization code for non-durable messages sometimes caused a destination to be nullified. This would result in the following exception while paging out messages under heavy loads:
<Sep 12, 2003 9:54:12 PM EDT> <Error> <Kernel> <BEA-000802> <ExecuteRequest failed
java.lang.NullPointerException.
java.lang.NullPointerException
at weblogic.jms.common.MessageImpl.writeExternal(MessageImpl.java:1622)
at
weblogic.jms.common.TextMessageImpl.writeExternal(TextMessageImpl.java:92)
at
weblogic.jms.store.ObjectIOBypassImpl.writeObject(ObjectIOBypassImpl.java:155)
at
weblogic.jms.store.BufferDataOutputStream.writeObject(BufferDataOutputStream.java:175)
at weblogic.jms.store.FileIOStream.write(FileIOStream.java:506)
at weblogic.jms.store.StoreRequest.doTheIO(StoreRequest.java:282)
at weblogic.jms.store.JMSStore.execute(JMSStore.java:493)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)The problem was solved with a code fix.
In WebLogic Server 6.1 Service Pack 5 the server attempted to pop the environment from a ReadOnlyWrapper that did not push the environment onto a thread. This caused the following AssertionError and EmptyStackException :
java.util.EmptyStackException
at weblogic.utils.collections.Stack.pop(Stack.java:82)
at
weblogic.kernel.ResettableThreadLocalStack.pop(ResettableThreadLocalStack.java:79)
at
weblogic.jndi.internal.ThreadEnvironment.pop(ThreadEnvironment.java:18)
at weblogic.jndi.internal.WLContextImpl.close(WLContextImpl.java:72)
at
weblogic.jndi.factories.java.ReadOnlyContextWrapper.close(ReadOnlyContextWrapper.java:30)
[...]
--------------- nested within: ------------------
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ attempt to pop from an empty stack ] - with nested exception:
[java.util.EmptyStackException]
at
weblogic.kernel.ResettableThreadLocalStack.pop(ResettableThreadLocalStack.java:81)
at
weblogic.jndi.internal.ThreadEnvironment.pop(ThreadEnvironment.java:18)
at weblogic.jndi.internal.WLContextImpl.close(WLContextImpl.java:72)
[...]The code was modified so that a pop is not attempted on a ReadOnlyWrapper .
WebLogic Server threw an EmptyStackException if a context was created in an ejbCreate() method and Context.close() was subsequently called in an ejbRemove() method. The partial exception text is:
java.util.EmptyStackException
at weblogic.utils.collections.Stack.pop(Stack.java:82)
at
weblogic.kernel.ResettableThreadLocalStack.pop(ResettableThreadLocalStack.java:79)
at
weblogic.jndi.internal.ThreadEnvironment.pop(ThreadEnvironment.java:18)
at weblogic.jndi.internal.WLContextImpl.close(WLContextImpl.java:72)
at javax.naming.InitialContext.close(InitialContext.java:476)
[...]This problem was solved with a code fix.
In previous WebLogic Server 6.1 Service Packs, JSP parameters with a value of "/////" were interpreted by getParameter() as having the value "/".
The problem was resolved with a code change.
WebLogic Server threw an UnsupportedEncodingException if you included extra quotation marks around the charset value of a JSP. For example, the following tag would yield the exception:
<%@ page contentType="text/html; charset=\"Shift_JIS\"" %>
The problem was resolved with a code fix.
In WebLogic Server 6.1 SP02, Java comments that start in one scriptlet and end in the next one, cause this exception:
<22.07.2002 14:12:24 CEST> <Error> <HTTP> <[WebAppServletContext(7422744,DefaultWebApp,/DefaultWebApp)] Servlet failed with Exception weblogic.servlet.jsp.JspException: (line 12): scriptlet close brace '}' unbalanced at line 12 which breaks scope '_base_service_scope_' at weblogic.servlet.jsp.ScriptletScopeLexer.mCLOSE_BRACE(ScriptletScopeLexer.java:527) at weblogic.servlet.jsp.ScriptletScopeLexer.mTOKEN(ScriptletScopeLexer.java:232) at weblogic.servlet.jsp.ScriptletScopeLexer.nextToken(ScriptletScopeLexer.java:159) at weblogic.servlet.jsp.ScriptletScopeLexer.parse(ScriptletScopeLexer.java:119) at weblogic.servlet.jsp.JspLexer.mSCRIPT(JspLexer.java:4367) at weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:2173) at ....
The problem was resolved by a code fix to the make the ScriptletScopeLexer to skip an entire Java comment.
When you precompiled JSPs on a machine in one time zone, and then deployed those same JSPs on a server in a different time zone, WebLogic Server sometimes re-compiled the JSPs. This occurred because WebLogic Server checked JSPs by comparing the local timestamp of the JSPs (as embedded by the JAR utility) against the timestamps in the generated class files.
The problem was resolved by storing the time zone at compile time and using that time zone at deployment time to determine whether recompilation is necessary.
If you refreshed a JSP with a copy, and the copy did not parse correctly, WebLogic Server entered a deadlock condition. The problem involved two separate deadlocks. The deadlocks were removed by throwing and evaluating an exception in the JSP stub level, and by removing unnecessary synchronization of threads in getJarFiles() .
The following JSP code:
<jsp:plugin type="applet" code="examples.applets.PhoneBook1.class" codebase="/bea_WebLogic Server_internal/classes/DefaultWebApp@DefaultWebApp/" height="800" width="500" type="applet" jreversion="1.3.1_06" nspluginurl="http://java.sun.com/products/plugin/1.1.3/plugin-install.html"; iepluginurl="http://java.sun.com/products/plugin/1.1.3/ jinstall-113-win32.cab#Version=1,1,3,0" >
generated this HTML:
<embed type="application/x-java-applet;version=1.3.1_06" pluginspage="http://java.sun.com/products/plugin/1.1.3/plugin-install.html"; height="800" width="500" code="examples.applets.PhoneBook1.class" codebase="/bea_WebLogic Server_internal/classes/DefaultWebApp@DefaultWebApp/">
The generated HTML code failed on Netscape: Netscape attempted to download the plug-in from WebLogic Server instead from the SUN site.
When the plugins page line was moved before the codebase line, the code worked correctly on Netscape.
A code fix to order the applet attributes properly resolved the problem.
When you set the compilerclass JSP parameter, WebLogic Server logged a compilerclass=null message in the startup log, as in:
JSPServlet with initArgs '[JspConfig:
verbose=true,packagePrefix=jsp_servlet,-compiler= C:\61sp4\jdk131/bin/javac,compileFlags=,workingDir=C:\61sp4\wlserver6.1\config\examples\applications\ examplesWebApp\WEB-INF\_tmp_war_examples_examplesWebApp,pageCheckSeconds=1,superclass=weblogic.servlet.jsp. JspBase,keepgenerated=false,precompileContinue=false, compilerSupportsEncoding=true,encoding=null,defaultfilename=index.jsp,compilerclass= null,noTryBlocks=false]'>The problem occurred because the setting of compilerclass was not used during startup. The correct setting was used for compiling JSPs. The code was fixed to obtain the correct parameter value during server startup.
WebLogic Server could fail to evaluate empty BodyTags, causing the exception:
<ExecuteThread: '14' for queue: 'weblogic.kernel.Default'> <<WLS Kernel>> <>
<BEA-101017>
<[ServletContext(id=12216222,name=xmlxTestApp,context-path=/xmlxTestApp)]
Root cause of ServletException.
javax.servlet.jsp.JspException: Could not find file:
java.io.FileNotFoundException: Could not find appropriate xml file
at weblogicx.xml.tags.XsltTag.doEndTag(XsltTag.java:280)
at jsp_servlet.__xsltprocessor._jspService(__xsltprocessor.java:195)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
at
weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6304)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:361
[...]This problem was solved with a code fix.
WebLogic Server displayed a JSP parsing error if a JSP used a tag library that specified an empty body tag using an empty element tag, as in:
<%@taglib uri="/problem-taglib" prefix="c" %>
<html>
<head><title>Problem scenario</title></head>
<body>
<table border="1"><tr><th>Local file content</th>
<th>Included file content</th></tr>
<tr>
<td>Cell containing data from the original JSP</td>
<td><c:import url="IncludedResource.jsp" /></td>
</tr>
</table>
</body>
</html>The problem did not occur if a closing element tag was added to the empty body content, as in:
<td>Cell containing data from the original JSP</td>
<td><c:import url="IncludedResource.jsp" ></c:import></td>This problem was solved with a code fix.
The pageCheckSeconds attribute, which sets the interval, in seconds, at which WebLogic Server checks to see if JSP files have changed and need recompiling, did not work the first time a JSP was modified.
This problem occurred because WebLogic Server did not set a lastStaleCheck time the first time a JSP was invoked.
The code was modified so that if lastStaleCheck is not set yet, it is set to the current time. This prevents the JSP from being recompiled unnecessarily.
When packaged in a WAR file, precompiled JSPs stored in a sub-context of the application were always recompiled upon deployment to WebLogic Server. This problem did not occur when JSPs were deployed from an exploded archive directory, or for JSPs in the root-context of a WAR file.
The problem was caused because of a difference in the rounding behavior of timestamps used in the jar and zip formats. The discrepancy in rounding could cause an older timestamp (by one second) to be recorded in class files inside the WAR file, triggering the server to recompile the classes.
The code was modified to advance the timestamps in compiled JSP classes by one second, thereby preventing JSPs from being recompiled.
When using the Sybase jConnect/XA Driver, connections were not reusable after being returned to the connection pool. This would cause the following exception, after all available connections in the pool were used:
XA error: XAER_RMERR : A resource manager error has occured in the
transaction branch start() failed on resource 'ZeusPool': XAER_RMERR : A
resource manager error has occured in the transaction branch
javax.transaction.xa.XAExceptionThe problem occurred because Sybase initiates a local transaction for DDL calls, and the transaction was not cleaned up when the connection was returned to the pool.
The connection cleanup code was fixed to end the local Sybase transaction generated by DDL calls.
If XA recovery did not return an XID, WebLogic Server 6.1 Service Pack 3 could throw a NullPointerException :
java.lang.NullPointerException
at
weblogic.transaction.internal.ServerResourceInfo.rollback(ServerResourceInfo.java:721)
at
weblogic.transaction.internal.ServerSCInfo.rollback(ServerSCInfo.java:318)
at
weblogic.transaction.internal.ResourceDescriptor.rollbackXids(ResourceDescriptor.java:1160)
at
weblogic.transaction.internal.ResourceDescriptor.recover(ResourceDescriptor.java:1060)
at
weblogic.transaction.internal.ResourceDescriptor.access$9(ResourceDescriptor.java:1029)
at
weblogic.transaction.internal.ResourceDescriptor$1.execute(ResourceDescriptor.java:770)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)The code was modified to check for the presence of an XID and prevent the exception from occurring.
After a transaction has timed out, two threads could try to roll back the same transaction ID, resulting in an error similar to:
XA.end FAILED (rm=pool_name, xar=pool_name, error code: XAER_RMERR : A resource manager error has occured in the transaction branch, message: null>
oracle.jdbc.xa.OracleXAException
at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:659)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:305)
at weblogic.jdbc.jta.VendorXAResource.end(VendorXAResource.java:47)This problem was solved with a code fix.
In WebLogic Server 6.1 SP03 and SP04, if an object passed in the "equals" method of weblogic.transaction.internal.XidImpl is not an instance of XidImpl (for instance, it is of type String ), then this exception is thrown:
java.lang.ClassCastException: java.lang.String at weblogic.transaction.internal.XidImpl.equals(XidImpl.java:114) at test.main(test.java:9)
The problem was solved with a code fix to check and report type mismatches.
When a resource name contained more than 64 characters, WebLogic Server 6.1 Service Pack 4 could throw the following exception when testing the connection pool:
java.sql.SQLException: XA error: XAER_RMERR : A resource manager error has occured in the transaction branch start() failed on resource
'weblogic.jdbc.jta.DataSource' null
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1167)
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1133)
at weblogic.jdbc.jta.Connection.getXAConn(Connection.java:153)
at weblogic.jdbc.jta.Connection.prepareStatement(Connection.java:241)
[...]The problem occurred because only the first 64 characters were tested for uniqueness. The code was modified to properly handle resource names longer than 64 characters.
In a multiple-server domain, if a Managed Server was rebooted to use a different address or port number, the JTA subsystem failed to update the address information. This would cause the following exception when the changed server was rebooted:
javax.naming.CommunicationException. Root exception is
java.net.ConnectException: t3://ip_address:port_number: Destination unreachable;
nested exception is:
java.net.ConnectException: Connection refused; No available router to destination
[...]The code was fixed to obtain new address information from the Administration Server in response to an address or port change.
In WebLogic Server 6.1 SP03 and later, temporary directories created by the Administration Console deployment descriptor editor in under the bea\wlserver6.1 directory with name jarxxxx (for example, bea\wlserver6.1\jar7018 ) were not deleted.
Analysis revealed that the temporary directories were not deleted because of a open file stream on an inner file.
The problem was resolved with a code change.
In WebLogic Server 6.1 SP04, updates to an exploded web application that was deployed to a Managed Server were reflected in the exploded application staged on the Managed Server, but not in the .war file in the .wlnotdelete directory. After server restart the old version of the application was deployed.
Refreshing the application using weblogic.refresh caused the updated .jsp to be copied into the exploded application format staged on the Managed Server, but not the original version of the .war.
The problem was resolve by a code change to remove the application entry from the local deployment file.
As a result of this change, the latest version of an application is copied from its source to a Managed Server's staging area when the Managed Server is restarted after a refresh.
In WebLogic Server SP03, a startup class that created a dynamic connection pool and targets it to a server instance, caused the server to hang, when LoadBeforeAppDeployments=true for startup class. No exception was reported.
Analysis revealed a synchronization problem, which was corrected with a code fix.
In WebLogic Server SP03 and SP04, when a Managed Server and Administration Server were shutdown at the same time, the Managed Server tried to reconnect to the Administration Server.
The problem was solved with a code change to ensure that Managed Servers do not attempt reconnect to the Administration Server while in shutdown or suspend modes.
In WebLogic Server SP03 and SP04, restarting the Administration Server resulted in the error:
Admin restart causes java.rmi.ConnectException: This RJVM has already been shutdown.
The issue was consistently reproduced using these steps:
The problem occurred because weblogic.management.internal.MBeanProxy was using a stale stub of AdminMBeanHome, because the Administration Server was restarted and the AdminMBeanHome object instance (Dynamic Proxy Stub) was no longer valid.
The problem was solved with a code change.
In WebLogic Server 6.1 Service Pack 3, using the UpdateLicense utility with the license_update_file failed to properly update the license file. This lead to the following exception when booting the server:
$$$$$$$$$$$$$$$$ License Exception $$$$$$$$$$$$$$$$
Unable to start WebLogic Server !!
WebLogic: license signature validation error!The problem was solved with a code fix.
In WebLogic Server 6.1 SP04, a ClassCastException occurred when retrieving ServletSessionRuntimeMBean.
The problem was exhibited in a two-node cluster, on which an application retrieves the array of ServletSessionRuntimeMBeans from the WebAppComponentRuntime of each cluster node, for use in determining whether a a particular user has already logged on to one of the two nodes.
The call sequence is as follows:
Repeating this call sequence several times in the same HTTP session leads to a ClassCastException in the WebAppComponentRuntime.getServletSessions() method:
ClassCastException: java.lang.ClassCastException: $Proxy79 at weblogic.servlet.internal.session.SessionData.getServletSessionRuntimeMBean(SessionData.java:271) at weblogic.servlet.internal.session.SessionContext.getServletSessionRuntimeMBean(SessionContext.java:199) at weblogic.servlet.internal.session.SessionContext.getServletSessionRuntimeMBeans(SessionContext.java:216) at weblogic.servlet.internal.WebAppServletContext.getServletSessionRuntimeMBeans(WebAppServletContext.java:2442) at weblogic.servlet.internal.WebAppRuntimeMBeanImpl.getServletSessions(WebAppRuntimeMBeanImpl.java:126) at java.lang.reflect.Method.invoke(Native Method) at...
The problem occurred because ServletSessionRuntimeMBean was cast incorrectly to the implementation—ServletSessionRuntimeMBeanImpl in SessionData.java.
The problem was solved with a code change.
In WebLogic Server SP03, if the domain and a cluster in the domain have the same name, duplicate entries appear for the Targets attribute in the domain's config.xml file. The following was observed:
When an application was first targeted to the cluster through the console, there were no problems, and the target was correctly reflected in config.xml.
After restarting the Administration Server, the Administration Console did not show that the application was targeted to the cluster, and a Managed Server in the cluster did not show the application as bound in its JNDI tree. The target was still correctly reflected in config.xml.
After the user re-targeted the application to the cluster using the Administration Console, config.xml showed the cluster name twice in its Targets attribute.
<Application Deployed="true" Name="seb" Path=".\config\rom\applications"> <WebAppComponent Name="seb" Targets="rom,rom" URI="seb.war"/> </Application>
The problem occurred because, in any version of WebLogic Server, all targets domains, clusters, servers, virtual hosts) must have unique names.
The problem was solved with a code change to modify tweblogic.managment.internal.UnresolvedMBean.java to ignore the DomainMBean when resolving in the case where the attribute is a target.
In WebLogic Server SP03, WebLogic Server stops logging, on both Administration Server and Managed Servers, when the maximum number of files is reached.
After the following error messages are printed out to the domain log file, the server logging service is shutdown.
####<Apr 21, 2003 3:17:39 PM GMT+09:00> <Alert> <Log Management> <KESATO01> <myserver> <ExecuteThread: '10' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-170017> <The log file .\myserver\myserver.log will be rotated. Reopen the log file if tailing has stopped. This can happen on some platforms like Windows.> ####<Apr 21, 2003 3:17:40 PM GMT+09:00> <Critical> <Logging> <KESATO01> <myserver> <ExecuteThread: '10' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <000000> <Handler: 'C:\bea81ga\mydomain\myserver\myserver.log' raised several exceptions. Shutting it down> ####<Apr 21, 2003 3:17:40 PM GMT+09:00> <Error> <Logging> <KESATO01> <myserver> <ExecuteThread: '10' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <000000> <Handler: 'C:\bea81ga\mydomain\myserver\myserver.log' raised exception when opening. Exception weblogic.logging.LogRotationException null> ####<Apr 21, 2003 3:17:40 PM GMT+09:00> <Error> <Logging> <KESATO01> <myserver> <ExecuteThread: '10' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <000000> <Handler: 'C:\bea81ga\mydomain\myserver\myserver.log' raised exception when opening. Exception weblogic.logging.LogRotationException null>
If the problem occurs, all log messages are not printed out to the server log file. This problem occurs on the admin server and the managed server
Analysis revealed that WebLogic Server closed log files during rotation and, if log rotation failed, the log files would remain closed.
Log Rotation failed when WebLogic Server generated the wrong index for the new log file. Since it assumed that the file that had the latest time stamp is the latest index. It never checked to see if a file with the index already existed. WebLogic Server did not attempt to delete the log file if the log file already existed and did not check to see if the rename() was successful.
In addition, for time based log rotation, on multi-CPU machines, multiple rotations happened within the same millisecond. The problems were changed with code fixes.
In WebLogic Server 6.1 SP05 restart of a Managed Server resulted in a warning. The Administration Server and Managed Server were running, and the Managed Server was shutdown. The Administration Server showed that the Managed Server was not running. Upon restarting the Managed Server, this warning was issued:
<Warning> <Management> <c4wlg001> <node001> <ExecuteThread: '1' for queue: '__weblogic_admin_rmi_queue'> <system> <> <141029> <Unable to reconnect to Admin Server running at http://c4wlg001:7001 from Managed Server - node001.> weblogic.management.configuration.ConfigurationException: Server: node001 is already running. at weblogic.management.Admin.registerManagedHome2AdminHome(Admin.java:1679) at weblogic.management.Admin.reconnectToAdminServer(Admin.java:1637) at weblogic.t3.srvr.ServerRuntime.reconnectToAdminServer(ServerRuntime.java:413) at java.lang.reflect.Method.invoke(Native Method) at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:636) at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:621) at...
The Managed Server starts successfully.
Analysis revealed that a error check was performed at an inappropriate point, preventing the JNDI tree to be appropriately updated. The problem was corrected by a code fix.
In WebLogic Server SP04, running with CR071109_610sp2.jar, an Administration Server started with the command-line options:
weblogic.management.discover.interval = 60
weblogic.management.discover.retries = 6
weblogic.management.internal.debug = true
after a failure, (java.rmi.ConnectException is thrown) managed servers were discovered and re-connected successfully, but an OutOfMemoryError occurred.
Subsequently, MBean invocations on managed servers failed with this exception:
java.rmi.NoSuchObjectException: RemoteInvokable - id: '267'
Analysis revealed that ManagedServerReDiscoveryChecker thread had stopped running, causing Managed Servers not to be discovered. The problem was solved with a change to retry logic to ensure that the discovery thread always runs when needed.
In WebLogic Server 6.1 SP05, shutdown classes were not called on Managed Servers when the Administration Server was not running. The following exception was thrown:
<29.10.2003 10:48:16 CET> <Notice> <WebLogicServer> <Started WebLogic Managed Server "managed1" for domain "mydomain" running in Production Mode>
<29.10.2003 10:49:54 CET> <Alert> <WebLogicServer> <The disabling of server logins has been requested by system>
<29.10.2003 10:49:54 CET> <Alert> <WebLogicServer> <Server logins have been disabled.>
<29.10.2003 10:49:54 CET> <Alert> <WebLogicServer> <Server shutdown has been requested by system>
<29.10.2003 10:49:54 CET> <Alert> <WebLogicServer> <The shutdown sequence has been initiated.> <29.10.2003 10:49:56 CET> <Emergency> <Server> <Unable to initialize the server: 'Fatal initialization exception Throwable: weblogic.rmi.extensions.RemoteRuntimeException - with nested exception: [java.rmi.ConnectException: Could not establish a connection with 4622510611903127260S:172.23.64.209:[7001,7001,7002,7002,7001,7002,-1]:mydomain:myserver, java.rmi.ConnectException: Destination unreachable; nested exception is: java.net.ConnectException: Connection refused: connect; No available router to destination] java.rmi.ConnectException: Could not establish a connection with 4622510611903127260S:172.23.64.209:[7001,7001,7002,7002,7001,7002,-1]:mydomain:myserver, java.rmi.ConnectException: Destination unreachable; nested exception is:
java.net.ConnectException: Connection refused: connect; No available router to destination
at weblogic.rjvm.RJVMImpl.getOutputStream(RJVMImpl.java:276)
at
weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:428)..The problem was corrected with a code change to run shutdown classes before shutting down the management layer.
If a JMX client application used getAllMBeans() on a WebLogic Server, exceptions similar to the following were thrown:
Exception in thread "main" java.lang.ClassNotFoundException:
weblogic.management.descriptors.ejb11.MailServiceMBean
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:183)
at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:190)
at weblogic.management.internal.Helper.findClass(Helper.java:831)
[...]
--------------- nested within: ------------------
weblogic.management.configuration.ConfigurationError - with nested exception:
[java.lang.ClassNotFoundException:
weblogic.management.descriptors.ejb11.MailServiceMBean]
at
weblogic.management.internal.Helper.getAdminOrConfigMBeanInfo(Helper.java:118)
[...]This problem was solved with a code fix.
[Apache] In WebLogic Server 6.1 SP03, PathTrim and PathPrepend added unexpected "/" at the end of URL. After PathTrim was applied to the original URL and it results to '/', an extra '/' was appended to the PathPrepend variable.
This problem was solved with a code fix.
[Apache] In WebLogic Server 6.1 SP03, the Apache plugin did not read PathPrepend when using <IfModule mod_weblogic.c>. The problem occurred with plugins for Apache 1.3.x and Apache 2.0.43.
The problem was solved with a code fix.
[Apache] When two virtual hosts are used in Apache server, each virtual host has defined its own WLLogFile. The value of this parameter keeps changing among two WLLogFile values defined for two virtual hosts.
There were two problems: one, WebLogic Server was only setting WLLogFile once upon server startup; two, WebLogic Server set it before getting it from VirtualHost.
Setting WLLogFile for each virtual host in the Apache plugin fixed the problems.
(NSAPI) The plug-in that shipped with WebLogic Server 6.1 Service Pack 3 used the WL-Proxy-Client-IP header to send client IP addresses. This caused problems in heterogeneous environments, because earlier servers expected the plug-in to use the X-Forwarded-For and Proxy-Client-IP headers to transmit client IP addresses.
The code was fixed to include both the X-Forwarded-For and Proxy-Client-IP headers, as well as WL-Proxy-Client-IP, so that heterogeneous environments can retrieve client addresses without modification.
(NSAPI) If an HTTP request contained an expect-continue header, the plug-in would send a 100 (Continue) response even if the plug-in's client used HTTP/1.0. The code was fixed to comply with the HTTP/1.1 specification—the plug-in does not respond with a 100 (Continue) status if the client uses HTTP/1.0 or earlier (or if there was no expect-continue header in the request).
(ISAPI) In all versions of WebLogic Server, DefaultFileName does not work if iisforward.dll is not used. The problem is exhibited when:
On a request for a directory that has no filename, the DefaultFileName is not used. The problem was corrected with a code fix.
(WLS-NSAPI) In WebLogic Server 6.1 SP04, when a client stopped a response from being sent to it (for example, closing the browser before the response is completely received), a 500 [WRITE TOCLIENT ERROR] is logged in the webserver logs.
This is unacceptable to our client who uses a webserver health monitoring tool to determine his server's health and this issue typically comes up when a request - > response takes a fair amount of time.
The webserver health monitoring tools use a 500 error to indicate that something is wrong with the server's health and that since this is not a server health issue but the client terminating the response, the error if any should not be 500.
Request response path is as follows:
client -> proxyWebserver->plugin->wls
and the expected response path is
client <- proxyWebserver<-plugin<-wls
However, after the Weblogic server has successfully sent the response, but the webserver has not completely sent it to the client, the client aborts the communication and a 500 error is logged in the webserver's access.log which normally indicates that something is wrong with the server.
The Customer is of the opinion that a different error or none at all should be logged for such a situation
A code change was implemented so that 500 errors are not generated if the client breaks the connection.
(ISAPI) In WebLogic Server 6.1 Service Pack 4, the ISAPI plugin logged an unhandled exception error in the Windows event log when it encountered a modified cookie. The event text began with the line:
The HTTP Server encountered an unhandled exception while processing the ISAPI Application.
This problem was solved with a code fix to the ISAPI plugin.
[Apache] The plug-in ignored configuration parameters that contained regular expressions other than wildcard characters (*/?). This could cause 404 errors to occur when using parameters such as:
LocationMatch "/weblogic/(abc|def)/ghi"
This problem was solved with a code fix.
(ISAPI) In WebLogic Server 6.1 Service Pack 2, using the ISAPI plugin resulted in HTTP responses having two Date headers: one inserted by WebLogic Server and one inserted by IIS. This duplication of Date headers caused problems with certain caching services that expected a single Date header.
The problem was solved by updating the ISAPI plugin to filter out the Date header inserted by WebLogic Server.
[Apache] When using multiple MatchExpression parameters in httpd.conf to route requests to different locations, as in:
MatchExpression *.jsp WebLogicHost=localhost|WebLogicPort=8001
MatchExpression *.html WebLogicCluster=localhost:8001,localhost:8003Each request overwrote the same global parameter info, which caused requests to go to the wrong location. In the above example, this problem resulted in *.jsp requests going to the server at port 8003.
The code was fixed to ensure that each request uses its own copy of the parameter information.
(Apache, NSAPI) If the POST method was used through the plug-in and the Content-Length was not defined, the proxy log file would contain message such as:
POST and PUT requests *must* contain a Content-Length
The code was modified to set a content length of zero (0) if Content-Length is undefined.
File rotation has been implemented for these types of file names.After each rotation, WLS now checks to see whether the files exceed the limit, if restricted. It then deletes the older log files.
The initial cookie was created through web server one and sent to cluster one. When ithit the application again it went through web server two and instead of being directed to cluster 1 it went to cluster 2 and created a new session.
The WLCrossOverEnabled functionality now works correctly in WebLogic Server.
Apache) HTTP requests can contain either one of the following headers: Content-Length or Transfer-Encoding
Requests with a Transfer-Encoding header set to "chunked" were failing with an IO error.
Code was added to support requests using the Transfer-Encoding header set to "chunked".
Requests were not retried when the plug-in encountered a broken pipe error on Solaris while sending post data to WebLogic Server.
WebLogic Server now throws a HALF_OPEN_SOCKET_RETRY exception when sendPostData reports a broken pipe on Solaris
Under load, Segmentation errors occurred while retrieving plugin Properties for a virtual host.
Replacing the strtok API with strchr, as the strtok API is not thread safe, eliminated the errors.
Because the plugin did not follow a part of the HTTP1.1 specification, which states that if a request/response contains both a Content-Length header as well as a Transfer-Encoding: Chunked header, the Content-Length header MUST be ignored, there was a unique scenario involving a recycled connection from the pool that sometimes caused an error.
WebLogic Server now returns contentLength as -1 if CTE is on.
When the file size exceeded 30KB, a DNS error message of IE 6.0 was received instead of a 413 message when using the NSAPI plug-in.
The behavior of MaxPostSize configuration is now the same with or without a plug-in.
WLExcludePathOrMimeType did not work correctly when a request had a query string.
Requests such as http://webserver:port/weblogic/something.jsp?value=123 were not excluded and requests such as http://webserver:port/weblogic/something.do?name=test.jsp were not forwarded.
The plug-in now ignores query strings while checking for excludes.
When KeepAliveEnabled ON was configured in httpd.conf, KeepAliveSecs defaulted to 20. This default setting could not be changed.
Code was added to ensure KeepAliveSecs is configurable.
When using multiple Location tags in a VirtualHost tag, the Apache plug-in generated a strange URL if the requests matched two more Locations.
The Apache plug-in no longer uses regular expression match, unless specified.
When using the IIS plug-in, the creation of a large number of new connections through a firewall resulted in an HTTP status 302, and the connection was closed.
WebLogic Server now recycles the connections if the HTTP status code is 302.
When the Apache plug-in encountered a missing page, it was returning a 500 error, rather than the correct 503 error.
The plug-in now returns the correct error.
When using the Apache plug-in to proxy to multiple clusters using MatchExpressions, the PathTrim attribute was failing to trim off the segment of the url used to direct the request.
Reimplementing MatchExpressions parsing without using the strtok API corrected the problem.
The IIS plug-in was sending an Http status code of 500 (internal Server Error) when it encountered a WRITE_ERROR_TO_CLIENT exception due to a connection closed by the client.
The IIS plug-in no longer sends Http status code of 500 when a WRITE_ERROR_TO_CLIENT exception is caught.
If a cookie was part of the POST data then plugin would corrupt the post data while extracting the cookie.
Code was added to fix the cookie extraction from Post Data.
If the PRIMARY server could not be located, then the request was served by the next available server in the list. It ignored the Secondary server.
If the Primary server can not be located, but the Secondary server is present then the request will be forwarded to Secondary server rather than being served by another server on the list.
WebLogic Server was throwing an exception from inside the catch block which sometimes caused iPlanet to fail.
WebLogic Server no longer throws an exception from the catch block.
When Apache was stopped while using a single-thread multi-process module, it would try to stop the timer thread first. This timer thread never existed, thus a core dump occurred.
WebLogic Server no longer creates timer threads when Apache is being used with a single-thread multi-process module.
The ISAPI plug-in was unable to handle requests with the Transfer-Encoding header set to chunked.
Functionality was added to enable ISAPI to handle such requests.
WebLogic Server was throwing CONNECTION_REFUSED errors with the Iplanet plugin.
After polling a socket for WRITE operation, if the state of the socket is in any one of the following states, then the plug-in will not throw aCONNECTION_REFUSED exception.
Valid states are:
POLLOUT
POLLWRBAND
POLLWRNORM
(Apache) The plug-in was dropping sessions after WebLogic Server was restarted.
This is because Apache 1.3.x creates multiple child processes to handle incoming requests. Each process maintains its own serverlist where each server entry is uniquely identified by the JVMID (provided by WebLogic Server, and which is updated when a request is successfully processed). Whenever a server instance is restarted, it generates a new JVMID. So a request whose cookie contains a new JVMID will fail to locate the corresponding primary server plug-in if the JVMID is not refreshed in the plug-in.
A code fix ensures that if the JVMIDs extracted from cookie do not match with the ones stored in the serverlist, then WebLogic Server will try to refresh the JVMIDs once again.
Weblogic Server was not accepting more than one header when the response.addHeader method was used.
The plug-in now allows WWW-Authenticate to have multiple values.
In an Apache configuration with multiple virtual hosts, if only one of the virtual hosts was configured with SecureProxy=ON for the WebLogic Server plug-in, and the other virtual hosts did not use SecureProxy or WLProxySSL, the virtual hosts with no SSL configured saw that the plug-in attempted an SSL connection with the backend WebLogic Server. This caused a performance problem.
A new argument was added to an internal method to determine if a SSL connection needs to be initiated.
Apache plugin caused a duplicated http header and body for the 302 response. There was no problem between the plugin and backend servers, but the Apache server added an additional 302 response.
Code was added which reverted the return value of the request_handler method to OK.
When the plug-in parameter "QueryFromRequest" was used in the httpd.conf file
it gave the following syntax error during Apache Server startup
Syntax error on line 971 of C:/Program Files/Apache
Group/Apache2/conf/httpd.conf:Invalid command 'QueryFromRequest', perhaps misspelled or defined by a module not included in the server configuration.
The Apache 2.0 plug-in now supports the "QueryFromRequest" parameter.
The release 8.1 SP02 plug-in with client certificates reported the following error:
Failed to parse the client certificate in header: WL-Proxy-Client-Cert. Ignoring this certificate. java.security.cert.CertificateException: Could not parse certificate: java.io.EOFException.
The error occurred because the plug-in truncated the WL-Proxy-Client-Cert header when sending it to the WebLogic Server instance.
The problem was resolved with a code fix.
When using the release 7.0 SP02 plug-in with client certificates, WebLogic Server worked correctly. However, after an upgrade to release 8.1 SP02, the server log reported the following error:
Failed to parse the client certificate in header: WL-Proxy-Client-Cert. Ignoring this certificate. java.security.cert.CertificateException: Could not parse certificate: java.io.EOFException
The error occurred because the 8.1 SP02 plug-in truncated the WL-Proxy-Client-Cert header when it sent it to the server instance.
The code was changed so that WL-Proxy-Client-Cert is lazily added to the request sent to WebLogic Server.
(Apache) The Apache server generated core dumps when using the worker (multi-threaded) option instead of the prefork (only multi-process) option.
This was resolved by fixing the Locking and Unlocking logic.
(Apache) The Apache server was hanging when the WebLogic plug-in tried to open the wlproxy log file, even though Debug was OFF.
The code has been fixed so that the log file is not set if debugging is turned off.
When the WLExcludePathOrMimeType property was defined within a Location tag, it should not have had a global scope. (However, when the property was defined outside a Location tag, then it should have had a global scope.)
This was resolved by a code change to ensure that the WLExcludePathOrMimeType property is applied only to the requests that match the appropriate Location path for the defined property.
(Apache) The plug-in was logging a confusing "error page is unavailable" log message to the apache error.log, even when the client had closed the connection.
This was resolved by a code change that commented out the erroneous log message.
(NSAPI) The "pluginparams.ErrorPageTest" failed when attempting a proxy by extension.
The workaround for the ErrorPage to be loaded locally is to use the WLExcludePathOrMimeType property if proxying by MIME type.
For the SUN One Web Server, version 6.1, some additional configuration steps are required:
For more information, refer to Sun's documentation, at http://docs.sun.com/source/817-1831-10/agjava.html#wp1084 323
Provided an enhancement to the WLExcludePathOrMimeType parameter allowing it to be used at the Location tag level.
WLExcludePathOrMimeType parameter can now be defined locally at the Location tag level as wells as globally. When the property is defined locally, it does not override the global property but defines a union of the two parameters.
When the FilterPriorityLevel was set in the iisforward.ini file, the forwarding path was broken.
A code fix was implemented to ensure that when a virtual host was not defined in the iisforward.ini file, the iisproxy.ini file from the same location as where the iisforward.dll file was loaded is used.
iPlanet users experienced a problem with host name verification and received the following:
INFO: Host () doesn't match (), validation failed
ERROR: SSLWrite failed
A code fix resolved this issue.
The ISAPI plug-in sent the WL-PATH-TRIM HTTP Header value to a WebLogic Server in place of the WL-PATH-TRIM value.
WebLogic Server now receives the correct value.
When the NSAPI plug-in performed name resolution on backend WebLogic Server instances, name resolution used sysGetHostByName, which called getHostByName, which called internal methods that had maximum limits for open file descriptors, causing name resolution sometimes to fail.
A fix to cookie parsing and the substitution of JVMIDs to locate primary and secondary servers resolved the problem.
The ISAPI plug-in sometimes failed after adding a persistent cookie to a servlet session.
A correction to the cookie parsing code resolved the problem.
[ISAPI] When a connection was retrieved from the pool, but the WebLogic Server had already closed the connection, then the HALF_OPEN_SOCKET_RETRY exception was raised.
Requests will be now be retried after receiving the HALF_OPEN_SOCKET_RETRY exception.
WebLogic Server proxy plug-ins restrict the HTTP commands that can be submitted from the client to the server. The validation rules in the plug-in code now allow the following HTTP commands that are needed for WebDAV implementations:
DELETE
OPTIONS
*COPY
MKCOL
PROPFIND
PROPPATCH
SEARCH
UNLOCK
A request did not fail over to the next available server in the cluster after receiving 503 HTTP status. The same server was tried repeatedly until a READ_ERROR_FROM_SERVER or a CONNECTION_REFUSED exception was raised.
Code now marks the server as failed on getting a 503 HTTP status error, gets the next available server and re-sends the request. All requests now successfully fail over to next available server.
During the repository id generation of getter and setter operations, sometimes an extra '_' was added if the getter or setter contained a reserved keyword. This sometimes resulted in the failure of a remote call.
WebLogic Server now ensures it truncates extra underscores.
The method used to send IIOP messages was unsynchronized leading to corruption of the underlying data if multiple threads tried to send and receive data at the same time.
The method was made synchronized and the product now works correctly in multi-threaded environments.
When a application client code cached the remote stub and invoked a remote method on a SLSB deployed to a cluster, the behavior was that each call refreshed the list which tracked the cluster nodes where the remote object is available. This list was used to failover the calls if any of the node failed with a recoverable exception. The issue here was that failover did not work when the entire cluster was restarted while the application client had cached the stub from a previous invocation.
The retry logic in the failover algorithm was incorrect. This logic originally allowed n-1 number of retries in a cluster with n nodes. When the entire cluster restarted, the cached stub would have stale list. And the retry logic scanned though the stale list and exhausted all the retry attempts. In the last attempt it would have potentially refreshed the list. Even though the client side stub now had a new copy of the list it did not attempt to failover as it has already reached n-1 attempts limit.
The remote stub cached in the application client now ensures it refreshes the list only when remote method invocation fails on all the nodes in the existing list. Then stub is given one last chance for failover if the list got refreshed. If this last chance does not succeed the stub will throw an exception to the application otherwise failover will continue to work as advertised transparently.
In WebLogic Server 6.1 SP06, the examples.ejb 1.1 package, examples/ejb/building.html provides incorrect instructions for building samples, and incorrectly describes how the samples build script works. The instructions and description refer to previous version of the build script which used build.cmd or build.sh. The current version of the build script (build.xml) uses ant. To run build.xml, type ant in the directory for the sample you wish to build. To understand how the build script works, refer to the comments in build.xml
When using the .NET C# example included with the MedRec application (%WEBLOGIC_HOME%\samples\server\medrec\src\clients\CSharpClient\bin\ReleaseCSharpClient.exe), the client successfully retrieves a patient record, but when attempting to "Save Changes" from the client application, a date field error was flagged.
A code change fixed the date validation.
Some internal WebLogic Server objects that are bound into the JNDI tree were insufficiently protected. Some of these objects control key functions of the server. Simply unbinding the appropriate objects renders the server unreachable. It was possible to leave the server operational but to have some confidential data transmitted to a foreign object rather than the internal WebLogic Server object.
The patches available in this release control access to the JNDI tree.
See Security Advisory BEA04-65.00 .
Whenever an HTTP or HTTPS request was made of the server, information about the WebLogic Server version was supplied.
The default setting for returning a Web Server version upon HTTP or HTTPS request has been changed from true to false.
See Security Advisory BEA04-70.00 .
A deadlock occurred between two threads when using Netscape LDAP classes - LDAPConnection and LDAPConnThread. This deadlock grew until all the default execution threads were deadlocked with LDAPConnThreads.
After updating to the new Netscape SDK, deadlocks no longer occur.
A protection problem occurred when WebLogic Server was running on an operating system that required case-sensitive filenames and cross-mount directories containing Web applications from an operating system that did not support case-sensitive filenames. For example, this problem occurred when mounting Windows-based Web applications onto a Linux-based WebLogic Server.
This resulted in some URL patterns in the web.xml file being incorrectly evaluated so that access control was compromised.The associated patch adds configuration options to specify that Web application files should be treated as case-insensitive even though the operating system may be running in case-sensitive mode.
See Security Advisory BEA04-67.00 .
The constructor method for a flat group used by a custom realm expected a case-sensitive value. When a case-sensitive value was not found, a NullPointer exception was thrown.
WebLogic Server no longer throws a NullPointer exception when the value for the CachingRealm MBean value is null.
A set of enhancements have been added to the WebLogic Server command-line utilities and Administrative ant tasks to eliminate the need for a system administrator to enter a clear-text password. With these fixes, the WebLogic Server command-line utilities and Administrative ant tasks now create and read user-managed configuration files. Like the boot.properties files, this new capability relies on strong encryption and file system protections for security.
See Security Advisory BEA04-68.00 .
A NullPointer exception occurred when using the WebLogic Server Administration Console to list LDAP users.
Code was added to eliminate the NullPointer exception.
The Use Java attribute on the SSL tab in the WebLogic Server Administration Console was not working properly.
The behavior of the attribute has been fixed.
A password echo occurred intermittently on the Linux operating system when booting WebLogic Server using the Administrative Console.
No-echo capabilities have been added to resolve the issue. See the README file in the patch for further documentation.
See Security Advisory BEA04-69.00 .
If the certificate name was the same for both an Administration Server and remote Managed Server, WebLogic Server used the certificate for the Administration Server for the remote Managed Server.
The SSL Listen thread has been updated so that is only loads local certificates.
WebLogic Server was setting the AuthenticatedUser in the session rather than the AuthenticatedUserName.
Servlet authentication has been changed so that is sets the AuthenticatedUsername resolved in the ClassCast exception.
If host name verification failed but the setExpectedName() method was defined, WebLogic Server ignored the host name defined in the method and dropped the connection.
WebLogic Server now performs the host name verification check first. If that check fails, WebLogic Server uses the ExpectedName() method to verify the hostname. If that verification fails, the connection is rejected.
A NullPointerException was being thrown when an Applet attempted to obtain an initial
context using the t3s protocol.
The basic constraints check for applets was updated, and this eliminated the NullPointerException.
Following a code change, WebLogic Server does NOT support HTTP TRACE requests by default. If you want to turn on HTTP TRACE support, in WebLogic Server 6.1 and above, set HttpTraceSupportEnabled="true" in cluster/server. In 5.1, set weblogic.httpd.httpTraceSupport.enabled=true.
See Security Advisory BEA04-48.01 .
WebLogic Server was verifying the hostname of the administration server against the administration certificate in the nodemanager, thus causing an error.
Hostname verification in the nodemanager now only checks against the nodemanager hosts file.
The value that the WebLogic Server SNMP agent returned for sysUpTime did not accurately report the duration since the SNMP agent had been initialized.
The duration since initialization is now accurately reported.
When SNMP information was collected using a third-party collector task, the following message was logged:
<Error> <SNMP Agent> <000000> < Unable to set Entry Field Value...>
A code fix was implemented to resolve this issue.
WLEC clients were experiencing the following problems with WLEC connection pools:
Corruption of the ConnectionPool display in the administration console
COMM_FAILURES caused by unregistered endpoints
A code fix was implemented to resolve these issues and improve the overall performance of WLEC connection pools.
A memory leak occurred when deploying an Enterprise Application that contained a singleton class with static data. The problem did not occur when the singleton class was deployed as a Web Application.
This problem was solved with a fix to the application classloader.
WebLogic Server threw a ClassNotFoundException when processing a user-defined exception thrown from an EJB on a remote server to an EJB on the local server. This occurred even though the user-defined exception was included in the classloader for the local EJB. The problem occurred because the socket reader that processed the exception used the system classloader, rather than the application classloader.
This problem was solved with a code fix.
Client programs could not use java.lang.reflect.Proxy to access proxy objects deployed in WebLogic Server, unless the proxy classes were added to the system classpath. If an object did not reside in the system classpath, the client would receive a ClassNotFoundException .
The resolveProxyClass() method was implemented to load interfaces from the application-specific classloader as well as the system classloader.
WebLogic Server 6.1 SP04 threw a null pointer exception at weblogic.rmi.cluster.BasicReplicaList.add(BasicReplicaList.java:61). The problem occurred when a managed server was restarted after a failure. Upon restart, the NPE occurred and all server instances in the cluster had to be restarted. The error was related to a timing issue, and was solved with a code fix.
Clustered servers could lose sessions when a client switched to a third server in the cluster from the first and second servers, which had been the client's primary and secondary servers. A process would remove the session from the first two servers, and when the client switched back to the primary server, the primary server looked for the session on the secondary server, instead of properly looking on the third server.
A code fix resolved the problem by causing the session to be recreated from session information on the third server, completely removing the session from the primary and secondary servers.
In WebLogic Server 6.1 SP02, when using HTTP Tunneling with a cluster, the client got this message:
java weblogic.Admin -url http://colma:17683 -username system -password password PING 10
<May 29, 2003 10:14:18 AM PDT> <Error> <RJVM> <000515> <execute failed java.net.ProtocolException: Tunneling result not OK, result: 'DEAD', id: '0'java.net.ProtocolException: Tunneling result not OK, result: 'DEAD', id: '0'
at
weblogic.rjvm.http.HTTPClientJVMConnection.receiveAndDispatch(HTTPClientJVMConnection.java:422)
at
weblogic.rjvm.http.HTTPClientJVMConnection.execute(HTTPClientJVMConnection.java:305)
at
weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213 at
weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)
>
Failed to connect to
<urldeleted>
due to:
<urldeleted>
:Bootstrap to
<urldeleted>
failed. It is likely that the remote side declared peer gone on this JVM]
The problem occurred because the plug-in tried to round-robin each tunnel request to the next server. The request did not stick to the same server.
The problem was solved with a code fix to ensure state was maintained in the client by setting the jsessionid cookie and sending it back to the plugin.
In WebLogic Server 6.1 SP04, an error occurred when trying to update a secondary session. Given three clustered server instances: Server A, Server B, and Server C.
1) Hit Server A, PRIMARY A, SECONDARY C
2) Hit Server C, PRIMARY C, SECONDARY B
3) Hit Server A again
This error occurred on Server A:
<Jun 4, 2003 4:24:56 PM PDT> <Debug> <Cluster> <Error updating secondary for 3535724191309537720 on 7312270160516507840S: <IPaddressdeleted> : [7005,7005,7002,7002,7005,7002,-1]: <IPaddressdeleted> :7005, <IPaddressdeleted> :7005, <IPaddressdeleted> :7005:mydomain:myserver3. Re-creating secondary.>
This error occurred on Server C:
<Jun 4, 2003 4:24:56 PM PDT> <Info> <Cluster> <Lost 0 replication updates of object 3535724191309537720. Re-fetching secondary.>
The problem was solved by a code change.
In WebLogic Server 6.1 SP03, when a client of a stateful session bean accessed a bean deployed on a cluster configured for weight-based load-balancing, and the Managed Servers with the highest and second highest weight are killed in that order, the client gives the following message
<Jul 22, 2003 1:32:56 AM IST> <Warning> <Kernel> <No replica in list has the expected weight. Reverting to round-robin>
When the Managed Servers are restarted, the load balancing algorithm was switched to round-robin.
Analysis revealed that the replica list was getting updated when a Managed Server went down, but due to a race condition the max weight in RichReplicaList was not reset properly.
A code change to recompute max weight whenever the replica list size changes solved the problem.
The web application container returned 404 messages for InitJVMID requests from the HTTPClusterServlet , resulting in log files filling up with messages:
####<Sep 6, 2002 4:56:43 PM EDT> <Debug> <HTTP> <petunia> <ms1petunia> <ExecuteThread: '13' for queue: 'default'> <kernel identity> <> <101147> <HttpServer(887891,null default ctx,ms1petunia) found no context for "/WLDummyInitJVMIDs".
The problem was solved by sending InitJVMID requests to the internal web application which is always deployed on WebLogic Server.
When a transaction obtained connections to two resource adapters and both adapters used the same resource manager, WebLogic Server cleaned up only one connection. The connections were closed before the committing the transaction. This problem appeared as a javax.resource.spi.ResourceAllocationException .
The problem occurred because the transaction manager ignored the second connection that used the same resource manager. This was solved with a code fix.
When allocating a new connection, the connector container used the descriptor MBean to obtain configuration information. Because the descriptor MBean resides on the Administration Server, Managed Servers required the Administration Server to be available in order to allocate the new connection. If the Administration Server was down, the process of allocating new connections would throw a exception:
weblogic.rmi.extensions.RemoteRuntimeException
The container was modified so that it stores configuration information locally after an adapter is deployed. Managed Servers use this local configuration information, rather than the descriptor MBean, for allocating new connections.
When WebLogic Server Service Pack 5 obtained MetaData information from a Resource Adapter, it did not check the return value for nulls before using the object. This could cause a NullPointerException and connection failure.
The code was modified to check the return value for null after calling getMetaData() . If an adapter's implementation of ManagedConnection.getMetaData() returns a null value, WebLogic Server no longer throws a NullPointerException and no MetaData is logged.
WebLogic Server sometimes displayed the following NullPointerException when a domain contained two Administration Servers and you tried to access the servers via the Administration Console:
java.lang.NullPointerException
at
weblogic.management.console.helpers.UrlHelper.buildIconList(UrlHelper.java:149)
at weblogic.management.console.helpers.UrlHelper.getIcon(UrlHelper.java:174)
at
weblogic.management.console.tags.SmartNavNodeTag.getIcon(SmartNavNodeTag.jacva:111)
at
weblogic.management.console.tags.SmartNavNodeTag.inferStuffFromContext(SmartNavNodeTag.java:96)
at
weblogic.management.console.tags.SmartNavNodeTag.doStartTag(SmartNavNodeTag.java:44)
at
weblogic.management.console.webapp._domain.__nav._jspService(__nav.java:301)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198)
at
weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:250)
[...]
This problem was solved with a code fix.
After upgrading from WebLogic Server SP02 to SP04 on Solaris 8, when customer logs into the console they get the following exception in the log files. The console continues to work.
j ava.lang.NullPointerException at weblogic.management.console.utils.ConsoleComparator.compare(ConsoleComparator.java:81) at java.util.Arrays.mergeSort(Arrays.java:1176) at java.util.Arrays.sort(Arrays.java:1123) at java.util.Collections.sort(Collections.java:116) at weblogic.management.console.utils.MBeans.sort(MBeans.java:1103) at weblogic.management.console.tags.DeclareBeanSetTag.doStartTag(DeclareBeanSetTag.java:99) at weblogic.management.console.webapp._domain.__nav_services._jspService(__nav_services.java:982) at weblogic.servlet.jsp.JspBase.service(JspBase.java:27) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198) at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:490) at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:316) at weblogic.servlet.jsp.PageContextImpl.include(PageContextImpl.java:116) at ...
Analysis revealed that MBeans were returning a null displayName . The problem was solved with a code fix.
In WebLogic Server 6.1 SP02, when the WebLogic Server security manager starts and sets the policy file, the path /usr/lib was prepended to javac during JSP compilation, causing a java.security.AccessControlException.
The problem was solved with a code fix.
In WebLogic Server 6.1 SP04 and SP05, when starting WebLogic Server as an Windows service using a classpath from a file, the error
"Thread created successfully! Exception in thread "main" java.lang.NoClassDefFoundError: weblogic/Server"
is thrown if classpath file is over about 2k length.
The problem was solved by correcting an error related to reading the classpath from a file.
When using URLClassLoader on the client, a remote method call resulted in a NoClassDefFoundError.
c:\java\java131_07\bin\java -classpath ".;client.jar;C:\home\ravia\weblogic\dev\src700\3rdparty\weblogicaux.jar" URLTest qa146 9901 ejb20-statefulSession- TraderHome installadministrator installadministrator java.lang.NoClassDefFoundError: weblogic/rmi/extensions/server/Stub at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:488) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:106) at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:401) at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:162) at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:190) at weblogic.utils.classfile.utils.CodeGenerator.generateClass(CodeGenerator.java:71) at ...
The problem was solved by setting ThreadContextClassLoader as the parent for AugmentableSystemClassLoader .
In WebLogic Server 6.1 SP04, this error occurred:
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Old socket closed and released FD before FDRecord still exists,...
The problem was solved with a code change to Ensure that socket closes outside the muxer are handled gracefully.
The Solaris and Windows 2000 versions of WebLogic Server logged socket exceptions similar to:
<Apr 3, 2003 11:40:07 AM EST> <Error> <socket> <000424> <IOException on socket: weblogic.servlet.internal.MuxableSocketHTTP@1eca988 - idle timeout: '30000' ms, socket timeout: '0' ms, fd: 53 java.net.SocketException: Connection reset java.net.SocketException: Connection reset
at
java.net.SocketInputStream.read(SocketInputStream.java:168) at
weblogic.socket.PosixSocketMuxer.readBytesProblem(PosixSocketMuxer.java:876)
at
weblogic.socket.PosixSocketMuxer.deliverGoodNews(PosixSocketMuxer.java:767)
at
weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:694)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
ad.run(ExecuteThread.java:189)
>
However, these messages do not indicate a defect with the server or application. The code changed so that the above exceptions are displayed only when the server is in debug mode.
In WebLogic Server 6.1 SP04, child threads of WebLogic Server execute threads did not inherit the correct context classloader. This problem common occurred when a servlet or an ejb created a timer (java.util.Timer).
Analysis revealed that WebLogic Server execute threads maintained their own context classloader and child threads of these execute threads did not inherit the context because java.lang.Thread directly assigned the member variable of its own to the child threads.
The problem was solved with a code fix.
In WebLogic Server 6.1 SP04, the following exception occurred on a Solaris 8 server with patch for CR100665_61sp4.jar:
<Apr 23, 2003 3:36:27 PM CDT> <Error> <Posix Performance Pack> <Uncaught Throwable in processSockets java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:750) at java.util.HashMap$EntryIterator.next(HashMap.java:792) at java.util.HashMap.putAllForCreate(HashMap.java:408) at java.util.HashMap.clone(HashMap.java:624) at java.util.HashSet.clone(HashSet.java:217) at weblogic.socket.PosixSocketMuxer.closeSockets(PosixSocketMuxer.java:486) at weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:589) at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
The problem was solved with a code fix.
WebLogic Server ships with a file named wlntio_g.dll , which is a debug version of of wlntio.dll (and is required only for debugging purposes). WebLogic Server 6.0 Service Pack 2 included the wrong version of wlntio_g.dll , which could cause stack traces similar to the following when used for debugging:
<NT Performance Pack> NATIVE.malloc(): allocated at 0x08DAD008 numAllocs 1
numFrees 0
NATIVE: start io on 1972 with addr 0x08dad008
NATIVE: GetQueuedCompletionStatus on 1972 with addr 0x08dad008
<May 6, 2003 11:17:19 AM EDT> <Error> <NT Performance Pack> <failure in
processSockets() - GetData: 'weblogic.socket.NTSocketMuxer$GetData - native
pointer: '0', numBytes: '0''
java.lang.NoSuchFieldError: fd
at weblogic.socket.NTSocketMuxer.getNextSocket(Native Method)
at
weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:589)
at
weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)>
Service Pack 6 now includes the correct version of wlntio_g.dll .
In WebLogic Server 6.1 SP04, stateful session EJB failover did not work when multiple failovers were required
In a three node cluster a JSP creates or calls a replica-aware stateful session EJB. The remote EJB stub is stored in the http session. After each call to the stateful session EJB the updated EJB stub is also updated in the http session to reflect any changes for the EJB replica list (primary/secondary).
The following call sequence with the same browser window leads to a java.rmi.ConnectException when only one node of the cluster survives:
1. All three cluster nodes are running.
2. Making a call to node1, create EJB and store remote in http session (http session replication is enabled)
3. Kill node1
4. Make a call to the secondary node2, the EJB remote is retrieved from the replicated http session and the call to the EJB works fine. After this EJB call again the remote is stored in the http session.
5. Kill node2
6. Make a call to node3, get the EJB remote from http session.
WebLogic Server tries to lookup the EJB on node2 and does not try to use node3 (this should now be the new secondary?). The following exception is thrown on node3:
java.rmi.ConnectException: Could not establish a connection with -3088833905169218734S:172.23.64.38:[7001,7001,7002,7002,7001,7002,-1]:mydomain:managed2, java.rmi.ConnectException: Destination unreachable; nested exception is: java.net.ConnectException: Connection refused: connect; No available router to destination
at
weblogic.rjvm.RJVMImpl.getOutputStream(RJVMImpl.java:275)
at
weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:408) at
weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest(BasicRemoteRef.java:97)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:255)
The problem was solved with a code fix.
In WebLogic Server 6.1 SP04, a customer saw close_waits running under AIX.
Analysis revealed that when WebLogic Serve 6.0 clients connected to a WebLogic Server 6.1 instance, WebLogic Server leaked sockets. This occurred when WebLogic Server attempted to close the MuxableSocket via the muxer without registering the socket with the muxer—the socket was rejected after being claimed by t3, before it could be registered with the muxer. The problem was corrected with a code fix.
In WebLogic Server 6.1 SP04, running with IBM's MQWorkflow on AIX 5.2., invocation of an MQWorkflow Java API by a servlet in WebLogic Server resulted in an error in MQWorkflow. The problem was not exhibited under Window, if Native IO (Performance Pack) was disabled, or if the libmuxer.so library was removed from the classpath.
Analysis revealed that WebLogic Server did not set the "language code", an encoding parameter, to "en-us" as it should, but to "c". The problem was corrected with a code fix.
In WebLogic Server 6.1 SP03 and SP04, restart of the Administration Server resulted in this error:
java.rmi.ConnectException: This RJVM has already been shutdown
The problem was reproduced consistently when beforing these steps:
The following error resulted:
<Feb 5, 2003 7:03:27 PM PST> <Info> <J2EE> <Undeployed: ejb_basic_statelessSession> java.rmi.ConnectException: This RJVM has already been shutdown -7152222714009328 37S:172.17.25.250:[7001,7001,7002,7002,7001,7002,-1]:mydomain:myserver
at
weblogic.rjvm.RJVMImpl.getOutputStream(RJVMImpl.java:280)
at
weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:408)
at
weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest(BasicRemoteRef.java:97)
at
weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:125)
at
weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35) at $Proxy7.getMBeanServer(Unknown Source)
at weblogic.management.internal.MBeanProxy.getAttribute(MBeanProxy.java:253)
The problem was solved with a code change to remove stale MBean references.
In WebLogic Server 6.1 SP04, running with AIX, a method call made over IIOP to a remote object hung.
The customer has a server (non-WebLogic Server) hosting remote objects. An EJB running on WebLogic Server calls a remote object on the non-WebLogic Server over IIOP. The method call hung indefinitely. The method call was simple—it returns a boolean type. The thread dump showed:
"ExecuteThread: '11' for queue: 'default'" (TID:0x300C12A8, sys_thread_t:0x35649A58, state:CW, native ID:0x1011) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:429) at weblogic.iiop.SequencedRequestMessage.waitForData(SequencedRequestMessage.java:24) at weblogic.iiop.EndPointImpl.sendReceive(EndPointImpl.java:641) at weblogic.iiop.OutboundRequestImpl.sendReceive(OutboundRequestImpl.java:43) at weblogic.iiop.IIOPRemoteRef.invokeInternal(IIOPRemoteRef.java:128) at weblogic.iiop.IIOPRemoteRef.invoke(IIOPRemoteRef.java:90) at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35) at $Proxy70.isRunning(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at weblogic.iiop.IIOPInvocationHandlerImpl.invoke(IIOPInvocationHandlerImpl.java:285) at $Proxy71.isRunning(Unknown Source) at...
Analysis revealed a classloader problem. A code fix resolved the problem.
In WebLogic Server 6.1 SP05 a lookup on context (and assigning to object) throws IllegalArgumentException if EJB stubs is not in classpath
The problem occurred with a stateful session EJB ( examples.ejb20.basic.statefulSession , shipped with WebLogic Server) deployed to a single WebLogic Server server. A JDNI lookup was performed on the EJB home object and the returned value was assigned to the class object. The client classpath contained weblogic.jar and no client classes.
This code was used to perform the lookup on the context.
Context ctx = new InitialContext(ht); Object objref = ctx.lookup("ejb20-statefulSession-TraderHome");
The lookup succeeded for latter succeeds for WebLogic Server 6.1 SP03 but failed on WebLogic Server 6.1 SP05. The exception was:
j ava.lang.IllegalArgumentException: java.lang.IllegalArgumentException: interface examples.ejb20.basic.statefulSession.
TraderHome was not visible from the class loader With verbose classloading set for the JVM, it was found that the examples.ejb20.basic.statefulSession.TraderHome class was successfully loaded by the In WebLogic Server 6.1 SP03, although it was not in the classpath. With In WebLogic Server 6.1 SP05, the failure occurred when attempting to load that class.
The problem was solved by a code change to ensure the ClientRuntimeDescriptor uses the current classloader, if it is a GenericClassLoader.
In WebLogic Server 6.1 SP04, the WLECConnectionRuntime MBeans were not updated when an INVOKE was issued on WLECConnectionPoolRuntime using Admin tool.
Analysis revealed that when resetConnectionPool() was invoked on the WLECConnectionPoolRuntime MBean, the pool was not reset. Old connections were not removed
The problem was solved with a code change. Now, the mbeans that correspond to old connections are unregistered before the resetConnectionPool() invocation.
In WebLogic Server 6.1 SP05, a deadlock in weblogic.socket.PosixSocketMuxe r was detected when a Managed Server could note connect to the Administration Server. This is an extract from the thread dump:
1wasLKDEADLOCK Deadlock detected!!!
NULL
NULL
2LKDEADLOCKTHR Thread "ExecuteThread: '0' for queue:
'__weblogic_admin_rmi_queue'" (0x8461B8A0) 3LKDEADLOCKWTR is waiting for:
4LKDEADLOCKMON sys_mon_t:0x84D183A8 inflaming: 0x00000000: 4LKDEADLOCKOBJ weblogic.socket.PosixSocketMuxer$FDRecord@31FD4B10/31FD4B18:
3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread "ExecuteThread: '98' for queue: 'default'" (0x767D26E0)
3LKDEADLOCKWTR which is waiting for:
4LKDEADLOCKMON sys_mon_t:0x83AD8C18 inflaming: 0x00000000:
4LKDEADLOCKOBJ weblogic.rjvm.ConnectionManagerServer@31FA3430/31FA3438:
3LKDEADLOCKOWN which is owned by:
2LKDEADLOCKTHR Thread "ExecuteThread: '0' for queue: '__weblogic_admin_rmi_queue'" (0x8461B8A0)
The following exception is also thrown:
java.rmi.ConnectException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl@2a7512ad - id: '8419466038107054512S:10.32.197.52:[7001,7001,-1,-1,7001,-1,-1]:bossapp:AdminServer' connect time: 'Fri. Aug 01 09:43:07 CST 2003'' has already been shut down at weblogic.rjvm.ConnectionManager.getOutputStream(ConnectionManager.java(Compiled Code)) at...
Analysis revealed that PosixSocketMuxer hit the deadlock due to contention for the FDRecord and ConnectionManage r locks. One thread holds the FDRecord lock and waits for a ConnectionManager lock, which is held by another thread which is waiting for the FDRecord lock to do a cleanup.
A code fix removed the contention. Now, the FDRecord lock is not held during dispatch.
For context-wide sessions, WebLogic Server did not check if an object was Serializable before placing it in the session. This could lead to the error:
Could not deserialize context attribute
java.io.NotSerializableException:
com.app.name
at
java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java(Compiled Code))
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code))
at
weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java(CompiledCode))
at
weblogic.servlet.internal.WebAppServletContext.getAttribute(WebAppServletContext.java(Compiled Code))
at
weblogic.servlet.internal.WebAppServletContext.getAttribute(WebAppServletContext.java(Compiled Code))
The code was modified so that setAttribute() checks for a serializable object before adding it to the session.
When starting several T3 clients on the same machine simultaneously, there was a possibility that two or more of the clients could obtain the same JVMID, cause exceptions or hanging on the clients. The problem occurred only when starting multiple T3 clients on the same machine at the same time. This problem was solved by modifying the code used to generate JVMIDs.
Prior to WebLogic Serve Service Pack 6, all server instances in a cluster used the server listen port as the multicast port for cluster communication. There was no way for a cluster to use a multicast port different from the server listen port.
This Service Pack introduces a new, optional Java property, -Dweblogic.cluster.multicastport= port_number , to specify the multicast port used in a cluster. To use the new property, all cluster members must specify the same -Dweblogic.cluster.multicastport value in their startup scripts.
If the -Dweblogic.cluster.multicastport is not specified at startup time, servers continue to use the listen port as the multicast port for cluster communication.
Prior to this Service Pack release, WebLogic Server did not log a nested exception associated with a deployment error. The logged text indicated only the deployment error, as in:
<Mar 28, 2003 1:10:51 AM PST> <Error> <J2EE> <Error deploying application application_name: Caught IOException for path=path_to_application>
The code was modified to log the nested exception as well as the deployment error itself, as in:
<Mar 28, 2003 1:10:51 AM PST> <Error> <J2EE> <Error deploying application_name: with deployment error Caught IOException for path=path_to_application and nested error java.io.FileNotFoundException: File not found>
A CMP2.0 EJB accessing an Oracle database did not timeout when the database was locked.
The problem was exhibited when running the ejb2.0 cmp example, with trans-timeout-seconds to a non-zero value such as "10", against a locked database table (the table was locked using SQLplus "lock table ejbaccounts in exclusive mode"). When the table was locked, and the client ran, the client hung indefinitely trying to create an account. After the database lock was released using SQLplus, a rollback exception occurred in the client. The rollback should occur when at the end of the transaction timeout.
Analysis revealed that, when the timeout period expired, and the timer sent a TransactionRolledBack message to the database, the database did not release the lock.
The problem was resolved, for the Oracle thin driver, for row-level locks by:
The fix works only for the Oracle thin driver, for row-level locks.
In WebLogic Server 6.1 SP02 and SP04, JDBC connections were not returned to the pool when a transaction was distributed over two server instances. The JDBC attribute KeepXAConnTillTxComplete was set to true . This sequence of events led to the problem:
No error messages were generated. The updates were performed and the message was placed in the JMS queue. However, some connections remained 'in use' in the ejb connection pool. After repeating the sequence of steps several times, the connection pool runs out of connections.
The problem did not occur if the actions are executed on a single server instance, or if the JMS message is placed in the queue outside the transaction scope.
The problem was solved with a code change to release the connection in the aftercompletion callback.
In WebLogic Server 6.1 SP04, a customer reported random generation of the following exception while invoking methods in a particular EJB in his application:
java.lang.ClassCastException: java.lang.String at weblogic.utils.classfile.DoubleKey.equals(DoubleKey.java:24) at java.util.Hashtable.get(Hashtable.java:318) at weblogic.utils.classfile.ConstantPool.find(ConstantPool.java:58) at weblogic.utils.classfile.ConstantPool.getUtf8(ConstantPool.java:251) at weblogic.utils.classfile.expr.ClassInfo.addField(ClassInfo.java:86) at weblogic.utils.classfile.expr.DotClassExpression.code(DotClassExpression.java:34) at weblogic.utils.classfile.expr.InvokeExpression.code(InvokeExpression.java:31) at weblogic.utils.classfile.expr.ExpressionStatement.code(ExpressionStatement.java:19) at weblogic.utils.classfile.expr.TryCatchStatement.code(TryCatchStatement
The problem was corrected with a code fix to the equals() method in weblogic.utils.classfile.DoubleKey.
In WebLogic Server 6.1 SP03 ejbc generated invalid SQL for an ejbSelect query. The query failed because table aliases were generated incorrectly, resulting in this error:
ORA-00904: invalid column name
The problem was corrected with a code fix.
A LockTimeoutException occurred during a test, upon attempt to remove a stateful EJB. The sequence of operations was:
On calling remove the following exception is thrown:
Nov 18, 2002 12:51:33 AM PST> <Info> <EJB> <010049> <EJB Exception in method: remove: weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:LibraryInfoEJB with primary key:85335648642269185 timed-out after waiting 0 ms. The transaction or thread requesting the lock was:Thread[ExecuteThread: '6' for queue: 'default',5,Thread Group for Queue: 'default']. weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:LibraryInfoEJB with primary key:85335648642269185 timed-out after waiting 0 ms. The transaction or thread requesting the lock was:Thread[ExecuteThread: '6' for queue: 'default',5,Thread Group for Queue: 'default'].
at
weblogic.ejb20.locks.ExclusiveLockManager$LockBucket.lock(ExclusiveLockManager.java:449)
at weblogic.ejb20.locks.ExclusiveLockManager.lock(ExclusiveLockManager.java:259)
at
weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java:248)
at weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java
The problem was solved by adding a new weblogic-ejb-jar.xml deployment descriptor element, <allow-remove-during-transaction>. When this element is set to true, the exception does not occur
The following error was thrown during ejb20 home methods tests, on NT with hotspot, and Native IO disabled:
java.lang.IllegalStateException: zip file closed at java.util.zip.ZipFile.ensureOpen(ZipFile.java:377)atjava.util.zip.ZipFile.getEntry(ZipFile.java:138)at eblogic.utils.classloaders.ClasspathClassFinder.getSourcesInternal(ClasspathClassFinder.java:225)at weblogic.utils.classloaders.ClasspathClassFinder.getSource(ClasspathClassFinder.java:155)at weblogic.utils.classloaders.MultiClassFinder.getSource(MultiClassFinder.java:53)at weblogic.utils.classloaders.MultiClassFinder.getClassSource(MultiClassFinder.java:45)at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:303)at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:161) weblogic.rmi.internal.BasicRuntimeDescriptor.getClientRuntimeDescriptor(BasicRuntimeDescriptor.java:526)...
Analysis revealed that the problem was related to uncanceled triggers during undeployment. The following correction solved the problem:
推荐文章
|
|
酒量小的小蝌蚪 · 婚戒物语 - 萌娘百科 万物皆可萌的百科全书 3 周前 |
|
|
跑龙套的蚂蚁 · python找出两个集合中相同的数 - CSDN文库 4 月前 |
|
|
激动的烤地瓜 · Impala查询功能测试-阿里云开发者社区 8 月前 |