Currently, we are using Liberty 8.5.5.5 for our product,using Dynamic Routing feature 1.0.It's working pretty well before, but after may be 20 days or long, I am not able to access my web application through http server, after I restarted the http server, back to use.
I found that there are some warning messages in the console.log
Launching controller01 (WebSphere Application Server 8.5.5.5/wlp-1.0.8.cl50520150305-2202) on IBM J9 VM, version pxa6470sr8fp10ifx-20150313_01 (SR8 FP10+IV70681) (en_US)
[AUDIT ] CWWKE0001I: The server controller01 has been launched.
[AUDIT ] CWWKG0028A: Processing included configuration resource: /opt/IBM/WebSphere/Liberty/usr/servers/controller01/collective-create-include.xml
[AUDIT ] CWWKZ0058I: Monitoring dropins for applications.
[AUDIT ] CWWKF0012I: The server installed the following features: [collectiveMember-1.0, ssl-1.0, json-1.0, dynamicRouting-1.0, jsp-2.2, restConnector-1.0, adminCenter-1.0, servlet-3.0, jaxrs-1.1, jndi-1.0, collectiveController-1.0, distributedMap-1.0].
[AUDIT ] CWWKF0011I: The server controller01 is ready to run a smarter planet.
[AUDIT ] CWWKT0016I: Web application available (default_host): http://ifetest.cn.ibm.com:9080/ibm/api/
[AUDIT ] CWWKT0016I: Web application available (default_host): http://ifetest.cn.ibm.com:9080/IBMJMXConnectorREST/
[AUDIT ] CWWKT0016I: Web application available (default_host): http://ifetest.cn.ibm.com:9080/ibm/adminCenter/deploy-1.0/
[AUDIT ] CWWKT0016I: Web application available (default_host): http://ifetest.cn.ibm.com:9080/ibm/adminCenter/explore-1.0/
[AUDIT ] CWWKT0016I: Web application available (default_host): http://ifetest.cn.ibm.com:9080/adminCenter/
[WARNING ] CWWKV0008W: Dynamic Routing service sent 307 response to the client ihsserver13036 because client expired.
[WARNING ] CWWKV0008W: Dynamic Routing service sent 307 response to the client ihsserver13036 because client expired.
[WARNING ] CWWKV0008W: Dynamic Routing service sent 307 response to the client ihsserver13036 because client expired.
Can anyone help me understand this log?
The CWWKV0008W message you are seeing in the log means that the communication between the web server plugin and the Liberty controller is taking longer than expected.
The plug-in keeps an HTTP GET request open to the controller. The controller delivers routing changes to the plug-in as a response to the open GET request. After a routing change has been delivered, the controller expects the next GET request from the plug-in to come within 15 seconds. If the plug-in sends that next GET request after more than 15 seconds, the controller will write the message you are seeing to the log, then ask the plug-in to re-initialize its connection.
This indicates some kind of network problem. If the message is intermittent it will not cause routing selection to fail. If the message is written continuously, you will have to debug network problems.
You can try debugging your problem to get more information about what is happening.
Add the xml element
<TraceSpecification name="default" specification=":DEBUG"/>
inside the
<IntelligentManagement>
stanza of your plugin-cfg.xml.
Information about what the plug-in is doing will be written to the file specified by the 'Name' attribute of the <Log> xml element in the plugin-cfg.xml. ( for example --- Name="/opt/IBM/WebSphere/Plugins/logs/ihsserver/http_plugin.log").
You can also get information about the routing table that is used by the plug-in from the server-status command of the web server.
In httpd.conf, search for server-status. A few lines down, uncomment the line 'Allow from 127.0.0.1'. You can then browse to the server-status page of your web server, if your browser is running on the same host as the web server.
Using the two sets of information might help you to figure out what is causing the routing to fail.
Related
I have 2 war in my server. First starts very rapidly but the second one is longer to start.
My server is able to respond to REST calls when fast one is started but it seems that HTTP endpoint can only be accessed when both applications are started.
Is there a way to control this so that I can respond rapidely to REST calls with first application and let the second application startup in the background.
Yes, check this post - Configure IBM Websphere Liberty Profile Server Start & Stop timeout.
You can set <applicationManager startTimeout="1m"/> setting to tell server not to wait for applications that start longer than timeout. Be aware that any request that comes into an application that is not ready to serve requests will return a HTTP 404 response.
I am trying to capture request & response from an application using Hoverfly. The Hoverfly is installed on a machine and set to proxy with capture mode.
The application is a web application deployed in Weblogic in linux box. The application internally uses soap requests to communicate to a Tibco ESB server and fetch details from provider systems. I want to capture the soap requests & responses between application server & ESB.
To capture the request & response I have set proxy on the application server in following ways:
1) Add the proxy parameters in setDomianEnv.sh script of application server
EXTRA_JAVA_PROPERTIES="-Dhttp.proxyHost=10.0.0.1 -Dhttp.proxyPort=8500 ${EXTRA_JAVA_PROPERTIES}"
export EXTRA_JAVA_PROPERTIES
2) add the proxy parametes in JVM startup parameters of application
3) set proxy for os level user
http_proxy=http://10.0.0.1:8500
In all the three cases I have failed to capture requests & responses in Hoverfly.
Are there any other ways to do the same or any additional settings to be done to route the request & response through the proxy?
That should be sufficient. Is your SOAP service HTTP or HTTPS ? if HTTP this should work. If HTTPS you need to add the self signed Hoverfly certificate to your Weblogic JVM truststore (jre/lib/security/cacerts) to be able to capture those HTTPS requests. Also in case of HTTPS communication, the JVM args should be -Dhttps.proxyPort and -Dhttps.proxyHost
In my opinion, OS level proxy is not required as long as the JVM parameters are set.
Make sure Hoverfly is running and in the Hoverfly Dashboard page, you should set it in Capture mode and when you invoke the services from your Weblogic server, the Capture count in Hoverfly Dashboard should increase. And that's a sign of everything is working.
I have configured spring with web sockets, including rabbit mq on the back end and I can confirm that I can send push messages to the browser.
And using SockJS on the front end.
Up until now I have been using the classic load balancer.
I am trying to get web sockets to work on AWS. I have upgraded to the Application Load Balancer but I still get Bad Request response when I try to make the web socket connection to:
ws://XXXX.eu-west-1.elasticbeanstalk.com/spring/hello/870/sbmdv5tn/websocket
That call still gives 400 Bad Request response...
And I see
Handshake failed due to invalid Upgrade header: null
Errors on the back end...
It has to do the fact that the a connection upgrade is requested and these upgrade requests occur "per hop".
In my scenario I am running with apache in front of tomcat and in order for tomcat to receive these upgrade headers I need to enable web socket tunnelling on the apache proxy such that apache will simply pass through the upgrade request.
UPDATE:
Although a better solution is to bypass apache altogether and go straight to tomcat - that is configure the load balancer to route to port 8080 and not port 80. I suspect the reason elastic beanstalk does not do this by default because it then requires a load balancer - and if you only want single instance you don't need a load balancer.
I have a client/server configuration.
In the client I have an application that talks to the server by http/https withou a browser being used.
I want to know how to configure client and jmeter to record the http requests being send from client to server
The client is a Windows 10 machine.
There can be several options:
Your application has dedicated proxy configuration. In this case just configure it to use JMeter as a proxy
Your application respects OS-level proxy settings. For Windows 10 hit "Win + S" and type "proxy". Perform proxy configuration at all available locations:
If everything goes well you should be able to record your application network activity using JMeter. Refer to How to Run Performance Tests of Desktop Applications Using JMeter for a little bit more detailed information and some troubleshooting steps.
I am taking over an iOS application connecting to the server through a Web socket connection using the Kaazing Websocket (JMS edition) client side javascript library.
I am using Phonegap for my iOS application and be able to test it both on Chrome and the iOS simulator. About 30% of the time I get a connection error from the library testing on chrome and 70% for testing on the iOS simulator/device. I get an Exception being thrown in the minified js library which just say "ConnectionFailedException : Websocket connection failed" Seems like this is a browser specific issue but I cannot do anything further about it.
I can't directly take a look at the server located in the UK but asking them for debug logs. So I asked for the logs from server and these are the errors that I spotted out that might be the reason:
2014-03-05 08:09:23,670 [NioProcessor-15] DEBUG session.revalidate - No WebSocket authorization timeout has been configured, so no revalidate period can be inferred.
2014-03-05 08:09:23,670 [NioProcessor-15] INFO session.revalidate - WebSocket Session [176128] is not being re-validated because no timeout has been specified for the negotiated "x-kaazing-http-revalidate" extension.
Anybody have any idea about this x-kaazing-http-revalidate and if not, what is the proper way to debug these Websocket connection?
Full disclaimer, I work at Kaazing.
x-kaazing-http-revalidate is a Kaazing HTTP extension, negotiated while establishing WebSocket connection. This is done by setting the authorization-timeout in the gateway-config.xml file (the configuration file we ship has an example). The intention of this extension is to periodically revalidate the user's authorization, because entitlements could change over the duration of a long-running connection.
ConnectionFailedException : WebSocket connection failed can occur, if some intermediaries/proxies associated with the service providers inject an unknown or a suspicious header/s in the WebSocket connection request. If the injected header is unknown/suspicious, then Kaazing gateway will not complete the connection, to avoid intruders from eavesdropping. Using a secure TLS/SSL connection should resolve the intermediary related issues.
To debug and to setup a secure javascript client please follow instructions from the documentation. You can also use WebSocket-debug.js instead of WebSocket.js with script tags in the jms-javascript.html file for more logging. There is also a Walkthrough: Deploy a JavaScript JMS App as a Hybrid iOS App.