This log message about the GFE version is suspicious too. That is a VERY old version with ordinal value 1. The C++ client is supposed to be sending 45 which is GFE 9.0.0 / Geode 1.0.0.
Looks like there might be a handshake protocol misalignment somewhere. Will keep digging. -Jake > On Apr 17, 2020, at 7:24 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > Can you confirm that when log level less than debug that the IOException goes > away and the client appears to function? > > -Jake > > >> On Apr 17, 2020, at 1:12 AM, Jakov Varenina <jakov.varen...@est.tech> wrote: >> >> Hi Jacob, >> >> Thanks for your response! >> >> Regarding GEODE-7944, "Unable to deserialize *membership id* >> java.io.EOFException" is not logged but thrown, and it breaks processing of >> QueueConnectionRequest in locator. This reflects in native client with "No >> locators found" even though they are available. Happens only when native >> client with subscription is enabled and locator started with >> --log-level=debug. >> >> I haven't had time to test and analyze in detail native durable client yet. >> So far I could only confirm that when using native durable client then >> locator behaves differently than how it is described in documentation (see >> previous mail) and how java client works: >> >> It seems that native durable client always requests from locator all >> available servers (redundant= -1, findDurable=false) with >> QueueConnectionRequest. Locator returns them in QueueConnectionResponse >> ordered by load (best...worst). While for java durable client, locator use >> *membership id *from QueueConnectionRequest to locate servers that host >> client queue and send them back in QueueConnectionResponse as described in >> previous mail. I expect that native durable client is handling re-connection >> to same servers queue somehow also, but this has to be investigated yet. Any >> hints or comments related to this would be really appreciated. >> >> BRs, >> >> Jakov >> >> On 15. 04. 2020. 10:07, Jacob Barrett wrote: >>> Looking back at history the native library has always only ever set that >>> findDurable flag to false. I traced it back to its initial commit. Aside >>> from the annoying log message, does client durable connection work >>> correctly? >>> >>>> On Apr 14, 2020, at 10:56 PM, Jakov Varenina <jakov.varen...@est.tech> >>>> wrote: >>>> >>>> Hi all, >>>> >>>> Could you please help me understand behavior of the native client when >>>> configured as durable? >>>> >>>> I have been working on a bug GEODE-7944 >>>> <https://issues.apache.org/jira/browse/GEODE-7944> which results with >>>> exception "Unable to deserialize membership id java.io.EOFException" on >>>> locator only when debug is enabled. This happens because native client, >>>> only when subscription is enabled, sends towards locator >>>> QueueConnectionRequest that doesn't encapsulate ClientProxyMembershipID >>>> (not properly serialized) and therefore exception occurs when locator >>>> tries to deserialize membership id to log it at debug level. >>>> >>>> I was trying to figure out why would locator need ClientProxyMembershipID >>>> from native client and found following paragraph in the documentation >>>> (copied from >>>> https://geode.apache.org/docs/geode-native/cpp/112/connection-pools/subscription-properties.html): >>>> >>>> /For durable subscriptions, the server locator must be able to >>>> locate the servers that host the queues for the durable client. When >>>> a durable client sends a request, the server locator queries all the >>>> available servers to see if they are hosting the subscription region >>>> queue for the durable client. If the server is located, the client >>>> is connected to the server hosting the subscription region queue./ >>>> >>>> Locator behaves as described in above paragraph only when it receives >>>> ///QueueConnectionRequest with ///findDurable flag set to "true" //and >>>> with valid membership i//d. //I noticed that unlike java client, the >>>> native client always sets //findDurable// to //"false" //and therefore >>>> locator will never behave as described in above paragraph when native >>>> client is used. >>>> >>>> Does anybody know why native client always sets //findDurable=false//? >>>> >>>> BRs, >>>> >>>> Jakov >
