Automatic Version Switch

[skafy]

Hi,

 

I am wondering how could I automaticly switch between releases. For better understanding I will represent idea on example:

There is running standalone server UniGui. People are connected to it and doing something on the website. Then I need to change something and create new release. Situation now is that I can switch releases when there is noone connected to website OR I kill server (and terminate all current sessions) and switch it as fast as possible so people will use new version of the program (website).

Is there a way automaticly switch between versions whitout killing active sessions on server or switchig it when noone is around. Like when I new relase apper newly created session will use new release and  sessions in old relase would normaly use old one until they refresh or reenter website. Older release would stop, when there is newer release is available and when session cound is 0.

 

Any idea?

[wprins]

You can monitor the number of active sessions and auto-restart when no-one is on.  You would then have to build some kind of notification mechanism into your system to allow you to tell your service to restart, or that allows it to notice when a new release has been made.  

 

Further, if you're using a standalone service .exe then you should be able to rename the .exe file while the service is running to put the new build .exe in place prior to this.  So basically, you can try:

 

1) Rename existing service.exe to service.exe.old (or whatever)

2) Notify running service to restart.

3) It monitors sessions and then restarts itself with CreateProcess() or whatever.  (I can probably provide concrete example if needed.)

[skafy]

I see. This can be done yes, but I'm looking for more sophisticated solution. Because in your case, if there would never be 0 session (someone would allways be on (just assuming)) then new version would never take place as active one.

[rvv]

For IIS

I created a file Update.bat

 

net stop "World Wide Web Publishing Service"
copy C:\RVPROG\prog.exe C:\prog.dll
net start "World Wide Web Publishing Service"

[skafy]

This disconnect all connected users right.?

[wprins]

I see. This can be done yes, but I'm looking for more sophisticated solution. Because in your case, if there would never be 0 session (someone would allways be on (just assuming)) then new version would never take place as active one.

 

Well in that case a suggestion would be that you have (at least) 2 instances of your application on 2 separate servers.  You then switch (via DNS, for example) users to using the new version on the "new" server and (eventually) shut down the "old" server after the last user (eventually) comes off or they time out, at which point you can upgrade it also.  

[zilav]

This disconnect all connected users right.?

Sessions are stored on the server in memory including UniGUI's data and data of your application, so yes, it will disconnect all users.

[radiocab]

Try this solution
http://www.eggcentric.com/ISAPILoader.htm

[Abaksoft]

Hello,

Already exists in forum :

http://forums.unigui.com/index.php?/topic/7370-isapi-hot-update/?view=findpost&p=37548&hl=isapiloader

 

http://forums.unigui.com/index.php?/topic/4536-isapi-deployment-with-in-place-dll-replacement/?hl=isapiloader

 

http://forums.unigui.com/index.php?/topic/2681-is-there-any-difference-with-performance-between-unigui-standalone-exe-server-and-unigui-dll-modewith-apache/?view=findpost&p=12378&hl=isapiloader

[Farshad Mohajeri]

Actually, it can not be done in uniGUI. Not only in uniGUI but also in all similar technologies. Problem here is that session states are stored in memory and reloading DLL will reset all data in memory. Hence all available sessions will be terminated.

[skafy]

Ok tnx everybody! I know it seems impossible, but i'll still going to make something. Maybe sth like @wprins suggested. Will update my results.

[herculanojs]

Hi,

 

I am wondering how could I automaticly switch between releases. For better understanding I will represent idea on example:

There is running standalone server UniGui. People are connected to it and doing something on the website. Then I need to change something and create new release. Situation now is that I can switch releases when there is noone connected to website OR I kill server (and terminate all current sessions) and switch it as fast as possible so people will use new version of the program (website).

Is there a way automaticly switch between versions whitout killing active sessions on server or switchig it when noone is around. Like when I new relase apper newly created session will use new release and  sessions in old relase would normaly use old one until they refresh or reenter website. Older release would stop, when there is newer release is available and when session cound is 0.

 

Any idea?

 

Its application is standalone ?

[Ron]

Problem is that with a single server, you cannot discriminate between sessions/users,

and either keep'em all or kill'em all.

 

Waiting for all to be inactive may take forever.

 

So you then basically need one server for each user, and then you can upgrade only

those who are not active.

 

You could setup a system which spawns a new server for each user, and then another

update system to kill the right servers for upgrade at first inactive - but that is quite complex.

 

The goal is to upgrade without losing the session and thus disconnecting the user.

 

What about using two applications, where one is a shell application which is not

updated, but only keeps the session - and then another main application which

