So, we have two Liberty servers with different versions.
WAS Liberty 16.0.0.2, and
WAS Liberty 17.0.0.2
Both of servers has the same configuration
But, the problem is, even with the same configuration, WAS Liberty version 17.0.0.2 will auto load application context/servlet on start/restart without sending a request to them, while WAS Liberty version 16.0.0.2 will not auto load application context/servlet on start/restart unless we send a request on it.
As per our search regarding this issue. In the IBM Knowledge center, it says that by default Liberty defers servlet loading until a request is received for the associated web application... but in WAS Liberty version 17.0.0.2, it will automatically load the servlet/application context.
Help will be very much appreciated for this one.
Note: we did not add <webContainer deferServletLoad="false"/> in our server.xml
Liberty used to deploy the web application on first request. That was the behaviour in 16.0.0.2. I don’t recall exactly when we changed when we deploy, but we updated to deploy async during startup rather than on first request since a number of people were expecting their servlet inits to be triggered sooner than first request.
Related
I am using springcloud config server to refresh my application properties at the runtime on scheduled basis in production environment. My schedule runs biweekly without any issues.
My application is running on Kubernetes cloud on multiple pods. Pods tends to crash or restart at any moment. What happens in case of pod crash/restart it fetches the latest property file from Config Server and repository at application startup rather waiting for next scheduled refresh cycle.
This lead to inconsistencies across the pods configuration and application behavior.
What I am looking for a strategy to avoid property refresh at the app startup and "Spring cloud config" client to only refresh based on refresh cycle.
Any suggestions to solve above would be greatly appreciate.
You want to use old properties even your application gets restarted so you need to keep old properties detail somewhere. You can not do that in your application as property detail is coming from config server so its better to set refresh rate for config server also how frequent it should pull config detail from git or whatever is your source.
If you set refresh-rate to two week of config server it will contain old property detail only and does not matter how frequent your application restarted it will get old properties from config-server.
I got this problem after deploy worklight app inside websphere. I already follow exactly all these steps carefully without any mistakes.
http://blog.revivalx.com/2014/06/18/deploy-worklight-war-file-into-websphere/
When I try to invoke this URL inside my browser, it throw an error.
Service unavailable since initialization failed.
Already search out the log file, it said like this
[10/2/14 17:46:39:474 MYT] 0000009b Authenticatio E com.worklight.core.auth.impl.AuthenticationFilter isWaitingForInitialization FWLSE0242E: Failed to synchronize application runtime information. The servlet initialization failed and the servlet will deny service. The most common reason is a failure in JMX communication with the ''worklightadmin'' service. You need to restart the web application after fixing the problem. [project xxxxxxxx]
Worklight version
version=6.2.0
fixpack=00
buildNumber=20140613-0730
Websphere version
Webspshere Base v 8.5.5.0
build gm1319.01
First thing first, you are using an outdated version of Worklight 6.2; download the latest studio and server artifacts from IBM Fix Central.
Second, you are using Worklight 6.2, don't follow guides written for 6.1...
Instead, follow the official installation documentation.
Worklight 6.2 contains a new management service that you must take into account when deploying Worklight to an application server, this is not taken into account in the guide you linked to.
From the error message:
The servlet initialization failed and the servlet will deny service.
The most common reason is a failure in JMX communication with the
''worklightadmin'' service
Read carefully the Knowledge Center for 6.2, then try to install.
Also read this: How to solve management service not starting up in Worklight 6.2
My organization is using Websphere Application Server with RAD. My unit is developing Web Services that take data from a consumer, and often pass the data through other Web Services.
Currently, we have two ways of defining time-out's for data to be returned from called services:
Using the Spring framework
Websphere profile configuration
If we need to update the values using Spring we need to re-deploy our service. If we define them as JVM properties we need to do a JVM configuration change and 'restart/recycle/stop and start' the application.
My co-worker had it suggested to him that there may be some better solutions to this problem. I'm wondering if this is true, and if so what they are?
edit:
One option we might be considering is "Application Policy Sets". We'd like to know if this is a good alternative method:
can we define Spring to leverage policy sets
can we define multiple policy sets for an application when timeout values for different services called by our service are different?
Does this console change take affect at run-time, or do we need to recycle?
I suggest you use JAX-WS policy sets and bindings on WAS level, because it allows you to:
define policy set for each web service separately
in policy set define web service parameters, from HTTP transport parameters to WS-Security policies such as UsernameToken, digital signature and encryption
web services remain unchanged, the code remains the same
there is only one place where you change it: in WAS console, application is not changed
The only drawback here is that web services should be generated from RAD (you can use top-down or bottom-up approach).
Please see more details in this excellent 3-part DeveloperWorks tutorial
Liberty Profile is loading EARs and WARs we deploy to it only when the server receives it's first request. How can we tell it to eagerly load applications upon server start?
We're using the latest 8.5.5 WLP.
Thanks,
Stu
You can configure the WebContainer to fully initialize the application prior to the first request by adding the following to your server.xml:
<webContainer deferServletLoad="false"/>
Can a Worklight Server be deployed to a WebSphere application server which also runs other non-Worklight .ear applications? Or does Worklight need its own separate instance of WAS?
Just like you can deploy multiple instances of Worklight (v6 and above) projects - multiple .war files to the same WAS application server, there should not be issues to deploy it to an application server running other services.
That said, possible issues to consider:
When deploying a Worklight project, you will want to enable "application security"
(in the WAS admin console, Security > Global Security). If there are some other web
applications for which application security is undesired, you need a different WAS server
instance.
Setting up, enabling and migrating security
The list of users that can use the web applications are configured through LDAP or
"federated repositories", or similar. If, for Worklight, you need to use a completely
different set of user logins than for the other web applications, then you need to use
multiple "security domains".
Configuring multiple security domains
The machine hosting the application server will probably need memory upgrades...
Deploying the Enterprise Archive (EAR) Using the WebSphere Admin Console
Probably also need to make clear seperation where required:
IBM WebSphere Developer Technical Journal: Co-hosting multiple versions of J2EE applications
Worklight is itself an application running inside a web container, whether that be Tomcat, WAS Liberty, or full WAS. It's essentially a layer running underneath the container to handle requests for Worklight applications, fielding their context root requests. If you create the WAR file for your Worklight app and extract out the deployment descriptor you'll find all the necessary filters and listeners that most other apps would have.
Things like adapters and wlapps are "installed" to this underlying layer, and are merely extracted and stored as whatever was packaged with them, such as the JS and CSS you used to make you app. In fact, with a standard Liberty install you can typically find your adapters in plain sight at (for the WL5.0.6 instance I have handy, it's different for WL6):
/opt/IBM/Worklight/server/wlp/usr/servers/worklightServer/worklight.home/worklight/data/export/adapters
So, in addition to what Idan has said, I also present you with the following docs (assuming WL6)
Overview of the Worklight Server installation process
Given my own experience, you should be perfectly able to install other EAR and WAR files to your existing WAS instance, just make sure your context roots are unique, as always ;)
I also second the memory considerations.