ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: Timeline for support of compute functions by thin clients
Date Tue, 03 Apr 2018 03:46:30 GMT
Folks,

Any other thoughts on this? Should we create tickets for compute support if
there are no objections?

-Val

On Thu, Mar 22, 2018 at 4:27 PM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:

> I agree that compute and services functionality is important for thin
> client. It doesn't seem to be very hard to implement, but would provide
> much better flexibility, as users would be able to do remote invocation of
> arbitrary code, use collocated processing, etc. Having an ability to do
> this from a thin client without joining the topology is a huge advantage.
>
> -Val
>
> On Fri, Mar 16, 2018 at 4:00 AM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
>
>> Denis,
>>
>> From client perspective any compute task is also request - response. This
>> doesn't distinguish compute from any other API anyhow. There are no
>> problem
>> to add closures, tasks, services, etc.. What is really difficult is
>> components requiring non-trivial thread interaction and complex request
>> workflows. E.g. streaming, COPY command, continuous queries, events.
>>
>> On Thu, Mar 15, 2018 at 10:25 PM, Denis Magda <dmagda@apache.org> wrote:
>>
>> > Pavel,
>> >
>> > I just don't see a substantial reason why we need to support the
>> > compute APIs.
>> >
>> > As you properly mentioned, it's not easy to copy all the APIs and,
>> again,
>> > for what. It's right that the thin client allows decoupling .NET from
>> JVM,
>> > but its implementation won't be more performant than the regular
>> client's
>> > one.
>> >
>> > So, personally, a thin client (.NET, Node.JS, Java, Python, etc.) is a
>> > lightweight connection to the cluster that supports classic
>> client-server
>> > request-response operations. If someone needs more (compute, services,
>> > streaming, ML), then go for the regular client which is battle-tested
>> and
>> > available for usage.
>> >
>> > --
>> > Denis
>> >
>> >
>> >
>> > On Wed, Mar 14, 2018 at 1:33 PM, Pavel Tupitsyn <ptupitsyn@apache.org>
>> > wrote:
>> >
>> > > Hi Denis,
>> > >
>> > > > There are no any plans for that level of support
>> > > Why do you think so?
>> > > We already have ScanQuery with filter in .NET Thin Client, which
>> involves
>> > > remote code execution on server nodes.
>> > > It is quite similar to Compute.Broadcast and such.
>> > >
>> > > Thanks,
>> > > Pavel
>> > >
>> > >
>> > > On Wed, Mar 14, 2018 at 11:32 PM, Denis Magda <dmagda@apache.org>
>> wrote:
>> > >
>> > > > Raymond,
>> > > >
>> > > > Then I would suggest you keep using the regular .NET client that
>> > supports
>> > > > and optimized for computations. Is there any reason why you can't
>> use
>> > the
>> > > > regular one?
>> > > >
>> > > > --
>> > > > Denis
>> > > >
>> > > > On Wed, Mar 14, 2018 at 12:53 PM, Raymond Wilson <
>> > > > raymond_wilson@trimble.com
>> > > > > wrote:
>> > > >
>> > > > > Hi Denis,
>> > > > >
>> > > > > We are using Ignite.Net and are planning to use 2.4 + .Net Core
+
>> > thin
>> > > > > client support to enable lightweight containerisable services
that
>> > > > interact
>> > > > > with the main Ignite compute grid.
>> > > > >
>> > > > > These work flows are less about Get/Put style semantics, and
more
>> > about
>> > > > > using grid compute.
>> > > > >
>> > > > > Eg: Here's an example where a client context asks a remote
>> context to
>> > > > > render
>> > > > > a bitmap tile in an ICompute:
>> > > > >
>> > > > >         public Bitmap Execute(TileRenderRequestArgument arg)
>> > > > >         {
>> > > > >             IComputeFunc<TileRenderRequestArgument, Bitmap>
func
>> =
>> > new
>> > > > > TileRenderRequestComputeFunc();
>> > > > >
>> > > > >             return
>> > > > > _ignite.GetCluster().ForRemotes().GetCompute().Apply(func, arg);
>> > > > >         }
>> > > > >
>> > > > > In this example, the calling context here could be a lightweight
>> > > Kestrel
>> > > > > web
>> > > > > service end point delegating rendering to a remote service.
>> > > > >
>> > > > > Thanks,
>> > > > > Raymond.
>> > > > >
>> > > > > -----Original Message-----
>> > > > > From: Denis Magda [mailto:dmagda@apache.org]
>> > > > > Sent: Thursday, March 15, 2018 8:31 AM
>> > > > > To: dev@ignite.apache.org
>> > > > > Subject: Re: Timeline for support of compute functions by thin
>> > clients
>> > > > >
>> > > > > Hi Raymond,
>> > > > >
>> > > > > There are no any plans for that level of support. The thin clients
>> > are
>> > > > > targeted for classic client-server processing use cases when
a
>> client
>> > > > > request data from a server, does something with it locally and
>> > > > potentially
>> > > > > writes changes back to the server. ICache, SQL fall under this
>> > > category.
>> > > > >
>> > > > > Are you intended to use .NET thin client or anyone else?
>> > > > >
>> > > > > --
>> > > > > Denis
>> > > > >
>> > > > > On Wed, Mar 14, 2018 at 12:25 PM, Raymond Wilson <
>> > > > > raymond_wilson@trimble.com
>> > > > > > wrote:
>> > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > The thin client implementation in Ignite 2.4 only covers
a
>> subset
>> > of
>> > > > > > the ICache interface.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > When will we see thin client support for compute, messaging
etc?
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > Thanks,
>> > > > > >
>> > > > > > Raymond.
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message