As far as I know, xmlrpc++ desn't support multithread.
In my program, there is a serious deadlock problem:
two servers A,B. When A call B, before the call reaches B, B makes a call to A. Then deadlock happens. This is because the call is based on tcp and each call is 3-way handshake
Anyone can solve this for me?
thanks a lot
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
methodA in serverA, listening to IP:portA
methodB in serverB, listening to IP:portB
A request comes in IP:portA, makes serverA call methodA. This method should call methodB in serverB.
But at the same time, a different request comes in IP:portB, makes serverB calling methodB and this method should call methodA in serverA.
Is this the scenario you are describing? The method-objects (methodA, methodB) are 'per server' implemented? global objects and later added to the servers? Do methodA and methodB share any code or data? are you programming in windows/unix/linux?
Quique
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Server A makes a request (request 1) to Server B, at the same time Server B makes a request (request 2) to Server A, then deadlock may happen
Because after making request 1, A is waiting B's response, but at the same time, B makes request 2 and also waiting A's response.
Two Servers are both waiting each other's response, that's the deadlock.
Im using linux.
thanks,
Hao
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is this just a 'theorical' question or you implemented it in this way?
I mean, for this stand, you need 2 clients and this 2 servers:
Client1 requests something to do to server A. To do the work, server A needs to call a function in server B
- and at the same time -
Client2 requests something to do to server B. To do the work, server B needs to call a function in server A
Each XmlRpc++ server with corresponding message handling ('connections') is running in a single thread/process, handling messages sequencially. Therefore, both server A and B are waiting for an answer. You are right, the deadlock happens. It does *not* work as a typical daemon that for each connection starts a new process (listen+fork).
If you want to continue with the design, current XmlRpc++ stand is not the correct lib for you. You may use another lib, modify XmlRpc++ lib or change your design.
Quique
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as I know, xmlrpc++ desn't support multithread.
In my program, there is a serious deadlock problem:
two servers A,B. When A call B, before the call reaches B, B makes a call to A. Then deadlock happens. This is because the call is based on tcp and each call is 3-way handshake
Anyone can solve this for me?
thanks a lot
Let me see....
methodA in serverA, listening to IP:portA
methodB in serverB, listening to IP:portB
A request comes in IP:portA, makes serverA call methodA. This method should call methodB in serverB.
But at the same time, a different request comes in IP:portB, makes serverB calling methodB and this method should call methodA in serverA.
Is this the scenario you are describing? The method-objects (methodA, methodB) are 'per server' implemented? global objects and later added to the servers? Do methodA and methodB share any code or data? are you programming in windows/unix/linux?
Quique
Sorry it's not. I mean
Server A makes a request (request 1) to Server B, at the same time Server B makes a request (request 2) to Server A, then deadlock may happen
Because after making request 1, A is waiting B's response, but at the same time, B makes request 2 and also waiting A's response.
Two Servers are both waiting each other's response, that's the deadlock.
Im using linux.
thanks,
Hao
Is this just a 'theorical' question or you implemented it in this way?
I mean, for this stand, you need 2 clients and this 2 servers:
Client1 requests something to do to server A. To do the work, server A needs to call a function in server B
- and at the same time -
Client2 requests something to do to server B. To do the work, server B needs to call a function in server A
Each XmlRpc++ server with corresponding message handling ('connections') is running in a single thread/process, handling messages sequencially. Therefore, both server A and B are waiting for an answer. You are right, the deadlock happens. It does *not* work as a typical daemon that for each connection starts a new process (listen+fork).
If you want to continue with the design, current XmlRpc++ stand is not the correct lib for you. You may use another lib, modify XmlRpc++ lib or change your design.
Quique
Thanks for your reply. Now I solved this problem by spawning a new process for requesting.