1

Closed

Serialization Error on Win CE 6 (.NET CF 3.5)

description

I am trying to run a small demo app using XCoordination Application Space v1.4 binaries on a WinCE 6.0 (.NET CF 3.5) device and I am running into an error when I try to connect to a worker (see below). I have configured both the server and client to utilize the JSON serializer but they still won't connect. Any suggestions? Thanks!

ERROR:

at System.Linq.Enumerable.ToList[TSource](IEnumerable1 source)
at TypeResolve.TypeUtils.LoadCurrentAssemblies()
at TypeResolve.TypeUtils.Initialize()
at TypeResolve.TypeUtils..cctor()
at TypeResolve.TypeResolver.GetType(String typeName)
at TypeResolve.TypeResolver.ConvertStringToType(String typeName)
at TypeResolve.TypeResolver.Resolve(String typeName, Int32[]& arrayDimensions)
at BruteForceSerializer.Normalization.Normalizer.DeNormalize(Object objectGraphRoot, Dictionary
2 visitedObjects)
at BruteForceSerializer.Normalization.Normalizer.DeNormalize(INormalizedObject no)
at BruteForceSerializer.Serializer.DeSerialize(String serializedObject)
at XcoAppSpaces.Serialization.Json.XcoJsonSerializer.Deserialize(Byte[] element)
at XcoAppSpaces.Core.Communication.SerializationExtensions.Deserialize[T](IXcoSerializer serializer, Byte[] serializedObj)
at XcoAppSpaces.Core.Communication.SerializationExtensions.DeserializeCausalityContext(IXcoSerializer serializer, Byte[] serializedCausalityContext)
at XcoAppSpaces.Core.Communication.MessageTransmitter.TryDeserializeMessage(String commServiceName, XcoMessage msg, String remoteAddress, CausalityContext& context, RemoteMessage& content)
at XcoAppSpaces.Core.Communication.MessageTransmitter.MessageReceived(XcoMessage msg, String remoteAddress, IXcoTransportService commService)
at XcoAppSpaces.Transport.Sockets.XcoTCPTransportService.RaiseMessageReceivedEvent(XcoMessage msg, String remoteAddress)
at XcoAppSpaces.Transport.Sockets.TCPServer.StartReceive(TcpClient client, Action refreshClientTimeout)
at XcoAppSpaces.Transport.Sockets.TCPServer.<>c__DisplayClassc.<DoAuthentication>b__b(Object _)
at System.Threading.ThreadPool.WorkItem.doWork(Object o)
at System.Threading.Timer.ring()

SERVER / WORKER CONFIG:

_Space = XcoAppSpace.Configure
                .UsingService<XcoJsonSerializer>().WithName("json")
                .UsingService(new XcoTCPTransportService("10.100.93.8", 8000)).WithSerializer("json");

CLIENT CONFIG:

_Space = XcoAppSpace.Configure
                .UsingService<XcoJsonSerializer>().WithName("json")
                .UsingService<XcoTCPTransportService>().OnPort(0).WithSerializer("json");
The error occurs when I execute the following line of code. Please note that the server / worker is being run on the CE device and the client is running on my Windows 7 PC.
_FieldUpdateRequestWorker = _Space.ConnectWorker<FieldUpdateRequestContract>(String.Format("{0}:{1}/FieldUpdateRequestWorker",
                        textBoxServerIp.Text,
                        textBoxServerPort.Text));

file attachments

Closed Jul 2, 2013 at 6:42 AM by thomass
Problems have been fixed.

comments

husterk wrote Jun 18, 2013 at 6:46 PM

UPDATE: I have rolled all the way back to XCoordination v1.0 and my application starting running properly! However, this means that there has been an issue with running on CE devices since v1.0. Also, I am now encountering a new ArgumentOutOfRangeException occurring in the XcoTCPTransportService class (see below). From reviewing the source code it looks like the exception is being generated when the DateTime.Now.Subtract() method is being called from within the CheckConnectionTimeouts() method.

at System.DateTime.DateToTicks(Int32 year, Int32 month, Int32 day)
at System.DateTime..ctor(Int32 year, Int32 month, Int32 day, Int32 hour, Int32 minute, Int32 second, Int32 millisecond, DateTimeKind kind)
at System.CurrentSystemTimeZone.GetDayOfWeek(Int32 year, Int32 month, Int32 targetDayOfWeek, Int32 numberOfSunday, Int32 hour, Int32 minute, Int32 second, Int32 millisecond)
at System.CurrentSystemTimeZone.GetDaylightChanges(Int32 year)
at System.CurrentSystemTimeZone.GetUtcOffsetFromUniversalTime(DateTime time, Boolean& isAmbiguousLocalDst)
at System.CurrentSystemTimeZone.ToLocalTime(DateTime time)
at System.DateTime.ToLocalTime()
at System.DateTime.get_Now()
at XcoAppSpaces.Transport.Sockets.XcoTCPTransportService.CheckConnectionTimeouts(Object timerInfo)
at System.Threading.Timer.ring()

wrote Jun 19, 2013 at 7:41 AM

thomass wrote Jun 19, 2013 at 7:41 AM

Hi Keith,
It seems that a bug was introduced in v1.4 in the deserialization logic. If have corrected the error, please try the attached version and tell me if it works for you.

