Hi *,
Has anyone else noted poor stability with the mi_xmlrpc MI interface? We are noticing that after a while (very little load) it stop responding.
Kind regards Jason
Jason Penton writes:
Has anyone else noted poor stability with the mi_xmlrpc MI interface? We are noticing that after a while (very little load) it stop responding.
there has been reports like that also earlier. i personally have not noticed that.
the library was somewhat hacked when it was include in openser and i don't think it has been upgraded since then.
perhaps sip-router core will have a more robust implementation of xmlrpc server?
-- juha
A brief investigatino shows that there is a problem in serverRun2 function of abyss_server.c
around line 1415, I removed the following 2 lines:
freeFinishedConns(outstandingConnListP); waitForConnectionCapacity(outstandingConnListP);
There seems to be a problem here which locks the server up (bringing it down) - cant even telnet to the port. Without these 2 lines I can successfully have 10 threads continuously bombarding the Kamailio xmlrpc server without error (tested using Jakarta Jmeter).
Will keep the list posted when I come up with new information / more complete solution.
Cheers Jason
On Wed, Apr 1, 2009 at 3:37 PM, Juha Heinanen jh@tutpro.com wrote:
Jason Penton writes:
Has anyone else noted poor stability with the mi_xmlrpc MI interface? We
are
noticing that after a while (very little load) it stop responding.
there has been reports like that also earlier. i personally have not noticed that.
the library was somewhat hacked when it was include in openser and i don't think it has been upgraded since then.
perhaps sip-router core will have a more robust implementation of xmlrpc server?
-- juha
Jason Penton writes:
There seems to be a problem here which locks the server up (bringing it down) - cant even telnet to the port. Without these 2 lines I can successfully have 10 threads continuously bombarding the Kamailio xmlrpc server without error (tested using Jakarta Jmeter).
Will keep the list posted when I come up with new information / more complete solution.
jason,
thank you very much for your effort to fix abyss server code. please send a patch or patch it yourself when you feel comfortable with your changes.
if you have time, it would also be nice if listening ip could be configured.
-- juha
Hi Juha,
No problem, will come up with a clean patch and submit later this week.
Cheers Jason
On Wed, Apr 1, 2009 at 4:12 PM, Juha Heinanen jh@tutpro.com wrote:
Jason Penton writes:
There seems to be a problem here which locks the server up (bringing it down) - cant even telnet to the port. Without these 2 lines I can successfully have 10 threads continuously bombarding the Kamailio xmlrpc server without error (tested using Jakarta Jmeter).
Will keep the list posted when I come up with new information / more complete solution.
jason,
thank you very much for your effort to fix abyss server code. please send a patch or patch it yourself when you feel comfortable with your changes.
if you have time, it would also be nice if listening ip could be configured.
-- juha
On Apr 01, 2009 at 16:37, Juha Heinanen jh@tutpro.com wrote:
Jason Penton writes:
Has anyone else noted poor stability with the mi_xmlrpc MI interface? We are noticing that after a while (very little load) it stop responding.
there has been reports like that also earlier. i personally have not noticed that.
the library was somewhat hacked when it was include in openser and i don't think it has been upgraded since then.
perhaps sip-router core will have a more robust implementation of xmlrpc server?
We reuse sr sip parser for parsing the xmlrpc http requests and then we need only to parse the xml, so sr itself acts as an xml server. This has the advantage that a special route can be used for handling xml messages and one can decide whether or not to accept such a message having all normal config tests at his disposal (e.g. one can allow xmlrpc only on tls and only if some certificate matches or one can forward xmlrpcs to all members of a cluster a.s.o).
However all this is integrated with the "rpc" interface, so it can be used only if you write ser style rpcs instead of the mi functions, or if you write a different xmlrpc mi transport (but since mi future is uncertain I wouldn't do that).
Andrei
Andrei Pelinescu-Onciul writes:
However all this is integrated with the "rpc" interface, so it can be used only if you write ser style rpcs instead of the mi functions, or if you write a different xmlrpc mi transport (but since mi future is uncertain I wouldn't do that).
andrei,
it must be possible to send the request to the proxy using normal xml-rpc client. for example,
c = xmlrpclib.ServerProxy("http://address_of_proxy:6060/RPC2") r = c.pua_publish(uri, 3600, "presence", "application/pidf+xml", etag, "", body)
i didn't understand from your description, if that is possible in s-r.
-- juha
On Apr 02, 2009 at 21:32, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
However all this is integrated with the "rpc" interface, so it can be used only if you write ser style rpcs instead of the mi functions, or if you write a different xmlrpc mi transport (but since mi future is uncertain I wouldn't do that).
andrei,
it must be possible to send the request to the proxy using normal xml-rpc client. for example,
c = xmlrpclib.ServerProxy("http://address_of_proxy:6060/RPC2") r = c.pua_publish(uri, 3600, "presence", "application/pidf+xml", etag, "", body)
i didn't understand from your description, if that is possible in s-r.
Yes, it is.
Andrei
-
Andrei Pelinescu-Onciul -
Jason Penton -
jh＠tutpro.com