RE: Timeline for support of compute functions by thin clients

[Raymond Wilson]

It would be nice if C# thin clients can upload C# compute functions to C#
Ignite nodes, as can be done with the thick client.

-Original Message-
From: Sergey Kozlov [mailto:skoz...@gridgain.com]
Sent: Thursday, April 5, 2018 2:14 AM
To: dev@ignite.apache.org
Subject: Re: Timeline for support of compute functions by thin clients

I'm ok if it does not break the idea to restrict execution for the signed
code only.

On Wed, Apr 4, 2018 at 1:05 PM, Ilya Kasnacheev 
wrote:

> Hello!
>
> > checksum of uploaded java code
>
> I argue not for Java code but for javascript/nashorn. Ruby or PHP guys
> won't be happy about writing java, but they can easily do JS.
>
> (If we wanted Java, we could make it service grid-oriented. Which is
> an interesting idea btw. We can frame local computations as service
> methods, let thin clients invoke them. No code sending necessary in
> this case.)
>
> Otherwise your suggestions look reasonable. The only thing I'll add,
> let's make it a configuration field and not IGNITE_ define for usability.
>
> Regards,
>
> --
> Ilya Kasnacheev
>
> 2018-04-04 12:55 GMT+03:00 Sergey Kozlov :
>
> > Hi
> >
> > We can introduce the rules to use compute tasks execution:
> >  1. Disable by default that feature (enabling will require change a
> > configuration property and restart cluster)  2. Disable by default
> > code sending in the cluster  (enabling will
> require
> > change  a configuration property and restart cluster)  3. White list
> > of allowed compute tasks: we can collect sha256 checksums for codes
> > and allow to execute a task only if checksum of uploaded java code
> > is listed in the white list.
> >
> > On Wed, Apr 4, 2018 at 11:26 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > On Tue, Apr 3, 2018 at 5:48 PM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Dmitry,
> > > >
> > > > I just think that it's natural to have this functionality and
> > > > that it
> > > would
> > > > drastically increase flexibility of thin client. Multiple
> > > > requests
> from
> > > > users (one of them in this thread) seem to confirm this. At the
> > > > same
> > > time,
> > > > I don't see much technical challenge here (like with near caches
> > > > or continuous queries for example), and therefore don't see why
> > > > we
> should
> > be
> > > > against this features.
> > > >
> > > > Can you please elaborate on security risks? What exactly do you
> > > > have
> in
> > > > mind?
> > > >
> > >
> > > Val, my main concern was that users would use the thin client to
> connect
> > to
> > > a remote cluster, hosted elsewhere, and could run some malicious code.
> > But
> > > you are right, it can probably be solved by other means, like a
> firewall
> > > for example. No objections on adding the compute API to thin
> > > clients
> from
> > > me.
> > >
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>



--
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Timeline for support of compute functions by thin clients

[Sergey Kozlov]

I'm ok if it does not break the idea to restrict execution for the signed
code only.

On Wed, Apr 4, 2018 at 1:05 PM, Ilya Kasnacheev 
wrote:

> Hello!
>
> > checksum of uploaded java code
>
> I argue not for Java code but for javascript/nashorn. Ruby or PHP guys
> won't be happy about writing java, but they can easily do JS.
>
> (If we wanted Java, we could make it service grid-oriented. Which is an
> interesting idea btw. We can frame local computations as service methods,
> let thin clients invoke them. No code sending necessary in this case.)
>
> Otherwise your suggestions look reasonable. The only thing I'll add, let's
> make it a configuration field and not IGNITE_ define for usability.
>
> Regards,
>
> --
> Ilya Kasnacheev
>
> 2018-04-04 12:55 GMT+03:00 Sergey Kozlov :
>
> > Hi
> >
> > We can introduce the rules to use compute tasks execution:
> >  1. Disable by default that feature (enabling will require change a
> > configuration property and restart cluster)
> >  2. Disable by default code sending in the cluster  (enabling will
> require
> > change  a configuration property and restart cluster)
> >  3. White list of allowed compute tasks: we can collect sha256 checksums
> > for codes and allow to execute a task only if checksum of uploaded java
> > code is listed in the white list.
> >
> > On Wed, Apr 4, 2018 at 11:26 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > On Tue, Apr 3, 2018 at 5:48 PM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Dmitry,
> > > >
> > > > I just think that it's natural to have this functionality and that it
> > > would
> > > > drastically increase flexibility of thin client. Multiple requests
> from
> > > > users (one of them in this thread) seem to confirm this. At the same
> > > time,
> > > > I don't see much technical challenge here (like with near caches or
> > > > continuous queries for example), and therefore don't see why we
> should
> > be
> > > > against this features.
> > > >
> > > > Can you please elaborate on security risks? What exactly do you have
> in
> > > > mind?
> > > >
> > >
> > > Val, my main concern was that users would use the thin client to
> connect
> > to
> > > a remote cluster, hosted elsewhere, and could run some malicious code.
> > But
> > > you are right, it can probably be solved by other means, like a
> firewall
> > > for example. No objections on adding the compute API to thin clients
> from
> > > me.
> > >
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Timeline for support of compute functions by thin clients