gets updated?

 

That may be possible, two DLL's served by one server, using the ISAPI loader to update

only one of them, and as the second app session terminates the user is directed to

the first app, which then loads the second app after update...as it also loads the second

app after login, and the user is all the time having the shell app session alive.

 

But to do upgrades on an individual basis, requires separate servers. It is the nature

of the issue, as individual and group are two separate domains, and cannot be joined.

[Ron]

Let's say I have an Apache or IIS main server, where the user logs in.

 

At login I then execute a standalone server at a different port, serving

the main application - one such standalone for each new user.

 

As an upgrade is available by timer->db/filecheck, the user is served a notice in

the app, having the option to upgrade, which then kills the standalone

server, routes the user back to the main login app which keeps the

session, and creates a new standalone server based on new exe,

again serving the secondary app to the user.

[herculanojs]

I am using standalone because of practicalities. I made the update process based only on the application's own executable.

 

I have developed an updater that is responsible for downloading the updates, downloading them on the server and creating an update information file that the application monitors from time to time, and when authorized to update and reload the application.

 

When update is available, all active sessions are alerted that update is available, and delimit a time when all sessions will be closed to proceed with the update.

 

The application is then monitoring through a team, if there is still active session. If there is no active session, or the update time has been exhausted, it immediately calls the update process.

 

---

Estou utilizando standalone por questões de praticidades. Fiz o processo de atualização baseado apenas no próprio executável da aplicação. 

 

Desenvolvi um atualizador que se encarrega de fazer o download das atualizações, baixá-las no servidor e criar um arquivo de informação de update que a aplicação monitora de tempo em tempo, e quando autorizado efetua a atualização e recarrega a aplicação.

 

Quando é detectado que há atualização disponível, é alertado à todas as sessões ativas que há atualização disponível e delimito um tempo em que todas as sessões serão encerradas para prosseguir com a atualização.

 

O aplicativo fica então monitorando através de um time, se ainda há sessão ativa. Não havendo sessão ativa, ou o tempo para atualização tenha sido esgotado, ele imediatamente chama o processo de atualização.

[Ron]

I've made a test project according to the idea I mentioned above, download

at http://s000.tinyupload.com/index.php?file_id=26843721044701981814

 

It contains two projects, one loginapp and one mainapp.

 

At login, a new standalone server will be created, on a new port.

 

The mainapp standalone exe's are located under the loginapp folder,

in separate dirs, with the dir name indicating the version.

 

At update, control will return to the login app, and the running process will

be killed and a new standalone server process created, on the new

exe available in the new dir.

 

The drawback is that the main apps will all be standalone servers, but there

will be one for each user, so there should really not be any resource issues

as long as the server box keeps up.

 

Hard to say what is more stable: x threads in an Apache/IIS container

or running them directly under the operating system as separate processes

like this.

 

But here you can at least get individual updates, where anyone can update

when they want to on an individual basis - think I will try it out.

[Ron]

Well, I was able to setup a system according to this idea mentioned above,

and test it on a live server with apache, but the problem was the loading time

of a new standalone server: 15 seconds from login vs 5 secs using a single dll.

 

I used a login.dll running under apache, which spawned a new standalone unigui server

for each logged in user: it executed the exe on a new port for each user, by running the

apache on a user with network resources access privileges. So that worked.

 

Uplading a new version of the standalone exe worked fine too, with setting the

firewall rule for the file, opening up for all ports.

 

But due to the extended loading time, 15 secs vs 5 secs when using a dll, this will

probably not work so well.

 

But I kind of liked the idea of separating the login from the main application,

as you then get very fast loading time of that small login app, and it provides

a small waiting spot for the user while redirecting to the new active updated app,

informing of what is happening.

 

I found a working compromise: use one login app, and two main apps,

where one is the active at any time.

 

At update, one dll is updated and set to active, and the main apps

notice that, and inform the user of the option to update.

 

At update, the user is kicked back to the login app, but I have an extra

session layer with the session key in the url param, and this gets picked

up by the login app which sends the user over to the new active mainapp dll.

One could use cookies instead of such an extra session layer.

 

This way users may switch to the new active app individually, and I have

separated the login from the main app.

 

From login to main app load, I give the main app 5 seconds to confirm

the new session key in the db, and it is valid for 12 hours, from that public IP.

 

So this is possible, with three DLL's, one for login/session control, and

two main apps where one stays active at any time, making the other available

for updating.

 

Maybe this could be done even without a login app, and use the webserver

to direct the user to the active app, using a url rewrite based on some data

from the file system or the db, setting the url of the active app.