You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Alexandr Shapkin (Jira)" <ji...@apache.org> on 2021/12/02 13:17:00 UTC
[jira] [Comment Edited] (IGNITE-16038) Java Thin Client: Retrieve binary configuration from server
[ 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)