Bug 580619

Summary:	ruby-dbus: Detect wrong call sequences of asynchronous services
Product:	[SUSE Appliance Toolkit] WebYaST	Reporter:	Klaus Kämpf <kkaempf>
Component:	Architecture	Assignee:	Martin Vidner <mvidner>
Status:	RESOLVED WONTFIX	QA Contact:	Josef Reidinger <jreidinger>
Severity:	Normal
Priority:	P3 - Medium	CC:	lslezak
Version:	SLE11 SP1 Beta4
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	Development	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Klaus Kämpf 2010-02-17 18:27:24 UTC

Find a way to detect call sequences, i.e. bnc#579001

Usual error scenario: An asynchronous service, requiring a proxy function call, listening to signals afterwards. Typically any PackageKit transaction call.
If the method is called before the listening counterpart (DBus::Main.new) is established, signals being send can get lost.

Comment 1 Martin Vidner 2010-02-22 16:01:53 UTC

Maybe I am interpreting the request too widely, but I don't see how it could be possible.
How do you know that a reply is available and wanted?
How do you know what replies should be watched for?
In general, how would you suggest a solution to work?

Comment 2 Klaus Kämpf 2010-02-25 10:45:37 UTC

If I understand bnc#579001 correctly, the on_signal settings were called (signal handler established) but the listener (DBus::Main.new) was not.

Couldn't it be possible to run a generic listener, reporting incoming signals without a dedicated listener ? Or relate the incoming signals to previously sent messages (through known proxy) ?

I probably have to look deeper into ruby-dbus for a more detailed solution proposal.

Comment 3 Martin Vidner 2010-02-25 12:42:08 UTC

> If I understand bnc#579001 correctly, the on_signal settings were called
> (signal handler established) but the listener (DBus::Main.new) was not.

You misunderstood. Quoting from bug 579001 comment 22:

>> For the record, actually no. If that were the case, there would still be a race
>> condition, only with a shorter trigger window. What was too late (as a result
>> of a previous refactoring) was the on_signal (org.freedesktop.DBus.AddMatch).
>> But the fix ends up being right.

One of the on_signal, "Finished", was called too late.

Anyway...

> Couldn't it be possible to run a generic listener, reporting incoming signals
> without a dedicated listener ?

Like assuming control over the DBus connection in a DBus::Main loop global for the library/application? I think the current implementation in WebYaST is as good as it gets, with a main loop for the lifetime of the transaction.

> Or relate the incoming signals to previously
> sent messages (through known proxy) ?

IMHO that's not possible in general (REPLY_SERIAL is not required for SIGNALs, only for METHOD_RETURNs and ERRORs, see Header Fields in http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-messages )
unless you create an API-specific wrapper (like for PackageKit)

> I probably have to look deeper into ruby-dbus for a more detailed solution
> proposal.

Wontfix for now, reopen if you have ideas.