[ 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)