Do not convert System.Boolean (binary:0x0) MessagePackObject to System.Int64. about msgpack-cli HOT 12 CLOSED

I think this error was caused because input stream was invalid, not environment. For examle, default(DateTime?) should be 0xC0 (nil) in msgpack stream, but when 0xC2 (false) is passed, this error will be caused. Could you show me the data?

from msgpack-cli.

Thanks for your reply, yfakariya.

More details about the issue:
We have two environments (Local & Central).
We are trying to send an object converted to message pack from local over the TCP socket and unpack back to object on the central.

We tried to deploy both Local application and Central Tcp listener on two different Windows 7 machines and we have no problem in upacking the data at the Central.
But when we try to deploy Local on Windows7 machine and Central on Windows 2008 server (Which would be actual production scenario) we have this issue.
In both the scenarios I am packing and unpacking the same object with same data through test application.
We are still unable to find the root cause of the issue.

Are we missing anything?

from msgpack-cli.

I believe .NET Framework worked identically, and date-time deserialization code is enough simple to avoid OS difference. So I think the data might not be same because it seems to have date time value.
Could you show me additional stack trace? The upper serializer may cause this error. For example, it might forget to invoke Unpacker.Read().

from msgpack-cli.

Below is the object we are trying to pack and Unpack
PlantContact objPlantContact = new PlantContact
{
Id = 1,
AccountNumber = "ECOPLANT5",
ContactFirstName = "Local",
ContactLastName = "One",
ContactTitle = "LocalToCentral",
ContactPositionId = 1,
ContactPositionName = "PositionLocal",
ContactEmailAdresss = "[email protected]",
ContactOfficePhone = "1234abc",
ContactMobilePhone = "4754",
ContactFaxNumber = "fax123",
LastSyncTime = DateTime.UtcNow

        };

Below is the entire Stack trace:

2014-12-09 04:47:12,427 [10] ERROR-Exception Received in HandleTcdAdminMessage
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.Serialization.SerializationException: The unpacked value is not expected type. Do not convert System.Boolean (binary:0x0) MessagePackObject to System.Int64. ---> System.InvalidOperationException: Do not convert System.Boolean (binary:0x0) MessagePackObject to System.Int64.
at MsgPack.MessagePackObject.ThrowInvalidTypeAs[T](MessagePackObject instance)
at MsgPack.MessagePackObject.AsInt64()
at MsgPack.Serialization.DefaultSerializers.System_DateTimeMessagePackSerializer.UnpackFromCore(Unpacker unpacker)
--- End of inner exception stack trace ---
at MsgPack.Serialization.DefaultSerializers.System_DateTimeMessagePackSerializer.UnpackFromCore(Unpacker unpacker)
at MsgPack.Serialization.DefaultSerializers.NullableMessagePackSerializer1.UnpackFromCore(Unpacker unpacker) at MsgPack.Serialization.MessagePackSerializer1.UnpackFrom(Unpacker unpacker)
at MsgPack.Serialization.EmittingSerializers.Generated.TcdRequestHandler_Tcd_Entities_PlantContact_PlantContactSerializer1.UnpackFromCore(Unpacker )
at MsgPack.Serialization.MessagePackSerializer1.UnpackFrom(Unpacker unpacker) at TcdRequestHandler.Tcd.Libraries.Shared.MsgPackConverter.Deserialize[T](Byte[] bytes) in d:\EcoLab\Development\Configurator\NextGenConfigurator\Libraries\TcdRequestHandler\Tcd.Libraries\Shared\MsgPackConverter.cs:line 41 at TcdRequestHandler.Tcd.Libraries.Shared.MsgPackConverter.GetData[T](Byte[] data) in d:\EcoLab\Development\Configurator\NextGenConfigurator\Libraries\TcdRequestHandler\Tcd.Libraries\Shared\MsgPackConverter.cs:line 26 at TcdRequestHandler.Tcd.Libraries.Common.TcdAdminRequestBase1.InitializePayloadWithInputBuffer(Byte[] inputBuffer) in d:\EcoLab\Development\Configurator\NextGenConfigurator\Libraries\TcdRequestHandler\Tcd.Libraries\Common\TcdAdminRequestBase.cs:line 74
at TcdRequestHandler.Tcd.Libraries.Common.TcdAdminRequestBase1.Initialize(ILog logger, Byte[] inputBuffer) in d:\EcoLab\Development\Configurator\NextGenConfigurator\Libraries\TcdRequestHandler\Tcd.Libraries\Common\TcdAdminRequestBase.cs:line 61 at TcdRequestHandler.Tcd.Libraries.Common.TcdAdminRequestBase1..ctor(ILog logger, TcdAdminRequestHeader adminHeader, TcdAppVersion appVersion, Byte[] inputBuffer) in d:\EcoLab\Development\Configurator\NextGenConfigurator\Libraries\TcdRequestHandler\Tcd.Libraries\Common\TcdAdminRequestBase.cs:line 46
at TcdRequestHandler.Tcd.Entities.PlantContact.PlantContactAdminRequest..ctor(ILog logger, TcdAdminRequestHeader adminHeader, TcdAppVersion appVersion, Byte[] inputBuffer) in d:\EcoLab\Development\Configurator\NextGenConfigurator\Libraries\TcdRequestHandler\Tcd.Entities\PlantContact\PlantContactAdminRequest.cs:line 19
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark)
at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
at System.Activator.CreateInstance(Type type, Object[] args)
at TcdRequestHandler.Tcd.Entities.TcdTcpEntityFactory.GetRequestEntity(ILog logger, TcdAppVersion appVersion, TcdAdminRequestHeader adminHeader, Byte[] payloadBuffer) in d:\EcoLab\Development\Configurator\NextGenConfigurator\Libraries\TcdRequestHandler\Tcd.Entities\TcpEntityFactory.cs:line 59
at Nalco.WPS.TcpHostService.TcpServer.HandleTcdAdminMessage(UInt32 ecpTransportVersion, EcpTransportHeader tHeader, NetworkStream stream) in d:\EcoLab\Development\Configurator\NextGenConfigurator\Services\Nalco.WPS.TcpHostService\TcpServer.cs:line 547

