Receiving notification from Singleton after the client crash
- From: "Joe Doe" <jgeorge@xxxxxxxxxx>
- Date: Wed, 3 Jan 2007 17:09:59 -0500
Hello,
I have a client object that talks to a singleton remote object. I
deliberately the crash the client to see what happens to my server. When I
restart the client, it reconnects without issues. From then on when the
singleton remotely calls the client, it throws errors. "Found two different
objects associated with the same URI, " followed the URI name.
I am not sure how to handle this. I use lease expiration logic through a
sponsor so that the server object should know that the client went away. Is
there a way to cleanup these identities.
In the real world, I am sure my client is going to crash because it is a
complex app. I want to be prepared for this so that they don't have to
restart the service where I am hosting the remote server to fix the issue.
Please help. Thanks in advance.
Server stack trace:
02884023 2:02:14.140 PM [332] at
System.Runtime.Remoting.IdentityHolder.SetIdentity(Identity idObj, String
URI, DuplicateIdentityOption duplicateOption)
02884024 2:02:14.140 PM [332] at
System.Runtime.Remoting.IdentityHolder.FindOrCreateServerIdentity(MarshalByRefObject
obj, String objURI, Int32 flags)
02884025 2:02:14.140 PM [332] at
System.Runtime.Remoting.RemotingServices.GetOrCreateIdentity(MarshalByRefObject
Obj, String ObjURI)
02884026 2:02:14.140 PM [332] at
System.Runtime.Remoting.RemotingServices.MarshalInternal(MarshalByRefObject
Obj, String ObjURI, Type RequestedType, Boolean updateChannelData)
02884027 2:02:14.140 PM [332] at
System.Runtime.Remoting.RemotingServices.GetObjectData(Object obj,
SerializationInfo info, StreamingContext context)
02884028 2:02:14.140 PM [332] at
System.Runtime.Remoting.Messaging.RemotingSurrogate.GetObjectData(Object
obj, SerializationInfo info, StreamingContext context)
02884029 2:02:14.140 PM [332] at
System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitSerialize(Object
obj, ISurrogateSelector surrogateSelector, StreamingContext context,
SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter,
ObjectWriter objectWriter)
02884030 2:02:14.140 PM [332] at
System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.Serialize(Object
obj, ISurrogateSelector surrogateSelector, StreamingContext context,
SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter,
ObjectWriter objectWriter)
02884031 2:02:14.140 PM [332] at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize(Object
graph, Header[] inHeaders, __BinaryWriter serWriter, Boolean fCheck)
02884032 2:02:14.140 PM [332] at
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Stream
serializationStream, Object graph, Header[] headers, Boolean fCheck)
02884033 2:02:14.140 PM [332] at
System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SerializeMessage(IMessage
msg, ITransportHeaders& headers, Stream& stream)
02884034 2:02:14.140 PM [332] at
System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage
msg)
.
- Follow-Ups:
- Prev by Date: Re: Last Stop Before Support Call
- Next by Date: Benefits of reusing proxy?
- Previous by thread: Re: Last Stop Before Support Call
- Next by thread: Re: Receiving notification from Singleton after the client crash
- Index(es):
Relevant Pages
|