Store Server Online and Offline Concepts
Contents |
Online & Offline concepts of Store Servers
The connection status to the central server controls the 'online status' of a store server. If a central server can be reached and is not overloaded a store server is online, if it can't be reached a store server is offline. If the central server itself is down all store servers are offline also.
Online & Offline State Transitions
An Openbravo Commerce store server can go through several states:
- Online: the store server is connected and can access the central server, all requests from the WebPOS systems are passed through to the central server for processing.
- Transition to Offline: this status is reached when the (store) server notices that it can not reach the central server or the central server is overloaded (see the sensitivity check discussed below). In this status the store server will prevent operation of WebPOS systems. The duration of this status is determined by a preference (Transition to Offline Wait time, default 5 minutes). After this time the store server will do one final check if it is allowed to go offline and if the central server is still not available. If not then the store server will go offline.
- Offline: the store server is offline, requests from WebPOS are processed locally in the store server. The store server continues checking if the central server is available at certain intervals. The interval is determined by the Transition to Online Wait time preference.
- Transition to Online: the automatic/background process detects that the central server is accessible and that the central server is not overloaded. This check is done every Transition to Online Wait time (default 1 hr). If all is fine the online transition handlers are called so that specific functional code can executed to for example send data to the central server. One of the default transition handlers makes sure that all transactions are synced to the backoffice and vice versa before going online. When the online transition handlers are done the store server moves to Online mode.
When the store server is transitioning to online or offline the WebPOS clients are not allowed to perform any transactions. In this case the user is notified and can relog in. Normally the transition period should be short, minutes.
This 'blocking' behavior is by default switched of. To enable it you have to set the preference Multi Server Architecture Enablement to 'Y'. After changing this preference the system should be restarted as it caches the current value.
Central Server Sensitivity Check
The sensitivity check determines if the central server is overloaded. This check is performed on the central server on request of a store server in the following cases:
- when a user request (originating from webpos) via the store server to the central server fails by a process failure, a read time out or a connection time out
- when the store server is offline and periodically checks if it can transition to online.
The sensitivity check is a request from the store to the central server and is executed on the central server. The check compares the number of active database connections with a treshold. The treshold is defined in a preference Database Congestion Threshold which can be set on store level. If the number of active connections is higher than the treshold then the central server is considered to be overloaded. Also if the sensitivity request from the store to central server takes more than 10 seconds it is considered to be offline.
The sensitivity check is repeated at least once if it fails or if the central server is considered to be overloaded. To have the check executed multiple times set the Number of request retries done by the store server to a value higher than 1.
Causes for not going offline
There are several reasons why a store server will not go to offline status even if the central server is not available:
- the central and store server have modules with different versions. The store server source code is not updated.
- there is data pending to be synced from central to store and this data is older than the Maximum Allowed Delta Sync Age preference.
- there are sync errors from central to store
Conditions to transition to online
A store server has a background process which periodically checks if a store server can go online if the store server is offline. The process performs several checks before moving to transition to online status. Only if all the checks pass the system will go to the transition to online phase:
- the Transition to Online Wait Time interval must have passed
- the store server must have received a recent ping from the central server. This is controlled by the Mobile Server Status Ping Periodicity preference (default 5 minute). If the store server has received a ping from central within 3 times this preference then this is considered to be OK.
- all data is synced from central to store and vice versa
- no sync errors in either direction
- the sensitivity check request from store to central passes.
Causes for staying offline
The reasons for staying offline, i.e. failed transition to online are complementary to the checks done before transitioning to online. There can be several reasons that a store server is and remains offline:
- no connection to central server from the store server: this can have several causes, network failure or the central server is not running
- data can not be replicated: the store server will only go online if all its data has been and can be replicated from store to central and vice versa. If there are replication errors then the store server will remain offline.
- the store is in the offline-wait time: there is a new property (Transition to Online Wait Time (seconds), available from 17Q1) which sets this wait time. See this document and check the Transition to Online Wait Time (seconds) property (default is one hour wait time).
The reason for a store server remaining offline can be found in the 'Offline Log/Cause' field in its mobile server window.
If there is a connection between central and store then this field is replicated from the store to the central server and can be checked there. If no connection between central and store then you can check this field in the relevant Mobile Server Definition record in the store server.
Currently 2 types of messages are shown in the offline log field:
- Transition to online failed: the field shows a list of one or more transition handlers with a specific message. For example: SyncStatusOnlineTransitionHandler this server has 1 waiting importentries/synchronization-batches. This last message means that there is 1 import entry to process or 1 batch to be replicated.
- Offline Servers/Checks: shows the central server key which is offline or shows any specific offline-check-handler class.
Transitioning Triggers - Send Transition to Online
Transition to online and offline is triggered by different events.
An online server communicates with the central server frequently for example when creating tickets (in synchronized mode). When the communication fails or the server responds with a server error then the store server will do a check availability request. If that request fails (at least twice) then the central server is assumed to be not available and the store server will transition to offline.
An offline server will test the connection to the central server at regular intervals (see previous section). If the checks to go online all pass the store server will try to transition to online. If the transition to online fails then the store server will move back to offline and wait a certain time period (Transition to offline wait time) before retrying.
Another way to trigger a server to transition to online is to send it a transition to online trigger. This can be done from the central server by going to the mobile server window, selecting the offline server and then clicking the 'Send Transition to Online' button.
Clicking this button will trigger a transition to online (which can fail), depending on the situation the store server transitions to online after a few minutes.