Hi Jacob,
Native durable client reconnects to the servers hosting the queue in a
following way:
1. Always sends QueueConnectionRequest (redundant=-1,
findDurable=false, ClientProxyMembershipID="Not set, except uniqueID
which is hard-coded to 1") requesting all available servers
regard
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 V
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,
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 wrote:
>
> Hi Jacob,
>
> Thanks for your response!
>
> Regarding GEODE-7944, "Unable to deserialize *membership id*
> j
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 availabl
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 wrote:
>
> Hi all,
>
>
