Bug 22929 - There is no way to track undelivered messages when using MessagingCenter
Summary: There is no way to track undelivered messages when using MessagingCenter
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 1.2.2
Hardware: Macintosh Mac OS
: Normal enhancement
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2014-09-12 08:09 UTC by Jakub Arnold
Modified: 2016-05-28 00:43 UTC (History)
6 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Jakub Arnold 2014-09-12 08:09:40 UTC
Based on my initial post on the forums here http://forums.xamarin.com/discussion/23980/what-is-the-role-of-a-subscriber-in-the-messagingcenter-and-what-are-the-rules-for-receiving?new=1 and on digging through the source code for MessagingCenter in the Assembly Browser, it seems that there are many cases when a message simply gets ignored without any way to capture that.

There should at least be an event handler that one can subscribe to, to be able to handle undelievered messages. Adding this would allow for more defensive coding, where app developers could just raise an exception if a message gets silently ignored.

The way that could happen is when a subscriber goes out of scope or is garbage collected for any reason. The MessagingCenter only keeps WeakReferences, and checks if it IsAlive before sending the message. If the object is not alive, it simply returns and does nothing. Logging such events would be a good start.

Steps to reproduce:

Subscribing with a temporary object does nothing

            MessagingCenter.Subscribe<object>(new{}, "world", sender =>
                    throw new Exception(); // nothing gets thrown

            MessagingCenter.Send(new{}, "world");

Using a simple string works (probably because of string interning?)

            MessagingCenter.Subscribe<string>("hello", "world", sender =>
                    throw new Exception();

            MessagingCenter.Send("hello", "world");

Using an object that stays in scope works as well

            object foo = new{};

            MessagingCenter.Subscribe<object>(foo, "world", sender =>
                    throw new Exception();

            MessagingCenter.Send(foo, "world");

Since this behavior is a bit confusing at least, especially in the string case, it would be great if we could just log such messages to spot issues like this immediately.
Comment 1 Parmendra Kumar 2014-09-16 08:29:03 UTC
I have tried to reproduce this issue as given steps in bug description but unable to reproduce it. Could you please provide us the sample project or environment info to reproduce this issue ?.
When we use the given steps, we are getting an Exception.

Screencast: http://screencast.com/t/BaFVV0Cre2k

Environment Info:
=== Xamarin Studio ===

Version 5.3 (build 441)
Installation UUID: 1a096c6f-0678-402e-89b2-a2c10f7e80e4
	Mono 3.8.0 ((no/45d0ba1)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 308000009

=== Apple Developer Tools ===

Xcode 5.1 (5084)
Build 5B130a

=== Xamarin.Mac ===

Version: (Business Edition)

=== Xamarin.Android ===

Version: 4.16.0 (Business Edition)
Android SDK: /Users/360_macmini/Desktop/android-sdk-macosx
	Supported Android versions:
		2.1    (API level 7)
		2.2    (API level 8)
		2.3    (API level 10)
		3.1    (API level 12)
		3.2    (API level 13)
		4.0    (API level 14)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: 77efa3f
Build date: 2014-08-26 07:59:55-0400

=== Build Information ===

Release ID: 503000441
Git revision: befb6aa1176d37a5f678f4274f340a0159091b7a
Build date: 2014-09-08 17:57:02-04
Xamarin addins: 6dc7c388e31fdfc8014689839d37de0d4622435c

=== Operating System ===

Mac OS X 10.9.4
Darwin ShrutiMac.local 13.3.0 Darwin Kernel Version 13.3.0
    Tue Jun  3 21:27:35 PDT 2014
    root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
Comment 2 CraigD 2014-09-20 21:15:48 UTC
Parmendra, I don't think this is actually a bug. What the customer is asking is more of a feature request.

The implementation of the Xamarin.Forms MessagingCenter is fairly similar to other equivalent products. It is typical for the messages to be 'posted' without any guarantee of being handled (since it doesn't know if any objects are listening or not); and for subscribers to only expect to receive the message if they are naturally still in-memory (by definition).

Jakub, if you feel that some part of the MessagingCenter is actually failing to work as designed, could you please re-submit more information on exactly what the test case would look like for that scenario. It is not a bug that a message does not get delivered if there are no 'live' receivers.

Feel free to also submit a feature request via UserVoice
regarding the ability to attach an event handler or otherwise get notified about unhandled messages.
Comment 3 Jakub Arnold 2014-09-21 20:47:30 UTC
Craig, I understand that a message can not get delivered by a design, that is completely ok.

My point was that it is really hard to diagnose why a message isn't being received when it should be, since there's no way to attach or enable any kind of logging. If the MessagingCenter had an event for something like "message to a subscriber which isn't alive anymore", or "message without subscribers (one where there isn't even a dead weak reference)", one could attach logging to those events and instantly see what is going on.

From looking at the source in the assembly browser, it seems that there are two cases when the MessagingCenter simply returns, without doing anything, and there is no way to tell if the subscriber has gone out of scope, or if the arguments are wrong. I mean this seems easy when you get it right, but when you get it wrong, its very confusing until one looks at the source code for the MessagingCenter.

Maybe just a more detailed explanation of the edge cases in the documentation would work. The only way to figure out that there are weak references involved is through the assembly browser.
Comment 4 Jason Smith [MSFT] 2016-03-16 12:38:11 UTC
Im sorry this got set to NEEDSINFO and fell off our radar, I have added this to the feature request board. Thank you.