Yes I can. IOException is not thrown and the client works in that case.
BRs,
Jakov
On 17. 04. 2020. 16:24, Jacob Barrett 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
