Tag Archives: weblogic

When a system is deployed on weblogic12.2.1.3, it reports an error “IllegalStateException zip file closed”. When it is deployed on weblogic12.2.1.2, it does not report an error and can be accessed normally.

Problem phenomenon

When a system is deployed on weblogic12.2.1.3, it reports an error “IllegalStateException zip file closed”. When it is deployed on weblogic12.2.1.2, it does not report an error and can be accessed normally.

Problem analysis

You can find the clear reason on the official website through the error report. The main reason is a bug in Weblogic. Because the application jar file is closed silently due to inactivity, because the jarfile class implements the autoclosable interface, and jarurlhandler does not handle this exception at present, this error is reported. Therefore, it is repaired through patch 27774698. The repair principle is to add a catch block to handle exceptions, And reopen the jar file when there is an IllegalStateException.

In addition, the official suggestion is to apply this patch only when reporting this error. It is not necessary to apply this patch to every system.

Problem continuation

       The above problems are solved by patching 27774698, and the deployment application reports an error error creating bean with name ‘wsrmsafregistrationservice’. After that, you can see that spring is initializing bean and wsrmsafregistrationservice in the log, but its full class name is com.oracle.webservices.impl.wls.wsrmsafregistrationservice, which is used internally, @ inject @ named (“safserverservice”), private SAFServerService safServerService; Therefore, when spring does autowire automatic link, it scans the classes inside Weblogic. This scanning should not occur. Therefore, spring autowire filter should be added to the code to avoid scanning the classes inside Weblogic. For the specific adding method, see the official website link doc ID 2397321.1.

Problem handling

       The problem of “IllegalStateException zip file closed” is solved by patching 27774698. After the application code is changed and the spring autowire filter is added, the application is successfully deployed and can be accessed normally. This problem is solved!

Weblogic Deployment Error: The most likely cause is an error in the network configuration of this machine.

The most likely cause is an error in the network configuration of this machine when deploying Weblogic in Linux environment; As shown in the following figure:

solution: VI enter/etc/hosts and configure your current login host name; (it’s better to switch to the root account for modification here)

view the host name, as shown in the following figure:

Schema validation error in conig/config.xml. See the log for detais, Schema validation can be……

The problem of config.xml when Weblogic gives an error prompt when activating changes is related to the parameter dweblogic. Configuration. Schemavidationenabled = false

terms of settlement:

You need to add this parameter to the startweblogic. Sh file

The path is: install path/xdomain/bin           Modify startweblogic. SH in the directory as shown in the figure below

Then restart

If it is clustered, each server should be configured and then started. Otherwise, the same problem may occur

java.lang.Throwable: Substituted for the exception com.bea.xml.SchemaTypeLoaderException which lack

Weblogic error message:

 <Error> <Console> <AdminServer> <[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'> <webuser> <> <> <1624366734323> <BEA-240003> <Administration Console encountered the following error: weblogic.management.provider.UpdateException: [Management:141191]The prepare phase of the configuration update failed with an exception.
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.updateDeploymentContext(RuntimeAccessDeploymentReceiverService.java:777)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doUpdateDeploymentContextCallback(DeploymentReceiverCallbackDeliverer.java:147)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.updateDeploymentContext(DeploymentReceiverCallbackDeliverer.java:28)
        at weblogic.deploy.service.internal.statemachines.targetserver.ReceivedPrepare.callDeploymentReceivers(ReceivedPrepare.java:203)
        at weblogic.deploy.service.internal.statemachines.targetserver.ReceivedPrepare.handlePrepare(ReceivedPrepare.java:112)
        at weblogic.deploy.service.internal.statemachines.targetserver.ReceivedPrepare.receivedPrepare(ReceivedPrepare.java:52)
        at weblogic.deploy.service.internal.targetserver.TargetRequestImpl.run(TargetRequestImpl.java:211)
        at weblogic.deploy.service.internal.transport.CommonMessageReceiver$1.run(CommonMessageReceiver.java:457)
        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:553)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:263)
