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
