[
https://issues.apache.org/jira/browse/IGNITE-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17452403#comment-17452403
]
Alexandr Shapkin edited comment on IGNITE-16038 at 12/2/21, 1:16 PM:
---------------------------------------------------------------------
[~alex_pl]
Yes, that's correct, it is a potential compatibility break. I also find the
case when a client can't read a value inserted by a thick client or vice versa
counterintuitive. We just don't have any warnings or reasons that explain the
problem with having different compact footers.
Consider this:
* a user starts a vanilla server node and performs cache#put(myKey, myVal)
[compactFooter=true]
* then it starts a default thin client and is trying to get a value with
thinCache.get(myKey) [compactFooter=false]
* ??? why there is no value found, seems like Ignite is broken...
In a very safe implementation, we might yield a WARN in a client's (java
version don't have it yet if I remember correctly) or server's logs with
respect to the binary configuration mismatch and provide a user with the right
direction on how to fix that. But I'd say we need to implement the change just
like it's written in IEP and set compactFooter=serverValue. Well, we might add
just another Ignite property to disable this feature and some announcements in
release docs are welcome.
Anyway, my biggest concern is that - it's very confusing for the end-users.
WDYT?
was (Author: ashapkin):
[~alex_pl]
Yes, that's correct, it is a potential compatibility break. I also find the
case when a client can't read a value inserted by a thick client or vice versa
counterintuitive. We just don't have any warnings or reasons that explain the
problem with having different compact footers.
Consider this:
* a user starts a vanilla server node and performs cache#put(myKey, myVal)
* then it starts a default thin client and is trying to get a value with
thinCache.get(myKey)
* ??? why there is no value found, seems like Ignite is broken...
In a very safe implementation, we might yield a WARN in a client's (java
version don't have it yet if I remember correctly) or server's logs with
respect to the binary configuration mismatch and provide a user with the right
direction on how to fix that. But I'd say we need to implement the change just
like it's written in IEP and set compactFooter=serverValue. Well, we might add
just another Ignite property to disable this feature and some announcements in
release docs are welcome.
Anyway, my biggest concern is that - it's very confusing for the end-users.
WDYT?
> Java Thin Client: Retrieve binary configuration from server
> -----------------------------------------------------------
>
> Key: IGNITE-16038
> URL: https://issues.apache.org/jira/browse/IGNITE-16038
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
> Affects Versions: 2.11
> Reporter: Alexandr Shapkin
> Priority: Major
>
> Thin clients require manual binary configuration currently. Settings like
> compact footer and simple/full name mapper should be set to match the cluster
> settings. Extend the protocol to retrieve those settings automatically on
> start.
>
> I.e. it's impossible to read a value inserted by a thick client with java
> thin client without specifying compactFooter=true
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
