Thanks Guys! When I was younger, my teacher told me that if I think the problem is in the compiler or the library and not in my code then I have to think again. Finally, I can prove him wrong ;) (once for 10 years)
Anyway, we implemented a stub sort of class that registered itself with FixedID = -135. It did nothing besides adding itself to TheTypeMap so that it can be found later when deserialization happens. Strangely enough - it worked. That is, the event was processed successfully and finally our afterCreate/afterUpdate method triggered. Nobody knows what we broke doing that, but at least we can safely say that we pinpointed the issue. Anil, you wrote that the GATEWAY_SENDER_EVENT_CALLBACK_ARGUMENT is sent to clients "in case of certain wan connection configuration". Did you have anything particular in mind? I scoured the documentation again but I haven't found anything that could make the difference in connection configuration. As for now, we planned on using the standard "Fully Connected Mesh Topology", although it seems to me that it's the server that decides whether the event should be propagated further or not - we haven't seen any sort of "endless event loop" after adding the stub-class. Regards Mateusz śr., 1 lip 2020 o 23:23 Anilkumar Gingade <aging...@vmware.com> napisał(a): > >> Anil, do can you explain why GATEWAY_SENDER_EVENT_CALLBACK_ARGUMENT is > sent to clients? > > Looking at the purpose of this class; this is to avoid resending of an > event to a recipient; in case of certain wan connection configuration. > > > > After processing the WAN event, my expectation is fetching data from WAN > event and creating a new region entry and then a new client event from it > and sending it to client. My suspicion is we are preserving this callback > event and passing all the way to the client; not sure if its needed. Need > additional investigation. > > > > -Anil. > > > > > > *From: *Jacob Barrett <jabarr...@vmware.com> > *Reply-To: *"user@geode.apache.org" <user@geode.apache.org> > *Date: *Wednesday, July 1, 2020 at 11:53 AM > *To: *"user@geode.apache.org" <user@geode.apache.org> > *Subject: *Re: CQ Event Notification in Multisite (WAN) > > > > > > > > On Jul 1, 2020, at 6:29 AM, Mateusz Rys <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 >
