Hi Val, No, I don't know why ClientException was introduced. Perhaps it was an attempt to strictly separate thin and thick implementations. But there still some API and thick implementation reused in thin client (BinaryObjects, Queries).
пт, 21 авг. 2020 г. в 23:28, Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Hi Alex, > > Do you know if there is any particular reason why we introduced > the ClientException in the first place? Generally, I believe that > consistency is a good thing, but there might be something that we're > missing. > > -Val > > On Fri, Aug 21, 2020 at 2:33 AM Alex Plehanov <plehanov.a...@gmail.com> > wrote: > > > Hello, Igniters! > > > > Since we touched on the subject of consistency across thin/thick APIs in > > thread [1] I would like to continue the discussion here. > > > > Currently, thick and thin APIs look similar but have no common parents. A > > set of ClientCache methods is almost a subset of IgniteCache methods, but > > these interfaces are fully independent. So we can't build common > > abstraction which can work with ClientCache and IgniteCache without code > > duplication. For example, we have ignite-spring-data module, to make it > > thin-client compliant we should copy-paste all cache methods invocations. > > > > It's impossible to make thin and thick interfaces absolutely identical > and > > we can't extend one from another since there thick and thin specific > > methods needed, but we can move common methods to the parent interface. > But > > here is another problem: exceptions. Thick methods declared as throwing > > IgniteException and IgniteCheckedException, but all thin-client > interfaces > > use ClientException. Without common exceptions for thin and thick > clients, > > we can't build common parent interface. > > > > Currently, only a small amount of thick interfaces can be fully reused by > > thin-client (Queries, IgniteBinary, ClusterNode) > > > > Also, I would like to discuss JCache support by thin-client. We already > use > > some of JCache specification for thin-client, but not fully support > JCache. > > For example, we use Cache.Entry for queries and JCache expiration > policies > > in public thin-client API (also, some of JCache interfaces are used by > the > > internal implementation). > > > > I've tried to implement POC for continuous queries for java thin client, > > but without JCache support API looks weird. On the one hand, we should > use > > CacheEntryEventFilter (JCache interface) since it's required by the > > server-side, on the other hand, we can't use CacheEntryUpdatedListener > > since it requires CacheEntryEvent which requires an instance of Cache > > (JCache interface), which doesn't exist on the thin-client side. > > > > We have plans to change public API in Ignite 3.0, perhaps it makes sense > to > > make thick and thin API consistent. WDYT? > > What about JCache support by thin-client in Ignite 3.0? > > Please, share your thoughts. > > > > [1]: > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/IEP-51-Java-Thin-Client-Async-API-td48900.html > > >
