My application that uses persistent Ehcache gets deployed as an ear file on the weblogic server. The deployment stategy used is the Production redeployment Strategy
(Production redeployment strategy involves deploying a new version of an updated application alongside an older version of the same application. WebLogic Server automatically manages client connections so that only new client requests are directed to the new version. Clients already connected to the application during the redeployment continue to use the older version of the application until they complete their work, at which point WebLogic Server automatically retires the older application.)
Since the Ehcache of the new version application is configured before the ehcache of the older version is shutdown (since the application is still running), the index and data files are not even created and used.
Hence persistence doesn't work.
What could i do to make the cache persistent? I wanted that somehow ehcahche manager stops while deploying new version in weblogic.
Regards
Related
Question: I thought Weblogic and GlassFish / Payara are completely different servers and do not share any common code/component. How come I reached a Weblogic CVE when using Payara?
Configuration: Both our development and production systems are under Payara:
Payara 4.1.1.171.1 Full edition
Oracle Java 1.8.0_144
CentOS 7
Symptoms:
we have illegal connection to url /wls-wsat/CoordinatorPortType11 and wls-wsat/ParticipantPortType, under Anonymous authentication despite having Apache Shiro as security system.
we have an unknown Pyhton program running in our Production. Nothing found in Development so far
Payara Development has shutdown once and one deployment failed ending having Payara stopped (start-domain was required). Payara Production has shutdown once. All of it for unknown reason, especially there were at most one or two users doing nothing special at the shutdown moments
What I can (not) do:
After seeing this and reading this, I think the problems is solved for WebLogic systems but I don't know the mapping GlassFish version <-> Weblogic version, if it exists
Unless I missed a big stuff, I haven't found anything related CVE-2017-10271 and Payara.
We are planning to upgrade to Payara 4.1.2.174 shortly but I have no guarantee it will fix this issue.
I'm trying to check how Shiro can block such connection
I'm asking this question to make sure that there is (or not) no relationship between WebLogic and GlassFish/Payara before opening an issue on Payara GitHub. I unsuccessfully tried to run the python script, I don't know Python :(
I have simple Java Server Faces application deployed on Weblogic server. How I can upgrade the package with zero downtime?
For example can I create cluster of nodes and switch the active nodes or I can do this using only one node?
You can specify a version in MANIFEST.MF and weblogic will transparently switch over to the new version on deployment, waiting for old sessions to close and routing new sessions to the new version.
Bear in mind that certain versions of WLS can't parse the version to a decimal, it will treat it as a string, so unless you want v1.9.6 to replace v1.10.0, just make it a decimal number.
The current app (with a competitor) is using Spring-Boot and Spring-Sessions to save session data independent from the instance in Redis.
How can we replicate this in Bluemix?
Is there a way to add on Spring-Sessions to the Redis service?
The other option would be the IBM Session Cache. Does that work with Spring-Boot and Spring-Session? Does the Session Cache service work without Tomcat? (Jetty for example?)
I haven't played with Spring-Sessions yet, but I might be able to point you in the right direction.
There is a general Redis service available on Bluemix. The open source Java buildpack (Tomcat) promises auto configuration of Redis. I would try this first. To use this buildpack:
cf push <appname> -b java_buildpack
If that doesn't work, you could read the credentials from VCAP_SERVICES and configure JedisConnectionFactory programmatically connect to it.
If you use the IBM Session Cache service with a Liberty application on Bluemix, the configuration is auto generated such that standard JEE HTTPSession objects are persisted to the service. It might work with other java runtimes, but configuration would be more manual.
Hope this helps.
Does the session cache work without Tomcat (Jetty for example)?
In general, the session cache should work with any webserver/servletcontainer, when Bluemix supports Jetty runtime for example, the session cache should support.
Session cache is based on IBM WebSphere eXtreme Scale caching technology, and the base product had been tested against WebSphere, Liberty and Tomcat runtime for the HTTP session use cases, but not tested under Jetty.
I noticed that both options are available while running Jboss, and they both recompile the project (I noticed 'make' running with both). I did see this question, the accepted answer made sense, but I wasn't sure what hot-swapping means. What is a possible example of a change which could be registered without needing to restart the server?
Your question needs more details to answer completely, but here are some basic concepts:
Hot-swapping is simply replacing the files of your project into the deployment folder of the application server (unpackaged, i.e. not the .war/.ear but all separate files). It is usually faster because the change are immediately visible in the web-application. But it is not always possible/supported by application servers, and often if you hot-swap .jar files the application server doesn't pick it up or end up confused.
Restarting JBoss will stop all existing services ( EJBs, Pooling, Queues, Messaging...) and restart them. It is almost the cleanest way to run your application (the cleanest would be un-deploy, restart and deploy)
Redeploy means your application and its services are first removed from JBoss, but other services setup at server level (Messaging, Pools, JMX,... depends on your actual settings) are still deployed. Then the application is deployed (copied from your dev folder or .WAR/.EAR to JBoss webapp)
Typically, you would hot-swap (eventually manually) .(x)html/.jsp/.jsf/images/.js/.css safely as JBoss doesn't need to process them.
Changing code in java classes deployed as .class in a WEB-INF/classes can often be hot-swapped.
Changing code in java files deployed as .jar will almost always need at least redeployment. Some OSGi enabled application server properly configured are more flexible in hot-swapping a complete application (I know Glassfish does but I don't know what specific setting is needed)
Finally, in development, sometimes the multiple redeployments lead to memory leak or unstable application server (often you'll get a OutOfMemory exception in the logs) then you need to cleanup (undeploy, stop, start then deploy)
When running jboss 7.1 as a windows service (or not), it occasionally takes more than one try to successfully deploy a war file. This is not a problem when starting jboss manually since restarts are easy. However, when jboss runs as a windows service and it is restarted automatically (due to a windows patch), jboss itself may launch, but the war may not.
Is there any way to cause jboss to retry deploying the war after it fails the first time - for example, by changing a setting in standalone.xml?
There are to ways to fix your problem.
1) go to standalone.xml (or whatever configuration you are running), find deployment-scanner and add/modify attribute deployment-timeout in seconds
2) Deploy your application as managed deployment, you can do that if you deploy trough admin console or via cli with deploy command. This way deployment will then be "managed" and will always be deployed and wont be using deployment scanner and its timeouts.
I recommend you to use deploy as managed deployment as deployment scanner is not really recommend to be used in production environments as it adds additional IO load on filesystem.
It is great for development / testing scenarios but should be avoided in production if possible.