from msgpack-cli.

Thank you for the information. I found that I could try to reproduce the issue because there were no custom serializer in the stacktrace. But finally I have not be able to reproduce the exception except I manually tweak serialized binary's null DateTime? type value (0xC0) to false (0xC2). I think the input binary may cause the exception. So,

1. Can you reproduce the problem now on the server?
2. Can I see the problemstic binary?

I'm sorry to take up your time.

from msgpack-cli.

Yes I could still reproduce the problem in the server.
Sorry, I didnt understand what you mean by "problematic binary".

Below is the code i use to pack and unpack the objects, may be it could be of some help.

public static byte[] Serialize(T thisObj)
{
var serializer = MessagePackSerializer.Get();

        using (var byteStream = new MemoryStream())
        {
            serializer.Pack(byteStream, thisObj);
            return byteStream.ToArray();
        }
    }

private static T Deserialize(byte[] bytes)
{
var serializer = MessagePackSerializer.Get();
using (var byteStream = new MemoryStream(bytes))
{
return serializer.Unpack(byteStream);
}
}

from msgpack-cli.

Sorry for my poor English. Can I see BitConverter.ToString(bytes) when you reproduce?

from msgpack-cli.

Below is the string:
"9F-AD-6D-61-69-6C-40-6D-61-69-6C-2E-63-6F-6D-A8-31-32-33-34-35-36-37-38-A5-46-4E-61-6D-65-A5-4C-4E-61-6D-65-AA-38-30-38-30-38-30-38-38-30-38-A7-34-35-36-38-39-32-33-05-AD-74-65-73-74-50-6F-73-74-69-74-69-6F-6E-A2-4D-72-A1-31-17-C2-D3-00-00-01-4A-57-55-7E-CD-D3-FF-FF-C7-7C-ED-D3-28-00-05"

from msgpack-cli.

Thank you, and sorry for delay.
Your data looks 15 items array, that means serialized source should have 15 fields/properties instead of 9 items your PlantContact class has (a first byte 0x9F says that it is 0xF items array -- it should be 0x99). I think there is a schema mismatch between serializing environment and deserializing environment. Just for reference, I describe hand-deserialized data bellow:

[ "[email protected]", "12345678", "FName", "LName", "8080808808", "4568923", 5, "testPostition", "Mr", "1", 23, false, 1418804428493, -62135596800000, 5 ]

This result can be seen with following code:

var bytes = 
    new byte[]
    {
        0x9F, 0xAD, 0x6D, 0x61, 0x69, 0x6C, 0x40, 0x6D, 0x61, 0x69, 0x6C, 0x2E, 0x63, 0x6F, 0x6D, 0xA8, 0x31, 0x32, 0x33,
        0x34, 0x35, 0x36, 0x37, 0x38, 0xA5, 0x46, 0x4E, 0x61, 0x6D, 0x65, 0xA5, 0x4C, 0x4E, 0x61, 0x6D, 0x65, 0xAA, 0x38,
        0x30, 0x38, 0x30, 0x38, 0x30, 0x38, 0x38, 0x30, 0x38, 0xA7, 0x34, 0x35, 0x36, 0x38, 0x39, 0x32, 0x33, 0x05, 0xAD,
        0x74, 0x65, 0x73, 0x74, 0x50, 0x6F, 0x73, 0x74, 0x69, 0x74, 0x69, 0x6F, 0x6E, 0xA2, 0x4D, 0x72, 0xA1, 0x31, 0x17,
        0xC2, 0xD3, 0x00, 0x00, 0x01, 0x4A, 0x57, 0x55, 0x7E, 0xCD, 0xD3, 0xFF, 0xFF, 0xC7, 0x7C, 0xED, 0xD3, 0x28, 0x00,
        0x05
    };
var array = Unpacking.UnpackArray( bytes ).Value;
Console.WriteLine( new MessagePackObject( array ) );

I think the deserializer expected that the 11th item would Int64(starts with D3) but actual one was false. Would you watch your libraries version again?

from msgpack-cli.

Close because no answer about 6 months.
It is welcome to reopen this issue if you think that this issue should not be closed.

from msgpack-cli.

thank you @yfakariya you saved me some time. I was having a similar error because of mismatch in fields between the service and the consumer when using application/x-msgpack where as application/json would still deserialize. Why does the contract has to be an exact match though ?

from msgpack-cli.

@ibaig It may be occurred by msgpack for cli's 'lexical ordering' of array fields. Could you try to qualify your (de)serializing types' fields with [MessagePackMember(<order>)]?

from msgpack-cli.