How to run two instances of the same Play! Framework application?

Question

I am trying to run two instances of the same Play application to transparently update the application in the future.

When I start the first instance, everything is obvious. When I run the start 9525 command to start the second instance of the application on port 9525, I get the following error:

 Play server process ID is 8909 This application is already running (Or delete .../RUNNING_PID file) 

Any idea how to get around this?

Answer 1

This document has already described the use of Apache for transparent updates. In general, you need to run two instances in two separate folders

At the beginning:

• Create a dist package inside your application source folder
• Unpack it into a subfolder, i.e. instance1
• Run instance1 on the desired port for example 9998 , this will be your daily instance

After the change, when you want to reinstall the application again:

• Push the changes on the server (assuming that you are using some version control system, i.e. git)
• Create dist and unzip it to the others folder, i.e. instance2
• Run it on another , i.e. 9999
• Stop application in instance1 folder
• Copy unzipped dist from instance2 to instance1
• Run the application in instance1 and stop the application on instance2
• Repeat this procedure every time you need to relocate with new changes.

Of course, creating a simple shell script that will perform all the steps at once will be a great helper for you.

Tip:

To avoid redeployment, especially if you just need to replace / change the contents of the public and static , such as CSS or images, you can also use Apache common vhost to process these resources. Just create vhost for some folder as a subdomain, i.e. http://static.domain.tld or better with a separate domain: http://my-cdn.tld so you can use the following path:

 <img src="http://static.domain.tld/images/photo.png" alt="" /> 

instead

 <img src="/public/images/photo.png" alt="" /> 

Benefits:

• You do not need to update the application to modify these files.
• You do not send cookies that are mostly redundant for public assets (if the vhost domain is not the main project)
• You can use the HTTP server configuration to set cache tags (performance!)
• You automatically exchange statistics between all instances.
• You don’t spend JVM resources on image servicing :) I noticed that although the default server for playback can really be fast, serving static content using a simple HTTP server will probably be faster ...

And finally, in my experience, nginx is faster than Apache. Therefore, if the only task for the HTTP server in your case is balancing the load of Play applications, think that nginx is just easier.