Bug 580619 - ruby-dbus: Detect wrong call sequences of asynchronous services
Summary: ruby-dbus: Detect wrong call sequences of asynchronous services
Status: RESOLVED WONTFIX
Alias: None
Product: WebYaST
Classification: SUSE Appliance Toolkit
Component: Architecture (show other bugs)
Version: SLE11 SP1 Beta4
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Martin Vidner
QA Contact: Josef Reidinger
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-17 18:27 UTC by Klaus Kämpf
Modified: 2010-02-25 12:42 UTC (History)
1 user (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.