On Jul 1, 2020, at 6:29 AM, Mateusz Rys
<razama...@gmail.com<mailto:razama...@gmail.com>> wrote:
We rebuilt the library a couple of times, adding our own debug printouts and we
found that right before the exception there is an attempt to deserialize
fixedID = -135.
In JAVA it is defined as:
short GATEWAY_SENDER_EVENT_CALLBACK_ARGUMENT = -135;
Looking at DSFixedID.hpp from CPP Client I don't see -135 defined. Do you think
this might be the problem?
This doesn’t come as a complete surprise to me. Its likely this was never
implemented in the C++ client. I am not even suer what this is and why it would
be sent to the client anyway.
Anil, do can you explain why GATEWAY_SENDER_EVENT_CALLBACK_ARGUMENT is sent to
clients?
Yesterday, we also implemented a simple JAVA client and it works without any
problems.
We are doing almost exactly the same things we did in CPP client.
The only differences are:
- using ClientXXX instead of XXX in API calls (for example: ClientCacheFactory
instead of CacheFactory),
but I assume it's just a difference in API naming convention.
Yes, here are minor differences in the APIs. Java ClientCacheFactory is fairly
new and was derived to split concerns between server and client versions of a
Cache. On the C++ there is only a client cache, but it retains the original
name of CacheFactory and Cache. Confusing… yes.
- lack of registerPdxType in JAVA Client as there is no such thing
Java side doesn’t need this because of reflection as describe earlier. C++
needs this to map types to a factory function that will allocate the C++ class.
With two JAVA Clients writing and having listeners, local event is recognized
as DomainClass from the get-go and remote event is recognized as PdxInstance
that we have to convert.
Nevertheless, it works perfectly fine as we would expect.
With CPP Clients, we can see in the server logs that adding PdxType from remote
WAN is recognized.
Does the fact that we have it twice mean that the server treats it as two
separate entries?
[info 2020/06/30 14:09:22.044 CEST <ServerConnection on port 1543 Thread 4>
tid=0x52] Adding new type: PdxType[dsid=60, typenum=15169619
name=com.example.Order
fields=[
order_id:int:identity:0:idx0(relativeOffset)=0:idx1(vlfOffsetIndex)=0
name:String:identity:1:idx0(relativeOffset)=4:idx1(vlfOffsetIndex)=-1
quantity:short:identity:2:idx0(relativeOffset)=-2:idx1(vlfOffsetIndex)=-1]]
[info 2020/06/30 14:09:22.051 CEST <ServerConnection on port 1543 Thread 4>
tid=0x52] Adding, from remote WAN: PdxType[dsid=60, typenum=15169619
name=com.example.Order
fields=[
order_id:int:identity:0:idx0(relativeOffset)=0:idx1(vlfOffsetIndex)=0
name:String:identity:1:idx0(relativeOffset)=4:idx1(vlfOffsetIndex)=-1
quantity:short:identity:2:idx0(relativeOffset)=-2:idx1(vlfOffsetIndex)=-1]]
The server will in fact treat them differently, but the problem is the clients
don’t know what do to with them. As described earlier I don’t think the C++
client is tracking both the system id and the type name in the registration of
the allocation function. It should create a mapping from the class name to the
function so that when the client receives a fully qualified type id (type id
and system id) for which there is no mapping then it should try the class name
mapping. If a class name mapping is found it should record that same function
in the fully qualified type id mapping.
I'm not sure if producing an integration test isn't a bit beyond my knowledge
at the moment.
I have faith!
At this point I would just open a JIRA for this issue with all the information
you have gathered.
-Jake
