Mobile Application Server - Version: 11.5.9 to 12.0.5
BOUNCING THE MOBILE APPLICATION SERVER FOR INDUSTRIAL APPLICATIONS
It is advisable to bounce the Mobile Application Server(s) at predefined intervals, so that active database sessions can be refreshed, and possible defects that might occur due to caching can be avoided.
Solution
Mobile Application Server for Industrial Applications can be used in conjunction with a software/hardware dispatcher for load balancing purposes. In this case, multiple servers are active and bouncing should take care of maintaining continuity of active user sessions; users who are logged in should not loose their connection. Steps required in bouncing can be summarized as follows:
. Start new servers on ports different than currently running servers using the mwactl utility, i.e. "mwactl.sh start port"
. Register new servers with the dispatcher
· Notify the dispatcher to stop accepting new connections for servers that are to be stopped
· Send graceful stop command to each of the servers that are to be stopped using the mwactl utility, i.e. "mwactl.sh -login mfg/welcome -stop port". (Refer to the Installation Guide for more information about shutting down servers gracefully)
When the Mobile Application Server is stopped gracefully, server process does not terminate until current users logout (or zombie sessions timeout). Hence, on a system that has to be up 24x7, Mobile Application Server should be stopped gracefully to provide a transparent transition for active users. As explained in the steps above, dispatcher should be aware of this process, and it should not send new sessions to servers that are being shutdown.
The Mobile Application Server Dispatcher has features to provide smooth transitioning for bouncing. First of all, every Mobile Application Server process that is brought up knows how to find the dispatcher (using mwa.cfg) and registers itself with the dispatcher after a successful start. Likewise, each server notifies the dispatcher as they get a graceful stop signal, which prevents the dispatcher from sending new sessions to these servers. Therefore, bouncing steps can be accomplished by a script, which would start the new servers first, and then stop the old ones gracefully. Since servers that are started should have different port numbers than servers that are in the process of shutting down, this script should also take care of alternating between two sets of port numbers. Please note that the Mobile Applications Server reserves two ports in case of a successful start; specified port (n), and n+1, i.e. if the server is started on port 10252, Mobile Application Server also reserves 10253 for administration purposes (Server Manager Listener is using this extra port), so you can not start another server on 10253. Running this script as a cron job (at specified intervals by the crontab file) would achieve the task of bouncing Mobile Application Servers on a regular basis.
In case of using a hardware dispatcher, each of these steps has to be executed manually. As explained above, after starting the new server, you should add these servers to the dispatcher routing table (Please consult your Dispatcher manual for instructions on how to modify your routing table). Dispatcher routing table should also be modified not to send new sessions to servers that are to be stopped. Finally, you should send graceful stop signals to servers that should be stopped. Once again, these steps can be accomplished by a script, which will run as a cron job.
To give an example, say your business runs 3 concurrent Mobile Application Servers, and you want to bounce these servers everyday at 6:00 a.m. (GMT). In this case you will have to allocate 12 ports ( 2 sets of 6 ports) for the Mobile Application Server. At least 6 of these ports will be active at any time 3 for Mobile Application Servers, 3 for Server Manager Listeners), and all of them will be used at bounce time. Assume the following sets are used: (10252, 10253, 10254, 10255, 10256, 10257) and (10258, 10259, 10260, 10261, 10262, 10263). The first time servers are started, bouncing script can use the first set, so you should be executing mwactl.sh 3 times with the following syntax:
mwactl.sh start 10252
mwactl.sh start 10254
mwactl.sh start 10256
Once again, please note that, 10253, 10255, 10257 will be allocated by these servers! The next morning, you should complete the following steps:
· Start new servers on the inactive set (which is the second set) using the following:
o mwactl.sh start 10258
o mwactl.sh start 10260
o mwactl.sh start 10262
· If you are using the hardware dispatcher, modify the routing tables to register these servers (running on ports 10258, 10260, 10262) with the dispatcher. Remember that, this step is not required if you are using
the the Mobile Application Server Dispatcher.
· If you are using the hardware dispatcher, modify the routing table so that the dispatcher won't accept new connections on the set that is to be stopped (running on ports 10252, 10254, 10256). Remember that, this step is not required if you are using the the Mobile Application Server Dispatcher.
· Stop the servers that need to be stopped gracefully (running on ports 10252,10254, 10256) using the following:
o mwactl.sh -login appsuser/appspassword stop 10252
o mwactl.sh -login appsuser/appspassword stop 10254
o mwactl.sh -login appsuser/appspassword stop 10256
If you want to implement this in a shell script, you can cycle between the port sets by creating a dummy file as follows:
· Check if foo.1 exists, if so remove foo.1, create foo.2 and use port set 2.
· Check if foo.2 exists, if so remove foo.2, create foo.1 and use port set 1
· If both of them do not exist, default to use port set 1
The following sample script illustrates how this can be done.
Note : This script does not check for all possible failures and is forcefully stopping the MWA Servers so logged in users would be disconnected. This should normally be scheduled to run during inactive hours like midnight or on holidays when there wouldn't be active users on the system. TMPDIR can be set to any temporary writable directory location
#!/bin/ksh
export TMPDIR=/usr/tmp
ulimit -n 1024
if [ -f $TMPDIR/foo.1 ]
then
rm -f $TMPDIR/foo.1
touch $TMPDIR/foo.2
#activate servers with port set 2
nohup $MWA_TOP/bin/mwactl.sh start 10258 >> /dev/null 2>&1 &
echo "Starting 10258 server"
nohup $MWA_TOP/bin/mwactl.sh start 10260 >> /dev/null 2>&1 &
echo "Starting 10260 server"
nohup $MWA_TOP/bin/mwactl.sh start 10262 >> /dev/null 2>&1 &
echo "Starting 10262 server"
#stop existing servers
nohup $MWA_TOP/bin/mwactl.sh -login mfg/welcome stop_force 10252 >> /dev/null 2>&1 &
echo "Stopping 10252 server"
nohup $MWA_TOP/bin/mwactl.sh -login mfg/welcome stop_force 10254 >> /dev/null 2>&1 &
echo "Stopping 10254 server"
nohup $MWA_TOP/bin/mwactl.sh -login mfg/welcome stop_force 10256 >> /dev/null 2>&1 &
echo "Stopping 10256 server"
else
if [ -f $TMPDIR/foo.2 ]
then
rm -f $TMPDIR/foo.2
touch $TMPDIR/foo.1
#activate servers with port set 1
nohup $MWA_TOP/bin/mwactl.sh start 10252 >> /dev/null 2>&1 &
echo "Starting 10252 server"
nohup $MWA_TOP/bin/mwactl.sh start 10254 >> /dev/null 2>&1 &
echo "Starting 10254 server"
nohup $MWA_TOP/bin/mwactl.sh start 10256 >> /dev/null 2>&1 &
echo "Starting 10256 server"
#stop existing servers
nohup $MWA_TOP/bin/mwactl.sh -login mfg/welcome stop_force 10258 >> /dev/null 2>&1 &
echo "Stopping 10258 server"
nohup $MWA_TOP/bin/mwactl.sh -login mfg/welcome stop_force 10260 >> /dev/null 2>&1 &
echo "Stopping 10260 server"
nohup $MWA_TOP/bin/mwactl.sh -login mfg/welcome stop_force 10262 >> /dev/null 2>&1 &
echo "Stopping 10262 server"
fi
fi
exit
Regards
Manoj
Source: NOTE:198543.1
Title: How To Rebounce the Mobile Application Server for
Industrial Applications v1.0.8
No comments:
Post a Comment