Currently i am working with Legato IPC in [async], So i have client and server in two different applications , where the client binds to the server, till now everything is OK and the client managed to connect to the server.
The question is what if the server crashed, do the client will crash too, i did a simple demo by restarting the server using “app restart” command with “faultAction=restart” for both client and server, so when the server restart the client will restart too
-Does the demo is valid and it simulating a crash ?
-Do we have something in legato to prevent the client from crashing if the server crashed ?
-For Async what if the server is blocked (eg. deadlock) do we have any timeout so the client shall not be blocked if the server is blocked?
have you tried other value of faultAction and see if there is improvement?
But it might be normal as if the server crashes, the function call in client is pointing to an invalid address, so restarting the application can restart those IPC
The client is not binding to one server, it binding to others , so if one server crashed this doesn’t mean that the client will stop its functionality, it can continue working reading data from others
Example
If we are in smart home application, the server responsible for temperature crashed, that does not means that the whole smart home application being crashed, it can read other data from other sensors and so on, notifying the client allow it to have a recovery plan for example take the last valid value or any alternative
I found interface called “SetServerDisconnectHandler” but still don’t know how to use it, so do you have any other alternative
also another questions related to Async-IPC
If the server blocked or stuck during serving clients requests , and the client still waiting for the request to be handled, how the client can recover and not to be waiting too much time
you can do it in another way.
By creating different client applications to collect sensor data and creating a server application to just collect the sensor data, in this way, your server should not have chance to crash.
Even there is crash in client app, i believe other app can still be running
I am already used this application and it worked fine, but this application is synchronous mode which is different from my case
For example
We have multiple clients requesting functionalities in server async mode, due to any reason in the server, it became not responsive [eg. deadlock or waiting for resources], in this case the client will be waiting till the server respond, which leads to deadlock, the client waiting for the server and the server cannot handle due to waiting for resources
The concept of the callback to notify the client understood but the case that the server is stuck, how the client can stop waiting in Async-Server mode
This is example from legato framework, please focus on two directories [CAsyncServer and CClient] and their adef file “test_IpcC2CAsync.adef”
The client is testing multiple functions, we can focus on “TestServerExit”, the scope of the test is to abort the server and the client shall detect the server crashing and to handle it self by not being crashed and to wait until the server recover again
So in the code below the client will detect the server crashing through “ipcTest_SetServerDisconnectHandler” when this handle is called on server crash, the handler will jump again and try to connect to the server
So for this problem i see maybe this solution is enough and it is provided by the framework
but
Another solution required is how to handle incase the server did not crash but their was too much requests in the queue
For example
The Server working in Async mode but their was too much requests, so one of the client shall not wait too much time and need to continue execution, how it can be handled
I check the code of IPC_step4.rar, it says it is using async message.
Can you comment on this why you cannot use this?
If you don’t want to wait server finishing the job, i think you need to use the idea of IPC_step4.rar
Btw, have you tried to setup a thread to handle another job in server side?
In this case, the server will not hold the client and can return the value by using the idea in IPC_step4.rar
That’s why the IPC_Setp4.rar is not working as async, and i attached another example from legato
In the async server mode, The server push the client’s requests to the event loop message queue and the client shall wait until the event loop return back to the client
One thing I don’t understand here:
according to the description of async IPC, it is to address this problem so that client will not be blocked.
But if you still find this problem, then what is the advantage of using async IPC?
And why did you still use async IPC instead of the idea of ipc_step4.rar which is using async message?