Unfortunately I was not able to reproduce the second bug you mentioned. From your Stacktrace, it seems to appear within DateTime.Now, which I have never seen before. It may be a hardware/driver related error - it sounds very similar to the one describe here:
http://social.msdn.microsoft.com/Forums/en-US/fa12225f-affc-4dbc-b4e5-83f3bbd4f034/datetimenow-exception-with-cf20-sp2

husterk wrote Jun 19, 2013 at 12:44 PM

Thomass - Thanks! This seems to have corrected the serialization issue. I am now able to run my app! I am looking into the DateTime issue now. Hopefully we can find something in our BSP to correct this issue. I spoke with our BSP developer and it looks like the issue may have something to do with the .NET CF and setting the Time Zone to UTC (while the Windows Shell is enabled). If we disable the Windows Shell or set a different Time Zone then the issue goes away. I will let you know if we find a solution for this.

However, now I am seeing a continuous log of System.IO.IOException first chance exceptions in the Visual Studio output window. This seems to occur when the connection between the device and the server becomes idle. The connections appears to be maintained as I can send more data between the devices (which also stops the IOExceptions but the exceptions occur once again as soon as the connection becomes idle. I have provided detail on the issue below.

FIRST CHANCE EXCEPTION:

System.IO.IOException - "Unable to read data from the transport connection."
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at System.IO.BinaryReader.Read(Byte[] buffer, Int32 index, Int32 count)
at XcoAppSpaces.Transport.Sockets.TransferHelper.Convert(BinaryReader stream, String& remoteAddress, Action handleEmptyData, Action`1 handleError)
at XcoAppSpaces.Transport.Sockets.TCPServer.StartReceive(TcpClient client, Action refreshClientTimeout)
at XcoAppSpaces.Transport.Sockets.TCPServer.<>c__DisplayClassc.<DoAuthentication>b__b(Object _)
at System.Threading.ThreadPool.WorkItem.doWork(Object o)
at System.Threading.Timer.ring()

INNER EXCEPTION:

System.NET.Sockets.SocketException - "An existing connection was forcibly closed by the remote host"
ErrorCode - 10054
at System.Net.Sockets.Socket.ReceiveNoCheck(Byte[] buffer, Int32 index, Int32 request, SocketFlags socketFlags)
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at System.IO.BinaryReader.Read(Byte[] buffer, Int32 index, Int32 count)
at XcoAppSpaces.Transport.Sockets.TransferHelper.Convert(BinaryReader stream, String& remoteAddress, Action handleEmptyData, Action`1 handleError)
at XcoAppSpaces.Transport.Sockets.TCPServer.StartReceive(TcpClient client, Action refreshClientTimeout)
at XcoAppSpaces.Transport.Sockets.TCPServer.<>c__DisplayClassc.<DoAuthentication>b__b(Object _)
at System.Threading.ThreadPool.WorkItem.doWork(Object o)
at System.Threading.Timer.ring()

thomass wrote Jun 21, 2013 at 5:32 AM

Hi Keith,
There is an Exception or two at the time the connection is closed after being idle (which is by default after 1 minute). Unfortunately I cannot prevent the IOException, because it is thrown by the NetworkStream.Read() method while waiting for new data to arrive, and there is no other way to cancel the blocking method. So it should be no problem if you just ignore it.
However, this should only happen once when the connection is closed, and not happen continuously. It should only happen again after sending messages and then again having an idle time of 1min+. Or do you see exceptions more frequent than that?

husterk wrote Jun 21, 2013 at 11:45 AM

Thomass - I understand and expect an IOException when a socket is no longer available. However, I am seeing a continuous stream of first-chance IOExceptions in Visual Studio output window. These exceptions are raised for at least 1 minute and I am not sure if they ever stop. It almost looks like something in your code enters a loop in which it is attempting to read from the socket even though the socket is no longer available. Just a guess...

thomass wrote Jun 21, 2013 at 1:04 PM

Hi Keith, hmm sounds strange, unfortunately I could not replicate this with the emulator. Could you give me some more info - perhaps it helps finding the problem:
  • Is it always the same exception that is thrown, with the same stacktrace (IOException being thrown in Transferhelper.Convert(), like the one you posted above)?
  • Do you encounter any other exceptions, like an ObjectDisposedException? (either regularly or even just once)

husterk wrote Jun 21, 2013 at 1:43 PM

Thomass - Yes, it is always the same exception. It seems to get continuously re-thrown in a loop. I don't see any other exceptions being thrown in the output window. Even with the exceptions the application still runs (since they are only first-chance exceptions). I am more worried about performance impact since this seems to happen for each idle worker connection.

wrote Jun 21, 2013 at 2:55 PM

thomass wrote Jun 21, 2013 at 2:55 PM

Hi Keith, please try again the new attached appspace version. Are you by any chance initiating the connection from the server side? Because in this case the server is the one that actively closes the connection, and there may have been a problem with the client recognizing that it has been closed.

wrote Jun 21, 2013 at 2:56 PM

husterk wrote Jun 21, 2013 at 3:37 PM

Thomass - Yes, I was initiating the connection from the server end. Unfortunately, I am not at the office today and I will be out all next week (on vacation). I will let you know how it goes as soon as I get back to the office. Thanks for all your help on this!

husterk wrote Jul 1, 2013 at 2:28 PM

Thomass - The new DLL you provided seems to have eliminated the stream of first-chance exceptions. Thanks for tackling this issue so quickly!

thomass wrote Jul 2, 2013 at 6:41 AM

Hi Keith,
I'm glad to hear that the issue is resolved!

wrote Jul 2, 2013 at 6:42 AM