Race condition when creating browser or resolver objects

[jadahl]

When trying to browse discovered services (using ServiceBrowserNew?) via DBus using the java-dbus interface the discovered services are only announced/replied once. Second time running the program none is returned. Sometimes AllForNow? is received, sometimes nothing happens, but the first time (for example after a long time or a reboot) all services seem to be discovered successfully. Using the python example or C example displays all services available.

Example:

$ ./run_service_browse.sh
ServiceBrowser.ItemNew: workstation1 [00:0a:49:71:17:90] -> _workstation._tcp
ServiceBrowser.ItemNew: workstation2 [00:1d:61:76:bf:f4] -> _workstation._tcp
ServiceBrowser.ItemNew: workstation3 [00:13:de:ad:be:ef] -> _workstation._tcp
ServiceBrowser: That's all for now.
<Ctrl-C>
$ ./run_service_browser.sh
ServiceBrowser: That's all for now.
<Ctrl-C>
$ ./run_service_browser.sh
<Ctrl-C>
$ ./run_service_browser.sh
<Ctrl-C>
$

Using ubuntu 8.04 packages.

[lennart]

Looks like an issue in java-dbus then, don't you think? What makes you think that this is an Avahi bug?

[lennart]

This is probably an ordering issue. Avahi will first send messages about found services and then reply from the ServiceBrowserNew? function. If Avahi is accessed with blocking calls the client side will reorder this automatically for you.

[rossburton]

I've got this problem with using Avahi from GJS too. Oddly even after making ServiceBrowserNew? synchronous I still lose signals somewhere.

How about adding *Async variants of the troublesome methods (such as ServiceBrowserNewAsync?) that don't emit any signals until a Start method is called? I'm not entirely keen on the Async suffix though.