[Ilya Kasnacheev]

Hello!

> checksum of uploaded java code

I argue not for Java code but for javascript/nashorn. Ruby or PHP guys
won't be happy about writing java, but they can easily do JS.

(If we wanted Java, we could make it service grid-oriented. Which is an
interesting idea btw. We can frame local computations as service methods,
let thin clients invoke them. No code sending necessary in this case.)

Otherwise your suggestions look reasonable. The only thing I'll add, let's
make it a configuration field and not IGNITE_ define for usability.

Regards,

-- 
Ilya Kasnacheev

2018-04-04 12:55 GMT+03:00 Sergey Kozlov :

> Hi
>
> We can introduce the rules to use compute tasks execution:
>  1. Disable by default that feature (enabling will require change a
> configuration property and restart cluster)
>  2. Disable by default code sending in the cluster  (enabling will require
> change  a configuration property and restart cluster)
>  3. White list of allowed compute tasks: we can collect sha256 checksums
> for codes and allow to execute a task only if checksum of uploaded java
> code is listed in the white list.
>
> On Wed, Apr 4, 2018 at 11:26 AM, Dmitriy Setrakyan 
> wrote:
>
> > On Tue, Apr 3, 2018 at 5:48 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Dmitry,
> > >
> > > I just think that it's natural to have this functionality and that it
> > would
> > > drastically increase flexibility of thin client. Multiple requests from
> > > users (one of them in this thread) seem to confirm this. At the same
> > time,
> > > I don't see much technical challenge here (like with near caches or
> > > continuous queries for example), and therefore don't see why we should
> be
> > > against this features.
> > >
> > > Can you please elaborate on security risks? What exactly do you have in
> > > mind?
> > >
> >
> > Val, my main concern was that users would use the thin client to connect
> to
> > a remote cluster, hosted elsewhere, and could run some malicious code.
> But
> > you are right, it can probably be solved by other means, like a firewall
> > for example. No objections on adding the compute API to thin clients from
> > me.
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

Re: Timeline for support of compute functions by thin clients

[Sergey Kozlov]

Hi

We can introduce the rules to use compute tasks execution:
 1. Disable by default that feature (enabling will require change a
configuration property and restart cluster)
 2. Disable by default code sending in the cluster  (enabling will require
change  a configuration property and restart cluster)
 3. White list of allowed compute tasks: we can collect sha256 checksums
for codes and allow to execute a task only if checksum of uploaded java
code is listed in the white list.

On Wed, Apr 4, 2018 at 11:26 AM, Dmitriy Setrakyan 
wrote:

> On Tue, Apr 3, 2018 at 5:48 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Dmitry,
> >
> > I just think that it's natural to have this functionality and that it
> would
> > drastically increase flexibility of thin client. Multiple requests from
> > users (one of them in this thread) seem to confirm this. At the same
> time,
> > I don't see much technical challenge here (like with near caches or
> > continuous queries for example), and therefore don't see why we should be
> > against this features.
> >
> > Can you please elaborate on security risks? What exactly do you have in
> > mind?
> >
>
> Val, my main concern was that users would use the thin client to connect to
> a remote cluster, hosted elsewhere, and could run some malicious code. But
> you are right, it can probably be solved by other means, like a firewall
> for example. No objections on adding the compute API to thin clients from
> me.
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Timeline for support of compute functions by thin clients

[Dmitriy Setrakyan]

On Tue, Apr 3, 2018 at 5:48 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Dmitry,
>
> I just think that it's natural to have this functionality and that it would
> drastically increase flexibility of thin client. Multiple requests from
> users (one of them in this thread) seem to confirm this. At the same time,
> I don't see much technical challenge here (like with near caches or
> continuous queries for example), and therefore don't see why we should be
> against this features.
>
> Can you please elaborate on security risks? What exactly do you have in
> mind?
>

Val, my main concern was that users would use the thin client to connect to
a remote cluster, hosted elsewhere, and could run some malicious code. But
you are right, it can probably be solved by other means, like a firewall
for example. No objections on adding the compute API to thin clients from
me.

Re: Timeline for support of compute functions by thin clients

[Valentin Kulichenko]

Dmitry,

I just think that it's natural to have this functionality and that it would
drastically increase flexibility of thin client. Multiple requests from
users (one of them in this thread) seem to confirm this. At the same time,
I don't see much technical challenge here (like with near caches or
continuous queries for example), and therefore don't see why we should be
against this features.

Can you please elaborate on security risks? What exactly do you have in
mind?

-Val

