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
