I want to upgrade a new version of the application that already running on my glassfish server contain domain with many applications. Before deploying new version, I have to backup the running application so I could restore it when having something wrong. I've found some ways to solve:
Save the application directory, save the domain.xml. When having problem, I will copy these files again to server. So could I re-deploy application by using this way?
Backup & restore domain that have the application. um.. I just only want to upgrade an application.
Any help?
Thanks,
Glassfish has built-in support of application versioning, which is very convenient for upgrade-revert scenarios. It is possible to deploy a new version of the application without removing the old version. You may later revert to the previous version via glassfish console or asadmin utility. Glassfish even supports rolling upgrades - multiple versions of application run simultaneously, new sessions are routed to new version, living sessions are served by old version until none exists and older version is turned off. In this way, users would not experience any down time.
Have a look into the Glassfish documentation on application versioning - Chapter Module and Application Versions.
In short, restrictions when using glassfish versioning:
you must assign a version tag by naming your deployment with version suffix (only new versions need tag, current version can stay untagged)
you must remember which version is the previous one, as more than 2 versions can be deployed (in your case this will be the one without version tag)
remember to backup database and other external resources shared by all versions of the app
I believe that you do not need to back up anything except for the old application archive (WAR, EAR), as with usual deployment, you can always undeploy new version and deploy old version (a restart of the server may be required in between). Backup is necessary only if you need to amend glassfish configuration during deployment (new datasources, security, etc.)
Related
The Problem
I have an Amazon Neptune cluster with an instance running in db.t3.medium DB instnance class. I do not see a choice to move this to the Serverless instance.
How can I migrate this instance?
Root Cause
You can only migrate an instance running Neptune Engine version 1.2 or later.
How to Fix
You need to migrate your Neptune Engine version first to 1.2. Once that is done, you will get the migration option to Serverless.
The engine version is controlled not in the cluster instance but at the cluster level and if you are running an older version of the engine, you may need to incrementally upgrade to from the highest version in the major version group, then move up to the next higher version. If you are running 1.0.x, you will first need to go to 1.1.0 R7 then move onto 1.2.
As with any major version upgrade, you could incur some downtime during migration.
To change the engine version, "Modify" the cluster (not instance) settings (the top right button on the console page) and select the latest possible DB engine version. You can keep the rest of the settings, and you can apply the change to take effect immediately if you can afford to initiate a downtime shortly after. Continue to upgrade to the next higher level until you reach 1.2. Each upgrade can take a while.
is it possible to run Solr 6.4.1 on tomcat?
I read that Solr does not support tomcat anymore, is that true, if yes is there any other option without tomcat?
Yes, any version of Solr from 5 and onwards does not support Tomcat as an alternative officially.
The reasoning for this has been documented on the wiki:
Solr is intended to be a server not a Java web application, similar to mysql or the Apache web server. When Solr was first created, designing it as a web application was a convenient choice, to avoid writing a lot of tricky code to build a network layer. These days, this design decision has become a limiting factor.
When you download Solr and install it onto your machine, it should be Solr that gets started. It should not be necessary to install Solr into a third-party application (servlet container) before it will work.
At this time, Solr is still a webapp, but this is an internal implementation detail, not an immutable property. The intention is to make Solr into a completely standalone application. Startup scripts that start the included container are the first step towards that goal. Jetty might still be the technology used once Solr is a standalone application, but if that happens, it will be internally embedded.
At the moment you can still attempt to run Solr in a different container, as the current version bundles jetty and loads Solr inside jetty, but you can run into unexplainable issues where you'll always suspect the container to be the issue .. and if you have a problem, reporting bugs while running under Tomcat won't do any good.
From one of the comments on the old tomcat page on the community wiki:
If you want to go against recommendations and run 5.3 or later in Tomcat, you can likely still do so, but you will need to inform tomcat about an exploded web application (found in server/solr-webapp) instead of the .war file.
The server/solr_webapp/webapp folder is an exploded web application. Tomcat documentation should be able to tell you how to add such an application.
.. but if you're deploying Solr now, you really shouldn't. Use the bundled version of jetty (which might change to a stand alone version later) and the solr command / script.
They have stopped the support for the same.
Other option could be, you can check out the code and see if you can build the solr. I had tried it for earlier version (3.3).
I am not sure of the current version. But that could be the option for you.
I have posted instructions on how to get solr 6.2 running on Tomcat here. However, these instructions no longer work on Solr 6.3 or 6.4.
Right now i am developing an app on remote DEV server. Every time when i update the code (js,html,css etc) then test on the device locally. There is a popup to force me to update the app. But my app need to connect DEV server for testing some backend feature like login.
DEV server is a remote Websphere running WL6.1 for development purpose. Why i need it because my app connect to some web services like Auth server via internal environment (actually is VPN). And those services i cannot set up easily in local environment. That makes using localhost for development is not really possible.
My problem is feeling the development process not really handy. Every time i change the code and want to run on the devices. I need to upload the .wlapp via console. It takes time! Everyday i change the code thousands time. That's why i need a solution.
And now i am seeking for 2 possible ways:
Auto push the .wlapp to remote server when i run and build. Can ANT do that? i read the Doc and find it's a bit of complicated.
Disable Direct Update. Actually i do a tricky hack inside worklight.js to override this feature. But i think it is not a good solution. So, is there any server config can switch the that off?
And i read this thread IBM Worklight - How to disable Direct Update?
Not working.
From what you are describing, things seem to work exactly as they should.
You have your local Worklight Development Server (that's the Worklight Studio plug-in you've installed in your Eclipse).
You have a remote server - here I am presuming this is actually some application server with Worklight Server deployed on it (that is, not the plug-in, but an actual installation of the server component) as well as your deployed project's .war file.
If that's not your setup, you need to think again about your 'testing setup'.
Auto push the .wlapp file to remote server. So the dev server always
keep the latest resource. Not to force me "update" the older version
on the server.
No. You can't do this. You need to manually build your app with the correct connectivity settings for the remote server via Run As > Build Settings and Remote Target.
In addition to the native project that will now contain these connectivity settings for the actual app, you will also have a .wlapp file in the bin folder. You will need to manually deploy it each time you're changing your app's contents. That's why you do development testing in the local development server... when moving to a remote server, that's for QA/UAT/PROD purposes usually.
Just disable this annoying feature in DEV environment.
You will need to do this in both servers via their respective Worklight Console as described in the question you've linked to, so that once you deploy the .wlapp file, it will not send a Direct Update request.
Instead, you'll need to manually re-install the app each time.
I suspect you didn't do this action on the remote server?
If you did, then you need to explain your setup, as the only thing you've wrote about was its name... "dev".
No. You need to manually deploy the .wlapp to your remote server.
I couldn't find an answer to this in any other questions and I wanted to see if anyone knew. I'm using JBoss AS 7.1 on Kepler eclipse, and I was wondering if there is a way to change your standalone.xml while the server is running and have Jboss push the change. Would just cleaning the server do this?
You can't edit the raw XML files and see runtime changes. In fact there is a good chance any changes will be overwritten by the server.
The best way to make runtime changes is either via the web console or the CLI environment. I don't know if JBoss Tools has any kind of CLI type of client that can be used.
What is the impact on existing code to migrate from WebSphere MQ V6 to V7?
Can we make simply the change?
Like all good questions, the answer here is "it depends."
First of all, don't go to v7.0, go to V7.1 at least, better yet to V7.5.
Using client or bindings mode connections? You can upgrade the QMgr without touching a client-based app in most cases. Any version of WMQ client can talk to any version of WMQ server, however its best not to leave apps on an unsupported version of WMQ client. Of course, the app running on the old client won't get the new function such as automatic reconnect or performance improvements, even though the QMgr is at V7.5.
Using SSL? The SSLPEER element order changed and the commands to manage certificates changed. Good news, cert management is now performed with runmq*km commands living in the {mq install}/bin directory so you don't need to hunt down the GSKit directory and figure out whether to use gsk6*, gsk7* or gsk8* commands.
If you go from 32 to 64 bit, you may need to recompile programs or exits.
Correct settings for PATH, CLASSPATH and LIBPATH change across versions.
There's much more and it's well covered in the Infoceenter. Each Infocenter has a section on migration. Within that section, there's subsections by version and within those there are subsections by platform. Pick the target version of WMQ (that's V7.5, right? Say yes!) and and drill down. Start here:
Migration from V6.0 to V7.5
Migration from V6.0 to V7.1
Migration from V6.0 to V7.0