On Mon, Apr 2, 2018 at 9:40 PM, Dmitriy Setrakyan 
wrote:

> Val, my preference would be not to have compute functionality on thin
> clients, as it would introduce extra security risk.
>
> Any particular reason why you are asking for this feature?
>
> ⁣D.​
>
> On Apr 2, 2018, 8:47 PM, at 8:47 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
> >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.kuliche...@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
> >
> >> 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 
> >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
> >
> >>> > 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
> >
> >>> 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_wil...@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
> >func
> >>> =
> >>> > new
> >>> > > > > TileRenderRequestComputeFunc();
> >>> > > > >
> >>> > > > > return
> >>> > > > > 

Re: Timeline for support of compute functions by thin clients

[Vladimir Ozerov]

I do not see any additional risks provided that authentication and
authorization will be integrated with thin clients in the same way it is
done for "thick" clients.

On Tue, Apr 3, 2018 at 7:40 AM, Dmitriy Setrakyan 
wrote:

> Val, my preference would be not to have compute functionality on thin
> clients, as it would introduce extra security risk.
>
> Any particular reason why you are asking for this feature?
>
> ⁣D.​
>
> On Apr 2, 2018, 8:47 PM, at 8:47 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
> >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.kuliche...@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
> >
> >> 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 
> >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
> >
> >>> > 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
> >
> >>> 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_wil...@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
> >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.
> >>> 

Re: Timeline for support of compute functions by thin clients

[Dmitriy Setrakyan]

Val, my preference would be not to have compute functionality on thin clients, 
as it would introduce extra security risk.

Any particular reason why you are asking for this feature?

⁣D.​

On Apr 2, 2018, 8:47 PM, at 8:47 PM, Valentin Kulichenko 
 wrote:
>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.kuliche...@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
>
>> 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 
>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
>
>>> > 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
>
>>> 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_wil...@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
>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:dma...@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 

Re: Timeline for support of compute functions by thin clients

[Valentin Kulichenko]

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.kuliche...@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 
> 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  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 
>> > 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 
>> 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_wil...@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 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:dma...@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_wil...@trimble.com
>> > > > > > wrote:
>> > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > 

Re: Timeline for support of compute functions by thin clients

[Valentin Kulichenko]

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 
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  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 
> > 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 
> 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_wil...@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 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:dma...@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_wil...@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.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Timeline for support of compute functions by thin clients

[Vladimir Ozerov]

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  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 
> 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  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_wil...@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 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:dma...@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_wil...@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.
> > > > >
> > > >
> > >
> >
>

Re: Timeline for support of compute functions by thin clients

[Pavel Tupitsyn]

> for what
Literally no one wants to have JVM in their process and additional
dependencies :)
As much APIs as possible should be available in thin mode, that is the
point.

This thread is started by our user, after all :)

On Thu, Mar 15, 2018 at 10:25 PM, Denis Magda  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 
> 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  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_wil...@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 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:dma...@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_wil...@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.
> > > > >
> > > >
> > >
> >
>

Re: Timeline for support of compute functions by thin clients

[Denis Magda]

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 
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  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_wil...@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 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:dma...@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_wil...@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.
> > > >
> > >
> >
>

RE: Timeline for support of compute functions by thin clients

[Raymond Wilson]

There is no particular reason why we cannot use the regular one, so this is
not a blocker for us.

The Thin Client was attractive in that it allowed client contexts to be very
lightweight which aids aspects such as fine grained container scalability
(think AWS::Fargate/EKS).

-Original Message-
From: Denis Magda [mailto:dma...@apache.org]
Sent: Thursday, March 15, 2018 9:32 AM
To: dev@ignite.apache.org
Subject: Re: Timeline for support of compute functions by thin clients

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  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 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:dma...@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_wil...@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.
> >
>

Re: Timeline for support of compute functions by thin clients

[Pavel Tupitsyn]

I think there were plans to eventually cover whole set of existing APIs in
Thin Client mode.
Some APIs may be difficult to add (like Compute Task), but basic compute
methods (non-Task based) are easy to do.


On Wed, Mar 14, 2018 at 11:33 PM, Pavel Tupitsyn 
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  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_wil...@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 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:dma...@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_wil...@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.
>> > >
>> >
>>
>
>

Re: Timeline for support of compute functions by thin clients

[Pavel Tupitsyn]

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  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_wil...@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 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:dma...@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_wil...@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.
> > >
> >
>

Re: Timeline for support of compute functions by thin clients

[Denis Magda]

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  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 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:dma...@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_wil...@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.
> >
>

RE: Timeline for support of compute functions by thin clients

[Raymond Wilson]

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 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:dma...@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  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.
>

Re: Timeline for support of compute functions by thin clients

[Denis Magda]

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  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.
>

Timeline for support of compute functions by thin clients

[Raymond Wilson]

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.