Tag Archives: jboss

Wildfly (JBoss) startup error: ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation (“add”) failed

Error content:

15:07:50,724 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MESwell.ear")]) 
- failure description: "WFLYCTL0212: Duplicate resource [(\"deployment\" => \"MESwell.ear\")]"

15:07:50,728 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.

 

Error reporting scenario:

This error occurs when I start it normally for the first time, and then turn it off. When I start it for the second time, it will fail to start. Many answers were searched on the Internet, but they failed. Later, I found this answer:

[wfcore-495] wfly won’t startup due to “wflyctl0212: duplicate resource [(\” deployment \ “= & gt; \” XXX. War \ “)] – red hat issue tracker

Through this answer, I know that it must be related to the nonstandard start-up operation of my second time. The nonstandard start-up led to the existence of the cache started last time. Then I searched wildfly how to clean up the cache.

 

Here is the Solution:

1. Find the package you put under \wildfly-10.1.0.Final\standalone\deployments\, check its startup status, and delete the files generated after the startup failure. (It seems to be fine without cleaning up)

2. Delete all files under \wildfly-10.1.0.Final\standalone\data

3、Go to \wildfly-10.1.0.Final\standalone\configuration and find your standalone.xml

Search for deployment, find a string of tags like the following generated, delete!

4. After executing the appeal operation, check whether the above three steps are not clear and clean

5. Restart your wildfly (JBoss)

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.

SSL appears when Firefox accesses HTTPS_ error_ weak_ server_ ephemeral_ Dh_ Key error

The above error will occur if the company website is accessed using Firefox and Samsung devices using HTTPS. The certificate is really bought. The following method works. From http://www.cnblogs.com/milton/p/4624559.html

The following error occurred when ff visited a self-signed internal website
SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message. (Error code: ssl_error_weak_server_ephemeral_dh_key)
Tomcat is used by the server. The solution is to modify Tomcat /conf/server.xml, change the configuration, and add sslEnabledProtocols and Ciphers

<Connector protocol="org.apache.coyote.http11.Http11Protocol"
     port="9443" minSpareThreads="5" maxSpareThreads="75"
     enableLookups="true" disableUploadTimeout="true"
     acceptCount="100" maxThreads="200"
     scheme="https"
     secure="true" SSLEnabled="true"
     keystoreFile="/home/tomc/apache-tomcat-7.0.33/conf/server.keystore"
     keystorePass="111111"
     clientAuth="true"
     sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
     ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"
     URIEncoding="UTF-8"/>

soapUI Error Loading WSDL

background
Because the code changes, party a is to test their code, let me here to deploy a test environment, good let them to test,
I for convenience, copy a copy of the code on the server will be directly from the production, all configuration is changed to test the configuration, on the test server.
Error showing
results as soon as soapUi tool was tested, an error was reported. Error Loading WSDL

Analysis:

network problems?
but I use Telnet 192.168.4.9:8080 port is through, indicating that there is no problem with the network.

security configuration problem?Since the code is copied from the server, there is no reason why it cannot be run. The only difference is between the test server and the production server. What security configuration has the test server done?Asked colleagues, it seems that there is no special configuration, so I could not access, baidu online, to see if there is the same problem, sure enough, but they changed a tomcat Web.xml auth attribute to false, it can be passed. But I am jboss, how can I find this configuration

tool problem?Starts loading the WSDL file on the production server and shows that it loads normally. Obviously not?

local debug?
local deployment setup, local is normal, that is the program itself is no problem.

finally I couldn’t figure it out. I went to the server log and found that there was an error in the server log, that is to say, the project I deployed did not start successfully. Reported a mistake like this.
[D:\ jboss-4.2.3.ga \server\default.\deploy\lbsp_service.war] -choose unique values for the ‘webAppRootKey’ content-param in your web.xml files!

final reason: the test server has many projects, when deploying many projects, the project has a content web.xml needs to add this item:

  <context-param>
<param-name>webAppRootKey</param-name>
<param-value>webapp.root</param-value>
</context-param>

With this addition, the project is normally deployed. The interface has been successfully accessed. Or carefully check the jboss log folder of the log, some errors, just a flash, you do not know whether there is an error. Also, some errors are likely to appear in the log file and not printed in the console, which can mislead you about errors.