Caused by: java.lang.Throwable: Substituted for the exception com.bea.xml.SchemaTypeLoaderException which lacks a String contructor, original message - XML-BEANS compiled schema: Could not locate compiled schema resource schemacom_bea_xml/system/s0BC706AE0F5CDA9F4183EB0C5C434EEA/keystores8f60elemtype.xsb (schemacom_bea_xml.system.s0BC706AE0F5CDA9F4183EB0C5C434EEA.keystores8f60elemtype) - code 0
        at com.bea.xbean.schema.SchemaTypeSystemImpl$XsbReader.<init>(SchemaTypeSystemImpl.java:1519)
        at com.bea.xbean.schema.SchemaTypeSystemImpl.resolveHandle(SchemaTypeSystemImpl.java:3505)
        at com.bea.xml.SchemaComponent$Ref.getComponent(SchemaComponent.java:113)
        at com.bea.xml.SchemaType$Ref.get(SchemaType.java:872)
        at com.bea.xbean.schema.SchemaParticleImpl.getType(SchemaParticleImpl.java:194)
        at com.bea.xbean.validator.Validator.beginEvent(Validator.java:389)
        at com.bea.xbean.validator.Validator.nextEvent(Validator.java:241)
        at com.bea.xbean.validator.ValidatingXMLStreamReader.validate_event(ValidatingXMLStreamReader.java:581)
        at com.bea.xbean.validator.ValidatingXMLStreamReader.next(ValidatingXMLStreamReader.java:546)
        at com.bea.xbean.richParser.XMLStreamReaderExtImpl.next(XMLStreamReaderExtImpl.java:1122)
        at com.bea.staxb.runtime.internal.MarshalStreamUtils.advanceToNextStartElement(MarshalStreamUtils.java:120)
        at com.bea.staxb.runtime.internal.UnmarshalResult.advanceToNextStartElement(UnmarshalResult.java:830)
        at com.bea.staxb.runtime.internal.ByNameUnmarshaller.deserializeContents(ByNameUnmarshaller.java:57)
        at com.bea.staxb.runtime.internal.AttributeUnmarshaller.unmarshalIntoIntermediary(AttributeUnmarshaller.java:47)
        at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.unmarshalElementProperty(LiteralUnmarshalResult.java:184)
        at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.extractAndFillElementProp(LiteralUnmarshalResult.java:156)
        at com.bea.staxb.runtime.internal.ByNameUnmarshaller.deserializeContents(ByNameUnmarshaller.java:67)
        at com.bea.staxb.runtime.internal.AttributeUnmarshaller.unmarshalIntoIntermediary(AttributeUnmarshaller.java:47)
        at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalBindingType(UnmarshalResult.java:199)
        at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalDocument(UnmarshalResult.java:169)
        at com.bea.staxb.runtime.internal.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:67)
        at weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(MarshallerFactory.java:150)
        at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:327)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.handleConfigTreeLoad(RuntimeAccessDeploymentReceiverService.java:1092)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.updateDeploymentContext(RuntimeAccessDeploymentReceiverService.java:697)
>

Because SSL is configured in Weblogic, an error is reported during activation. There is a cluster in the project, and this error occurs,

solve:

Stop the server services corresponding to other cluster nodes, and then modify and activate them. At this time, the changes can be activated normally.

If one node is configured in the cluster, other nodes need to be configured.

Weblogic heapdump configuration

The previous week, Weblogic in the production environment went down twice in a row and had to go back to log analysis on Sunday.
However, because the memory parameters are not configured with GC parameters, the HeapDump file before the crash was not generated. So you still need to configure the GC parameters to find the root of the problem next time.
 
Configuration memory parameters method, didn’t find in Weblogic console where you can configure the memory parameters, the method of directly only directly in bea/user_projects/domains/domain/bin/setDomainEnv. Sh on increase
“+ PrintGCDetails – – XX: XX: + PrintGCTimeStamps – XX: XX: + HeapDumpOnOutOfMemoryError – + HeapDumpOnCtrlBreak Xloggc: $$. Gc. Log”
 
The configuration is as follows:

 
GC – XX: + PrintGCDetails: used to track system details;
– Xloggc: $$. Gc. Log: will the gc event every time the record to a file.
-XX:+PrintGCTimeStamps: can be mixed with -XX:+ printGC-XX :+PrintGCDetails :11.851: [GC 98328K-& GT;93620K(130112K), 0.0082960 secs]
– XX: + HeapDumpOnOutOfMemoryError: the JVM when abnormal OOM to Dump the memory image file
– XX: + HeapDumpOnCtrlBreak: said can kill 3 & lt; pid> Generate DUMP files as needed
 
But pay attention to:
Oracle JVM version 6.0 removes the -xx :+HeapDumpOnCtrlBreak parameter. If you need to generate DUMP files, use the Jmap command. The command line format is as follows:
Jmap – dump: the format = b, the file = managed1_heapdump. Hprof & lt; pid>
Managed1_heapdump.hprof represents the name of the generated DUMP file and PID represents the Java process number.
 
 
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
 
The resulting.hprof file USES the HeapAnalyzer tool, an analysis tool for HeapDump, a memory text image of the IBM JDK.

Error code:10053

Symptoms:
Action.c(16): Error : socket0 – Software caused connection abort. Error code : 10053.

 

