Hi, I sent a PR to the geode native client adding the GatewaySenderEventCallbakArgument class, so the client will be able to deserialize it and the exception will not be thrown.
https://github.com/apache/geode-native/pull/628 I have checked with Mateusz that this change solves the problem he was reporting. BR/ Alberto B. ________________________________ De: Alberto Bustamante Reyes <alberto.bustamante.re...@est.tech> Enviado: lunes, 13 de julio de 2020 17:15 Para: user@geode.apache.org <user@geode.apache.org> Asunto: RE: CQ Event Notification in Multisite (WAN) Hi, In this repo you can find an easy way to reproduce the error: https://github.com/alb3rtobr/geode-wan-cq-deserialization I tested adding the GatewaySenderclass to the C++ client, and with this change the exception is not thrown (draft of the code: https://github.com/apache/geode-native/pull/627 ) Anil, have you had time to check if GatewaySenderEventCallback is needed in the clients? BR/ Alberto B. ________________________________ De: Alberto Bustamante Reyes <alberto.bustamante.re...@est.tech> Enviado: miércoles, 8 de julio de 2020 16:43 Para: user@geode.apache.org <user@geode.apache.org> Asunto: RE: CQ Event Notification in Multisite (WAN) Hi, I will try to help with this issue. I have created a ticket to keep track of it: https://issues.apache.org/jira/browse/GEODE-8344 BR/ Alberto B. ________________________________ De: Anilkumar Gingade <aging...@vmware.com> Enviado: viernes, 3 de julio de 2020 0:46 Para: user@geode.apache.org <user@geode.apache.org> Asunto: Re: CQ Event Notification in Multisite (WAN) Mateusz, It is mostly serial (circular) and star pattern (where all the clusters are connected to each other) where the receiver needs to check who the originator and who all are the recipients, before forwarding it to other cluster. As I mentioned, not sure why it is getting forwarded to clients. -Anil. From: Mateusz Rys <razama...@gmail.com> Reply-To: "user@geode.apache.org" <user@geode.apache.org> Date: Thursday, July 2, 2020 at 7:44 AM To: "user@geode.apache.org" <user@geode.apache.org> Subject: Re: CQ Event Notification in Multisite (WAN) 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<mailto: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<mailto:jabarr...@vmware.com>> Reply-To: "user@geode.apache.org<mailto:user@geode.apache.org>" <user@geode.apache.org<mailto:user@geode.apache.org>> Date: Wednesday, July 1, 2020 at 11:53 AM To: "user@geode.apache.org<mailto:user@geode.apache.org>" <user@geode.apache.org<mailto: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<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
