[yast-devel] Timeout problem in SCR DBus service
Hi all, Klaus has noticed that it takes quite long time to process requests by the SCR DBus service. I have noticed that in the past too but I didn't pay attention to this, I thought that DBus is so slow... Now I have found the problem: connection.setTimeout() in Yast calls dbus_connection_read_write() function which should wait for an incoming DBus message or timeout (after 5 seconds in this case). But for some reason (a bug?) it does not return immediately when a DBus _signal_ message is received, it times out instead. Unfortunately two signals are sent by DBus itself automatically at service startup (signal NameAcquired from interface org.freedesktop.DBus). So there is a delay 2*timeout which means 10 seconds in this case :-( The fix is quite simple - try reading from DBus and if there is no message _then_ call dbus_connection_read_write() function to wait for an message. With this patch the signals at start up are read immediately from the input queue. See the attached patch. Klaus, Schubi, please test the patch, I'd like to submit it to RC4 on monday... -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/
* Ladislav Slezak
Hi all,
Klaus has noticed that it takes quite long time to process requests by the SCR DBus service. I have noticed that in the past too but I didn't pay attention to this, I thought that DBus is so slow...
Now I have found the problem: connection.setTimeout() in Yast calls dbus_connection_read_write() function which should wait for an incoming DBus message or timeout (after 5 seconds in this case).
Actually, I wonder why this timeout is needed at all. DBusServer.cc implements a 'busy' loop, iterating on each received message or after a timeout. So with a 5 sec timeout, you run the loop every 5 seconds (at least). But I fail to see the value in this.
Klaus, Schubi, please test the patch, I'd like to submit it to RC4 on monday...
I will try your patch over the weekend and will also test with 'no timeout' (passing a -1 value). Thanks for looking into this ! Klaus -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Klaus Kaempf wrote:
* Ladislav Slezak
[Feb 06. 2009 17:48]: [...] Actually, I wonder why this timeout is needed at all.
The service needs to be terminated after some time. You definitely do not want to have a running Yast in the background forever. (Well, it's not complete Yast, only the SCR part, but still...) The service is started automatically by DBus, but it's not terminated automatically. The timeout is needed for automatic shutdown. The SCR service waits for an incoming message and exits when there is no new request and the last client exited at least 30 seconds ago. -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Ladislav Slezak
Klaus Kaempf wrote:
* Ladislav Slezak
[Feb 06. 2009 17:48]: [...] Actually, I wonder why this timeout is needed at all. The service needs to be terminated after some time. You definitely do not want to have a running Yast in the background forever. (Well, it's not complete Yast, only the SCR part, but still...) The service is started automatically by DBus, but it's not terminated automatically.
The timeout is needed for automatic shutdown.
The SCR service waits for an incoming message and exits when there is no new request and the last client exited at least 30 seconds ago.
I believe this is what the alarm(30) call in DBusServer::resetTimer does. This seems to be signal based and independant of the dbus_connection_read_write timeout value. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Ok, I did some tests on the timeout problem now. Here are the results: 1. The proposed patch (moving the connection.setTimeout() call after the connection.receive() call) is a *huge* improvement. Instead of ~15 secs, my testcase runs in fractions of a second. 2. The timeout (connection.setTimeout) and the alarm (DBusServer::resetTimer) times are related. Apparently, the SIGALARM is only handled outside the connection.receive() function, when the main loop of DBusServer.cc is executed. Esp. result 2 makes the whole signal/alarm logic questionable, as this could easily be moved into the main loop. Ideally, the connection.receive() should handle the timeout and return either with a message (to be handled) or a timeout (shutdown service). But coding DBus without glib seems to be black magic after all ... ;-) Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Klaus Kaempf wrote:
Ok, I did some tests on the timeout problem now. Here are the results:
1. The proposed patch (moving the connection.setTimeout() call after the connection.receive() call) is a *huge* improvement. Instead of ~15 secs, my testcase runs in fractions of a second.
Thanks for the testing! I'll submit the patch to SLE11 RC4. [...]
Ideally, the connection.receive() should handle the timeout and return either with a message (to be handled) or a timeout (shutdown service).
A good point, something for trunk/SP1...
But coding DBus without glib seems to be black magic after all ... ;-)
Yes, even the DBus documentation says that ("If you use this low-level API directly, you're signing up for some pain."). :-) -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Ladislav Slezak
[Feb 06. 2009 17:48]: Hi all,
Klaus has noticed that it takes quite long time to process requests by the SCR DBus service. I have noticed that in the past too but I didn't pay attention to this, I thought that DBus is so slow...
I have recognized that the call is slow only if the service will be started. Requests to a already running SCR DBus server are MUCH more faster. As far I have understood checks the SCR DBus service periodically if the
Klaus Kaempf schrieb: process which is using the service is still running. If not, the service will be shutdown. As the YaST-Webservice is running all the time this shutdown will not happen until the YaST-Webservice will be stoped. Bug, or feature...This is discussable:-) But lets see if the fix of Ladislav will also change the speed of a already running SCR DBus service. At least the startup is much more faster now. Thank you Klaus and Ladislav for finding out !!!!!!! Greetings Stefan
Now I have found the problem: connection.setTimeout() in Yast calls dbus_connection_read_write() function which should wait for an incoming DBus message or timeout (after 5 seconds in this case).
-- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (3)
-
Klaus Kaempf
-
Ladislav Slezak
-
Stefan Schubert