normal C/S communication process is :
Server Listen–>

Server Listen–> Client Connect–> Server Accept –> Client Send –> Server Recv–> Client Close –> Server Close
if you do not take the initiative to Close the connection and direct to withdraw from the Client end, Server end service thread will cause a 10053 error (this kind of error usually effect is not too big), and if in the process of the communication Server first initiative to Close the connection, the Client end can also cause a 10053 error

the situation of the bad network is usually refers to the latter, the Client thought the Server off (the actual network broken), so I cried. “10053

Recently, when I used LoadRunner to conduct the performance test of Winsock protocol, the WebServer tested was JBoss, and 10053 errors often occurred. The phenomenon was as follows: after I created the connection with lrs_create_socket, when the number of requests for this socket connection reached 100, the connection was not available, and it had to be closed before creating again. LoadRunner causes Connection abort. Error code: 10053. LoadRunner causes Connection abort.
After much exploration, it was finally found that the error was due to the configuration of the HTTP 1.1 KeepAlive parameter in Apach HTTPServer. From my test results of several different Webservers, it can be seen that JBoss and Tomcat made errors when a Socket connection made 100 requests, while other Web servers, such as IIS and WebLogic, did not have this problem.
several related parameters are described below: KeepAlive, KeepAliveTimeout, and MaxKeepAliveRequests.
KeepAlive Directive
Description: Enables HTTP persistent connections
Syntax: KeepAlive On|Off
Default: KeepAlive On
Context: server config, virtual host
Status: The Core
Module: the Core
In HTTP 1.0, a connection can only transfer one HTTP request, while the KeepAlive parameter is used to support the one connection, multiple transfers feature of HTTP 1.1, so that multiple HTTP requests can be passed in one connection. Although only newer browsers support this feature, this option is enabled anyway.
The keep-alive extension to HTTP/1.0 and The Persistent Connection feature of HTTP/1.1 provide long-lived HTTP sessions which allow multiple requests to be sent over The same TCP Connection.In some The Keep Alive Extension to HTTP/1.0 and The Persistent Connection feature of 1.1 provide long-lived HTTP sessions which allow multiple requests to be sent over The same TCP Connection.In some cases this has been shown to result in an almost 50% speedup in latency times for HTML documents with many images. To enable Keep-Alive connections, set KeepAlive On.
For HTTP/1.0 clients, keep-alive Connections will only be used if they are specifically required by a client. In addition, A keep-alive connection with an HTTP/1.0 client can only be used when the length of the content is known in advance. This implies that dynamic content such as CGI output, SSI Pages, And server-generated Directory listings will generally not use keep-alive Connections to HTTP/1.0 clients.for HTTP/1.1 clients, persistent connections are the default unless otherwise specified. If the client requests it, chunked encoding will be used in order to send content of unknown length over persistent connections.
— — — — — — — — — — — — — — — — — — — — — —
KeepAliveTimeout Directive
Description: Amount of time the server will wait for subsequent requests on a persistent connection
Syntax: KeepAliveTimeout
Default: KeepAliveTimeout 15
Context: server config, virtual host
Status: Core
Module: Core
KeepAliveTimeout tests the time between multiple request transfers in a single connection. If the server has completed one request but has not received the next request from the client, the server disconnects after the interval exceeds the value set by this parameter.
The number of seconds Apache will wait for a subsequent request before closing the connection. Once a request has been received, the timeout value specified by the Timeout directive applies.
Setting KeepAliveTimeout to a high value may cause performance problems in heavily loaded servers. The higher the timeout, the more server processes will be kept occupied waiting on connections with idle clients.
— — — — — — — — — — — — — — — — — — — — — —
MaxKeepAliveRequests Directive
Description: Number of requests allowed on a persistent connection
Syntax: MaxKeepAliveRequests Number
Default: MaxKeepAliveRequests 100
Context: Virtual host
Status: Core
Module: Core
MaxKeepAliveRequests is the maximum number of HTTP requests that can be made with a single connection. Setting its value to 0 will support an unlimited number of transfer requests within a single connection. In fact, no client requests too many pages in a single connection, and usually the connection is completed before this limit is reached.
The MaxKeepAliveRequests directive limits the number of requests allowed per connection when KeepAlive is on. If it is set to 0, unlimited requests will be allowed. We recommend that this setting be kept to a high value for maximum server performance.
For example:MaxKeepAliveRequests 500
Finally, although this problem was caused by the parameter configuration of HTTPServer, only LoadRunner would have had this problem, and if Rational Robot had implemented the same functionality, it would not have had this problem, presumably due to the testing tool’s implementation strategy for Socket connections.