We are currently working on implementing a notifications feature for our app we are developing for Windows Azure. We want to inform users when actions have taken place they are interested in (such as the importing and exporting of files and so on). This notification is specific to each logged in user.
We have been using ServerSentEvents and we have found that this list is one event behind. So we do not start seeing notifications until the second action has taken place and that notification is for the first action. In our dev environments this problem always happens, but in Azure it appears to work as expected (sometimes!!!)
We are using the default implementation of the Event Queue and Channel Initialiser. We publish via the EventPublisher.WriteTo method passing a topic and a serverevent.
Here is our implementation of Topic:
public class UserNotificationsTopic : Topic
{
[RouteInput]
public Guid UserId { get; set; }
public override bool Equals(object obj)
{
return Equals(obj as UserNotificationsTopic);
}
public bool Equals(UserNotificationsTopic other)
{
if (ReferenceEquals(null, other)) return false;
return ReferenceEquals(this, other) ||
UserId.Equals(other.UserId);
}
public override int GetHashCode()
{
return UserId.GetHashCode();
}
}
Implementation of our ServerEvent:
public class UserNotificationServerEvent : IServerEvent
{
public string Id { get; private set; }
public string Event { get; private set; }
public int? Retry { get; set; }
public object Data { get; private set; }
public UserNotificationServerEvent(string id, string @event, object data)
{
this.Id = id;
this.Event = @event;
this.Data = data;
}
}
Any help, suggestions would be appreciated!
Thanks
Scott
I think I have found the solution (with a lot of assistance from my colleague).
We reading about SignalR and found it has a similar problem in Azure (one event behind), the solution recommended was to add properties for urlCompression to the Web.config for the Azure Web Role.
I added the settings which are the default for IIS7.5:
<urlCompression doStaticCompression="true" doDynamicCompression="false"/>
And this appears to have solved the issue! I am not sure why yet, so if anyone can help with that please feel free to add.
Anyway, I just thought I'd share the update.