Re: IGNITE-3999 review

[Nikolay Izhikov]

Hello, Amir.

Please, see my jira comment - 
https://issues.apache.org/jira/browse/IGNITE-3999?focusedCommentId=16426473=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16426473

В Ср, 04/04/2018 в 20:16 -0400, Amir Akhmedov пишет:
> Hi Nikolay,
> 
> Just a gentle reminder :)
> 
> Thanks,
> Amir
> 
> On Fri, Mar 30, 2018 at 12:29 PM, Nikolay Izhikov 
> wrote:
> 
> > I will take a look at the next week.
> > 
> > В Пт, 23/03/2018 в 09:50 +0700, Alexey Kuznetsov пишет:
> > > Vladimir,
> > > 
> > > As SQL expert, could you review this PR?
> > > 
> > > In this PR QueryEntity.java was changed. And it may impact whole SQL
> > 
> > engine.
> > > 

signature.asc
Description: This is a digitally signed message part

[jira] [Created] (IGNITE-8141) Improve OS config suggestions: SWAPPINESS

[Reed Sandberg (JIRA)]

Reed Sandberg created IGNITE-8141:
-

 Summary: Improve OS config suggestions: SWAPPINESS
 Key: IGNITE-8141
 URL: https://issues.apache.org/jira/browse/IGNITE-8141
 Project: Ignite
  Issue Type: Improvement
  Components: documentation
Affects Versions: 2.4
Reporter: Reed Sandberg
Assignee: Reed Sandberg


Acknowledge suggested SWAPPINESS OS param adjustment using a range (<= 10).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8140) Web console: "integer number too large" in generated project

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8140:
--

 Summary: Web console: "integer number too large" in generated 
project
 Key: IGNITE-8140
 URL: https://issues.apache.org/jira/browse/IGNITE-8140
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Vasiliy Sisko


Some methods expected Long type but we set Integer, please fix
{code}
dataStorageCfg.setSystemRegionMaxSize(2147483648);
eventStorage.setExpireAgeMs(2323232323232323);
cfg.setMetricsExpireTime(2323232323);
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8139) Need to have better control on the size of SQL on heap cache

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-8139:
---

 Summary: Need to have better control on the size of SQL on heap 
cache
 Key: IGNITE-8139
 URL: https://issues.apache.org/jira/browse/IGNITE-8139
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.4
Reporter: Valentin Kulichenko
Assignee: Vladimir Ozerov
 Fix For: 2.5


Currently, if SQL on heap cache is enabled, there is no clear way to control 
the size of this cache. Looks like its evictions basically depend on evictions 
in off-heap, so it's really to get OOME. Not very usable.

The easiest improvement would be to have a knob (configuration parameter or 
system property) that would control the size of underlying concurrent map that 
stores cached rows.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [jira] [Comment Edited] (IGNITE-6815) "Unexpected exception during cache update" via NullPointerException thrown using TouchedExpiryPolicy

[Denis Magda]

Done!

--
Denis

On Wed, Apr 4, 2018 at 9:48 AM, Dmitry Pavlov  wrote:

> Hi PMCs,
>
> Please add  Reed Sandberg
>  28304fdb5984eb426fbf6c20a71c2072a3339c6a;s=Reed+Sandberg;st=author>
>  
>  28304fdb5984eb426fbf6c20a71c2072a3339c6a;s=reed.sandberg@
> drawbridge.com;st=author>
> to
> contributor list so issue
> https://issues.apache.org/jira/browse/IGNITE-6815  can
> be assiged.
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 4 апр. 2018 г. в 19:08, Dmitry Pavlov :
>
> > Hi Reed,
> >
> > Could you please update https://issues.apache.org/
> jira/browse/IGNITE-6815 status
> > to Patch Available, so we can proceed with this contribution ?
> >
> > I saw second PR from you with some proposal for OS config advices. Could
> > you please create issue corresponding to this PR  and also set to Patch
> > Available. Probably we could discuss this proposal on dev.list and apply
> > this PR.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > P.S. full description of contribution process
> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> >
> > сб, 31 мар. 2018 г. в 21:23, Vyacheslav Daradur :
> >
> >> Hi Dmitry,
> >>
> >> Checkout to new branch and execute:
> >> git pull https://github.com/reed-sandberg/ignite.git
> >> rsandberg/IGNITE-6815-expiry-npe
> >>
> >> or just download and apply the patch:
> >> https://patch-diff.githubusercontent.com/raw/
> apache/ignite/pull/3726.patch
> >>
> >>
> >>
> >> On Fri, Mar 30, 2018 at 11:44 PM, Dmitry Pavlov 
> >> wrote:
> >> > Hi Igniters,
> >> >
> >> > Who could advice me how to create PR from these commits? Should PR be
> >> > always created by commit author?
> >> >
> >> > Hi Reed,
> >> >
> >> > could you please create PR so we could run tests on continious
> >> integration?
> >> >
> >> > Sincerely,
> >> > Dmitriy Pavlov
> >> >
> >> > -- Forwarded message -
> >> > From: Reed Sandberg (JIRA) 
> >> > Date: пт, 30 мар. 2018 г. в 22:51
> >> > Subject: [jira] [Comment Edited] (IGNITE-6815) "Unexpected exception
> >> during
> >> > cache update" via NullPointerException thrown using
> TouchedExpiryPolicy
> >> > To: 
> >> >
> >> >
> >> >
> >> > [
> >> >
> >> https://issues.apache.org/jira/browse/IGNITE-6815?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=16420872#comment-16420872
> >> > ]
> >> >
> >> > Reed Sandberg edited comment on IGNITE-6815 at 3/30/18 7:50 PM:
> >> > 
> >> >
> >> > The following has fixed the problem in our production environment
> >> (stable
> >> > for 3 months now)
> >> >
> >> >
> >> >
> >> > 2.3:
> >> >
> >> > [
> >> >
> >> https://github.com/reed-sandberg/ignite/commit/
> e6310e8d1481396f8cf3a5ede834989d0b277fc5
> >> > ]
> >> >
> >> >
> >> >
> >> > 2.4:
> >> >
> >> > [
> >> >
> >> https://github.com/reed-sandberg/ignite/commit/
> 29ffe10e7be5ce3193b2fcb89c713c5269761c1c
> >> > ]
> >> >
> >> >
> >> >
> >> >
> >> > was (Author: rsandberg):
> >> > The following has fixed the problem in our production environment
> >> (stable
> >> > for 3 months now)
> >> >
> >> >
> >> >
> >> >
> >> https://github.com/reed-sandberg/ignite/commit/
> e6310e8d1481396f8cf3a5ede834989d0b277fc5
> >> >
> >> >> "Unexpected exception during cache update" via NullPointerException
> >> > thrown using TouchedExpiryPolicy
> >> >>
> >> >
> >> 
> 
> >> >>
> >> >> Key: IGNITE-6815
> >> >> URL: https://issues.apache.org/
> jira/browse/IGNITE-6815
> >> >> Project: Ignite
> >> >>  Issue Type: Bug
> >> >>  Components: cache, streaming
> >> >>Affects Versions: 2.2, 2.3
> >> >> Environment: 4.10.0-33-generic #37~16.04.1-Ubuntu SMP Fri Aug
> >> 11
> >> > 14:07:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> >> >> Distributor ID:   LinuxMint
> >> >> Description:  Linux Mint 18.2 Sonya
> >> >> Release:  18.2
> >> >> Codename: sonya
> >> >>Reporter: Reed Sandberg
> >> >>Priority: Major
> >> >>
> >> >> This is triggered when I apply an expiry on the cache during an
> import
> >> > with StreamLoader, with no expiry on the cache, the import runs fine.
> >> >> Somehow the following line of code is hit with val == null:
> >> >>
> >> >
> >> org/apache/ignite/internal/processors/cache/
> IgniteCacheOffheapManagerImpl.java:1253
> >> >> Stack trace (version 2.3.0 release package from maven public repo):
> >> >> {noformat}
> >> >> 16:04:25.259 ERROR o.a.i.i.p.c.d.d.a.GridDhtAtomicCache -
> >> >  Unexpected exception during cache update
> >> >> org.apache.ignite.IgniteException: Runtime failure on search row:

Re: IGNITE-3999 review

[Amir Akhmedov]

Hi Nikolay,

Just a gentle reminder :)

Thanks,
Amir

On Fri, Mar 30, 2018 at 12:29 PM, Nikolay Izhikov 
wrote:

> I will take a look at the next week.
>
> В Пт, 23/03/2018 в 09:50 +0700, Alexey Kuznetsov пишет:
> > Vladimir,
> >
> > As SQL expert, could you review this PR?
> >
> > In this PR QueryEntity.java was changed. And it may impact whole SQL
> engine.
> >
>

Re: Contribute to Apache Ignite

[Denis Magda]

Welcome aboard Sergey! I've added you to the contributors' list in JIRA.

--
Denis

On Wed, Apr 4, 2018 at 3:59 PM, Serg Skudnov  wrote:

> Hello, Ignite Community.
>
> I want to start contribute to Apache Ignite, starting with that ticket:
> https://issues.apache.org/jira/browse/IGNITE-8138
>
> Please, add me to the contributors list.
>
> Jira Username: coil
> Full Name:Sergey Skudnov
>
> Thanx.
>

Re: Service grid redesign

[Valentin Kulichenko]

I don't think peer class loading is even possible for services. I believe
we should reuse DeploymentSpi [1] for versioning.

[1] https://apacheignite.readme.io/docs/deployment-spi

-Val

On Wed, Apr 4, 2018 at 12:52 PM, Denis Magda  wrote:

> Sorry, that was me who renamed the IEP to "Oil Change in Service Grid". Was
> writing this email after the renaming. Like that title more because it's
> fun and highlights what we're intended to do - cleaning of our service grid
> engine and powering it up with new "liquid" (new communication and
> deployment approach not available before).
>
> Denis
>
>
> > This message contains serialized service instance and its configuration.
> > It is delivered to the coordinator node first, that calculates the
> service
> > deployment assignments and adds this information to the message.
>
>
> I would consider using a NodeFilter first to decide where a service can be
> potentially deployed.  Otherwise, we would require service classes to be on
> every node (every node might become a coordinator) which is not the desired
> requirement.
>
>
> As for the peer-class-loading, I would backup up Dmitriy here. Let's at
> least not to focus on this task for now. We should design services
> versioning in the right way first and support it.
>
> --
> Denis
>
>
>
> On Wed, Apr 4, 2018 at 12:20 PM, Dmitriy Setrakyan 
> wrote:
>
> > Here is the correct link:
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > 17%3A+Oil+Change+in+Service+Grid
> >
> > I have looked at the tickets there, and I believe that we should not
> > support peer-deployment for services. It is very hard and I do not think
> we
> > should even try.
> >
> > I am proposing closing this ticket as Won't Fix -
> > https://issues.apache.org/jira/browse/IGNITE-975
> >
> > D.
> >
> > On Wed, Apr 4, 2018 at 5:39 AM, Denis Mekhanikov 
> > wrote:
> >
> > > Vyacheslav,
> > >
> > > I've just posted my first draft of the IEP:
> > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > 17%3A+Service+grid+
> > > improvements
> > > It's not finished yet, but you can get the idea from it.
> > > If you have some thoughts on your mind, please let me know, I'll add
> them
> > > to the IEP.
> > >
> > > Denis
> > >
> > > ср, 4 апр. 2018 г. в 13:09, Vyacheslav Daradur :
> > >
> > > > Denis, thanks for the link.
> > > >
> > > > I looked through the task and I think that understand your redesign
> > point
> > > > now.
> > > >
> > > > Do you have a clear plan or IEP for the whole redesign?
> > > >
> > > > I'm interested in this component and I'd like to take part in the
> > > > development.
> > > >
> > > >
> > > >
> > > > On Mon, Apr 2, 2018 at 2:55 PM, Denis Mekhanikov <
> > dmekhani...@gmail.com>
> > > > wrote:
> > > > > Vyacheslav,
> > > > >
> > > > > Service deployment design, based on replicated utility cache has
> > proven
> > > > to
> > > > > be unstable and deadlock-prone.
> > > > > You can find a list of JIRA issues, connected to it, in my previous
> > > > letter.
> > > > >
> > > > > The intention behind it is similar to the binary metadata redesign,
> > > that
> > > > > happened in the following ticket: IGNITE-4157
> > > > > 
> > > > > This change in service deployment procedure will eliminate need for
> > > > another
> > > > > internal replicated cache
> > > > > and make service deployment more reliable on unstable topology.
> > > > >
> > > > > Denis
> > > > >
> > > > > вт, 27 мар. 2018 г. в 23:21, Vyacheslav Daradur <
> daradu...@gmail.com
> > >:
> > > > >
> > > > >> Hi, Denis Mekhanikov!
> > > > >>
> > > > >> As far as I know, Ignite services are based on IgniteCache and we
> > have
> > > > >> all its features. We can use listeners or continuous queries for
> > > > >> deployment synchronizations.
> > > > >>
> > > > >> Why do you want using the discovery layer for that?
> > > > >>
> > > > >> One more thing: we can use baseline approach for services, that
> > means
> > > > >> *IgniteService.deploy()* returns ready to work service after
> > > > >> deployment on baseline nodes and deploy to other nodes on demand,
> > for
> > > > >> example when deployed service's loading will be hight.
> > > > >>
> > > > >> About versioning, maybe there is sense to extend public API:
> > > > >> IgniteServices.service(name, *version*)?
> > > > >>
> > > > >> At first deployment, we can compute service's hashcode (just for
> an
> > > > >> example) and store it, after new deployment request for services
> > with
> > > > >> an existing name we will compute new service's hashcode and
> compare
> > > > >> them if they have different hashcodes that we will deploy new
> > service
> > > > >> as service with a different version.
> > > > >>
> > > > >>
> > > > >> On Fri, Mar 23, 2018 at 10:03 PM, Denis Magda 
> > > > wrote:
> > > > >> > Denis,
> > > > >> >
> > > > >> > Thanks for the extensive 

Contribute to Apache Ignite

[Serg Skudnov]

Hello, Ignite Community.

I want to start contribute to Apache Ignite, starting with that ticket:
https://issues.apache.org/jira/browse/IGNITE-8138

Please, add me to the contributors list.

Jira Username: coil
Full Name:Sergey Skudnov

Thanx.

[jira] [Created] (IGNITE-8138) Incorrect uptime in GG metrics for long running server node (1+ days)

[Max Shonichev (JIRA)]

Max Shonichev created IGNITE-8138:
-

 Summary: Incorrect uptime in GG metrics for long running server 
node (1+ days)
 Key: IGNITE-8138
 URL: https://issues.apache.org/jira/browse/IGNITE-8138
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4, 2.1
Reporter: Max Shonichev
 Fix For: 2.5


Ignite prints a metrics to the log with uptime, formatted as 'XX:YY:ZZ:TTT'.
It looks, like XX corresponds to hours, YY to minutes, ZZ to seconds, however 
if we filter uptime metric from a long running server (few days), we would see 
that :

{noformat}
 ^-- Node [id=684d2761, name=null, uptime=00:01:00:009]
 ^-- Node [id=684d2761, name=null, uptime=00:02:00:009]
 ^-- Node [id=684d2761, name=null, uptime=00:03:00:009]
 ^-- Node [id=684d2761, name=null, uptime=00:04:00:021]
...
 ^-- Node [id=684d2761, name=null, uptime=23:58:08:391]
 ^-- Node [id=684d2761, name=null, uptime=23:59:08:393]
 ^-- Node [id=684d2761, name=null, uptime=24:00:08:395]
 ^-- Node [id=684d2761, name=null, uptime=24:01:08:406]
...
 ^-- Node [id=684d2761, name=null, uptime=59:59:23:542]
 ^-- Node [id=684d2761, name=null, uptime=00:00:23:554]
...
{noformat}

BUG:
1. hours do not rollover at 23:59:59
2. there's no simple means for user to get uptime days, because hours do 
actually rollover after 59:59:59

what is expected: 
 1. add a day counter, init with 0
 2. make hours correctly rollover after full day (24hrs) run
{noformat}
 ^-- Node [id=684d2761, name=null, uptime=0:00:01:00:009]
...
 ^-- Node [id=684d2761, name=null, uptime=0:23:59:00:009]
 ^-- Node [id=684d2761, name=null, uptime=1:00:00:00:009]
...
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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: IGNITE-6879

[Denis Magda]

Hi guys,

According to ASF stats our spring data integration is 2 times more popular
than spark integraion - 900 maven downloads vs. 400.

So I would suggest us creating ignite-spring-data-2.0 module to support new
deployments and leave ignite-spring-data to not break existing ones.

--
Denis



On Wed, Apr 4, 2018 at 7:33 AM, Dmitry Pavlov  wrote:

> Hi Igniters,
>
> I am going to review these changes in 3-4 days. If everything is ok and if
> there is no objections, I will merge it.
>
> Hi Denis,
>
> are you agree with proposed change?
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 4 апр. 2018 г. в 14:26, Дмитрий Рябов :
>
> > I agree that increasing complexity isn't good idea. Roman, can you
> document
> > the migration guide?
> >
> > 2018-04-04 13:41 GMT+03:00 Alexey Kukushkin :
> >
> > > Roman, Dmitry,
> > >
> > > I also reviewed the fix and the code looks OK to me. But the fix has
> > > significant implication - Ignite no longer can be used with spring-data
> > 1.0
> > > due to no backward compatibility between spring 2.0 and 1.0 APIs. With
> > this
> > > approach we must remember to add corresponding spring-data migration
> > > instructions to the future ignite 2.5 migration guide.
> > >
> > > We could keep spring 1 support and backward compatibility by creating a
> > new
> > > module "ignite-spring-2-data" and keeping existing ignite-spring-data
> as
> > > is. I do not like this option since to me increased complexity and
> > > maintainability costs overweight the benefits of protecting
> > > "Ignite-spring-1" users.
> > >
> > > I suggest you find a committer (see this list
> > > ),
> > communicate
> > > the implication I mentioned above and say that two people already
> > approved
> > > the code providing we are OK with the chosen approach.
> > >
> >
>

Re: Data Loss while upgrading custom jar from old jar in server and client nodes

[Denis Magda]

Ivan R., Alex G., persistence experts,

Please have a look at this question.

--
Denis

On Mon, Apr 2, 2018 at 6:15 AM, Andrey Mashenkov  wrote:

> Crossposting to dev.
>
> Guys,
> User use Ignite native persistence with CacheStore configured.
> Seems, changing CacheStore requires cache recreation in his case to changes
> can be applied.
>
> Does anybody has idea how it can be fixed?
>
> Do we allow to rewrite cache config in native store if it has minor changes
> that will not cause issues? E.g. changing cacheStore factory or changing
> number of backups?
> Otherwise, I'd suggest to deprecate such configuration.
>
>
> On Tue, Mar 27, 2018 at 4:18 PM, siva  wrote:
>
> > Hi,
> >
> > Thanks for checking out issue. I think its not about IDE issue.
> > Again same thing i have reproduce like bellow steps
> >
> > 1.run the program from IDE as client
> > 2.copy jar to ignite libs folder and start the server
> > 3.Then check previous message steps so that can able to reproduce the
> > issue.
> > https://www.youtube.com/watch?v=COQiu2gi8ag=43s
> > 
> > I have attached the video link.Can you go through that video and check
> the
> > issue.
> >
> >
> > Thanks
> >
> >
> >
> > --
> > Sent from: http://apache-ignite-users.70518.x6.nabble.com/
> >
>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

Re: Service grid redesign

[Denis Magda]

Sorry, that was me who renamed the IEP to "Oil Change in Service Grid". Was
writing this email after the renaming. Like that title more because it's
fun and highlights what we're intended to do - cleaning of our service grid
engine and powering it up with new "liquid" (new communication and
deployment approach not available before).

Denis


> This message contains serialized service instance and its configuration.
> It is delivered to the coordinator node first, that calculates the service
> deployment assignments and adds this information to the message.


I would consider using a NodeFilter first to decide where a service can be
potentially deployed.  Otherwise, we would require service classes to be on
every node (every node might become a coordinator) which is not the desired
requirement.


As for the peer-class-loading, I would backup up Dmitriy here. Let's at
least not to focus on this task for now. We should design services
versioning in the right way first and support it.

--
Denis



On Wed, Apr 4, 2018 at 12:20 PM, Dmitriy Setrakyan 
wrote:

> Here is the correct link:
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> 17%3A+Oil+Change+in+Service+Grid
>
> I have looked at the tickets there, and I believe that we should not
> support peer-deployment for services. It is very hard and I do not think we
> should even try.
>
> I am proposing closing this ticket as Won't Fix -
> https://issues.apache.org/jira/browse/IGNITE-975
>
> D.
>
> On Wed, Apr 4, 2018 at 5:39 AM, Denis Mekhanikov 
> wrote:
>
> > Vyacheslav,
> >
> > I've just posted my first draft of the IEP:
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> 17%3A+Service+grid+
> > improvements
> > It's not finished yet, but you can get the idea from it.
> > If you have some thoughts on your mind, please let me know, I'll add them
> > to the IEP.
> >
> > Denis
> >
> > ср, 4 апр. 2018 г. в 13:09, Vyacheslav Daradur :
> >
> > > Denis, thanks for the link.
> > >
> > > I looked through the task and I think that understand your redesign
> point
> > > now.
> > >
> > > Do you have a clear plan or IEP for the whole redesign?
> > >
> > > I'm interested in this component and I'd like to take part in the
> > > development.
> > >
> > >
> > >
> > > On Mon, Apr 2, 2018 at 2:55 PM, Denis Mekhanikov <
> dmekhani...@gmail.com>
> > > wrote:
> > > > Vyacheslav,
> > > >
> > > > Service deployment design, based on replicated utility cache has
> proven
> > > to
> > > > be unstable and deadlock-prone.
> > > > You can find a list of JIRA issues, connected to it, in my previous
> > > letter.
> > > >
> > > > The intention behind it is similar to the binary metadata redesign,
> > that
> > > > happened in the following ticket: IGNITE-4157
> > > > 
> > > > This change in service deployment procedure will eliminate need for
> > > another
> > > > internal replicated cache
> > > > and make service deployment more reliable on unstable topology.
> > > >
> > > > Denis
> > > >
> > > > вт, 27 мар. 2018 г. в 23:21, Vyacheslav Daradur  >:
> > > >
> > > >> Hi, Denis Mekhanikov!
> > > >>
> > > >> As far as I know, Ignite services are based on IgniteCache and we
> have
> > > >> all its features. We can use listeners or continuous queries for
> > > >> deployment synchronizations.
> > > >>
> > > >> Why do you want using the discovery layer for that?
> > > >>
> > > >> One more thing: we can use baseline approach for services, that
> means
> > > >> *IgniteService.deploy()* returns ready to work service after
> > > >> deployment on baseline nodes and deploy to other nodes on demand,
> for
> > > >> example when deployed service's loading will be hight.
> > > >>
> > > >> About versioning, maybe there is sense to extend public API:
> > > >> IgniteServices.service(name, *version*)?
> > > >>
> > > >> At first deployment, we can compute service's hashcode (just for an
> > > >> example) and store it, after new deployment request for services
> with
> > > >> an existing name we will compute new service's hashcode and compare
> > > >> them if they have different hashcodes that we will deploy new
> service
> > > >> as service with a different version.
> > > >>
> > > >>
> > > >> On Fri, Mar 23, 2018 at 10:03 PM, Denis Magda 
> > > wrote:
> > > >> > Denis,
> > > >> >
> > > >> > Thanks for the extensive analysis. There is a vast room for
> > > optimizations
> > > >> > on the service grid side.
> > > >> >
> > > >> > Yakov, Sam, Alex G.,
> > > >> >
> > > >> > How do you like the idea of the usage of discovery protocol for
> the
> > > >> service
> > > >> > grid system messages exchange? Any pitfalls?
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Denis
> > > >> >
> > > >> >
> > > >> > On Fri, Mar 23, 2018 at 8:01 AM, Denis Mekhanikov <
> > > dmekhani...@gmail.com
> > > >> >
> > > >> > wrote:
> > > >> >
> > > >> >> Igniters,
> > > 

Re: Memory usage per cache

[Dmitriy Setrakyan]

On Wed, Apr 4, 2018 at 5:27 AM, Alexey Goncharuk  wrote:

> Denis,
>
> I think this particular metric should be deprecated. The most we can do
> about it is to return the actual allocated size when a cache is the only
> cache in a group and return -1 if there are multiple caches in a group.
> However, this does not look like a consistent approach to me, so I would
> prefer to always return -1 and suggest that users use corresponding cache
> group metrics.
>

Why not return cache group metrics from this method by default and properly
document it?

Re: Service grid redesign

[Dmitriy Setrakyan]

Here is the correct link:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-17%3A+Oil+Change+in+Service+Grid

I have looked at the tickets there, and I believe that we should not
support peer-deployment for services. It is very hard and I do not think we
should even try.

I am proposing closing this ticket as Won't Fix -
https://issues.apache.org/jira/browse/IGNITE-975

D.

On Wed, Apr 4, 2018 at 5:39 AM, Denis Mekhanikov 
wrote:

> Vyacheslav,
>
> I've just posted my first draft of the IEP:
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-17%3A+Service+grid+
> improvements
> It's not finished yet, but you can get the idea from it.
> If you have some thoughts on your mind, please let me know, I'll add them
> to the IEP.
>
> Denis
>
> ср, 4 апр. 2018 г. в 13:09, Vyacheslav Daradur :
>
> > Denis, thanks for the link.
> >
> > I looked through the task and I think that understand your redesign point
> > now.
> >
> > Do you have a clear plan or IEP for the whole redesign?
> >
> > I'm interested in this component and I'd like to take part in the
> > development.
> >
> >
> >
> > On Mon, Apr 2, 2018 at 2:55 PM, Denis Mekhanikov 
> > wrote:
> > > Vyacheslav,
> > >
> > > Service deployment design, based on replicated utility cache has proven
> > to
> > > be unstable and deadlock-prone.
> > > You can find a list of JIRA issues, connected to it, in my previous
> > letter.
> > >
> > > The intention behind it is similar to the binary metadata redesign,
> that
> > > happened in the following ticket: IGNITE-4157
> > > 
> > > This change in service deployment procedure will eliminate need for
> > another
> > > internal replicated cache
> > > and make service deployment more reliable on unstable topology.
> > >
> > > Denis
> > >
> > > вт, 27 мар. 2018 г. в 23:21, Vyacheslav Daradur :
> > >
> > >> Hi, Denis Mekhanikov!
> > >>
> > >> As far as I know, Ignite services are based on IgniteCache and we have
> > >> all its features. We can use listeners or continuous queries for
> > >> deployment synchronizations.
> > >>
> > >> Why do you want using the discovery layer for that?
> > >>
> > >> One more thing: we can use baseline approach for services, that means
> > >> *IgniteService.deploy()* returns ready to work service after
> > >> deployment on baseline nodes and deploy to other nodes on demand, for
> > >> example when deployed service's loading will be hight.
> > >>
> > >> About versioning, maybe there is sense to extend public API:
> > >> IgniteServices.service(name, *version*)?
> > >>
> > >> At first deployment, we can compute service's hashcode (just for an
> > >> example) and store it, after new deployment request for services with
> > >> an existing name we will compute new service's hashcode and compare
> > >> them if they have different hashcodes that we will deploy new service
> > >> as service with a different version.
> > >>
> > >>
> > >> On Fri, Mar 23, 2018 at 10:03 PM, Denis Magda 
> > wrote:
> > >> > Denis,
> > >> >
> > >> > Thanks for the extensive analysis. There is a vast room for
> > optimizations
> > >> > on the service grid side.
> > >> >
> > >> > Yakov, Sam, Alex G.,
> > >> >
> > >> > How do you like the idea of the usage of discovery protocol for the
> > >> service
> > >> > grid system messages exchange? Any pitfalls?
> > >> >
> > >> >
> > >> > --
> > >> > Denis
> > >> >
> > >> >
> > >> > On Fri, Mar 23, 2018 at 8:01 AM, Denis Mekhanikov <
> > dmekhani...@gmail.com
> > >> >
> > >> > wrote:
> > >> >
> > >> >> Igniters,
> > >> >>
> > >> >> I'd like to start a discussion on Ignite service grid redesign.
> > >> >> We have a number of problems in our current architecture, that have
> > to
> > >> be
> > >> >> addressed.
> > >> >>
> > >> >> Here are the most severe ones:
> > >> >>
> > >> >> One of them is lack of guarantee, that service is successfully
> > deployed
> > >> and
> > >> >> ready for work by the time, when *IgniteService.deploy*()* methods
> > >> return.
> > >> >> Furthermore, if an exception is thrown from *Service.init()
> *method,
> > >> then
> > >> >> the deploying side is not able to receive it, or even understand,
> > that
> > >> >> service is in unusable state.
> > >> >> So, you may end up in such situation, when you deployed a service
> > >> without
> > >> >> receiving any errors, then called a service's method, and hung
> > >> indefinitely
> > >> >> on this invocation.
> > >> >> JIRA ticket: https://issues.apache.org/jira/browse/IGNITE-3392
> > >> >>
> > >> >> Another problem is locking during service deployment on unstable
> > >> topology.
> > >> >> This issue is caused by missing updates in continuous query
> > listeners on
> > >> >> the internal cache.
> > >> >> It is hard to reproduce, but it happens sometimes. We shouldn't
> allow
> > >> such
> > >> >> possibility, that deployment methods hang without saying 

Apache Ignite 2.5 release

[Andrey Gura]

Igniters,

It's time to create branch for upcoming Apache Ignite 2.5 release in
order to start stabilization process.

If there are no any objections I'll create ignite-2.5 branch tomorrow.

Also please check JIRA issues assigned to you and move it to the next
version if this issues shouldn't be included to 2.5 release.

Release page on wiki [1] contains all issues targeted to 2.5 (fix
version field).

[1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.5

[jira] [Created] (IGNITE-8137) Explain how to see SQL schema and table structure in Ignite

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8137:
---

 Summary: Explain how to see SQL schema and table structure in 
Ignite
 Key: IGNITE-8137
 URL: https://issues.apache.org/jira/browse/IGNITE-8137
 Project: Ignite
  Issue Type: New Feature
  Components: documentation
Reporter: Denis Magda
 Fix For: 2.6


Presently, Ignite doesn't ship {{SHOW TABLE}} command. Thus, it's not clear how 
to get tables and schema structures in Ignite. 

Until this command is not supported we have to explain that:
* Many tools use JDBC and ODBC metadata related parameters can pull that 
information out of there and present it to an end user. For instance, SQLline 
utilizes {{!table}} command that gets data from JDBC metadata methods. DBeaver 
utilizes the same approach.
* Let's create {{Database Administration}} section under SQL reference 
(https://apacheignite-sql.readme.io/docs/sql-reference-overview) and presently 
list approaches supported by various tools (sqlline, dbeaver, etc) and how to 
get the same information from the drivers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3750: Ignite PDS 1 (Direct IO): failed test IgnitePdsCh...

[dspavlov]

GitHub user dspavlov opened a pull request:

https://github.com/apache/ignite/pull/3750

Ignite PDS 1 (Direct IO): failed test 
IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testDirtyFlag()



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-7680

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3750.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3750


commit 0b5e1eba17a788f94759914128fd2770e30103e7
Author: dpavlov 
Date:   2018-04-03T18:07:56Z

IGNITE-7680: Test Dirty flag, added more debug info

commit 0c817db0c969fdff80cd63988d3ee3120d17b75e
Author: dpavlov 
Date:   2018-04-04T11:34:11Z

IGNITE-7680: Javadocs

commit 727057b13e26c25bcb4ce72b0ef8923ff9727f5b
Author: dpavlov 
Date:   2018-04-04T18:04:57Z

IGNITE-7680: Test fix




---

Re: [jira] [Comment Edited] (IGNITE-6815) "Unexpected exception during cache update" via NullPointerException thrown using TouchedExpiryPolicy

[Dmitry Pavlov]

Hi PMCs,

Please add  Reed Sandberg

 

to
contributor list so issue
https://issues.apache.org/jira/browse/IGNITE-6815  can
be assiged.

Sincerely,
Dmitriy Pavlov

ср, 4 апр. 2018 г. в 19:08, Dmitry Pavlov :

> Hi Reed,
>
> Could you please update https://issues.apache.org/jira/browse/IGNITE-6815 
> status
> to Patch Available, so we can proceed with this contribution ?
>
> I saw second PR from you with some proposal for OS config advices. Could
> you please create issue corresponding to this PR  and also set to Patch
> Available. Probably we could discuss this proposal on dev.list and apply
> this PR.
>
> Sincerely,
> Dmitriy Pavlov
>
> P.S. full description of contribution process
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>
> сб, 31 мар. 2018 г. в 21:23, Vyacheslav Daradur :
>
>> Hi Dmitry,
>>
>> Checkout to new branch and execute:
>> git pull https://github.com/reed-sandberg/ignite.git
>> rsandberg/IGNITE-6815-expiry-npe
>>
>> or just download and apply the patch:
>> https://patch-diff.githubusercontent.com/raw/apache/ignite/pull/3726.patch
>>
>>
>>
>> On Fri, Mar 30, 2018 at 11:44 PM, Dmitry Pavlov 
>> wrote:
>> > Hi Igniters,
>> >
>> > Who could advice me how to create PR from these commits? Should PR be
>> > always created by commit author?
>> >
>> > Hi Reed,
>> >
>> > could you please create PR so we could run tests on continious
>> integration?
>> >
>> > Sincerely,
>> > Dmitriy Pavlov
>> >
>> > -- Forwarded message -
>> > From: Reed Sandberg (JIRA) 
>> > Date: пт, 30 мар. 2018 г. в 22:51
>> > Subject: [jira] [Comment Edited] (IGNITE-6815) "Unexpected exception
>> during
>> > cache update" via NullPointerException thrown using TouchedExpiryPolicy
>> > To: 
>> >
>> >
>> >
>> > [
>> >
>> https://issues.apache.org/jira/browse/IGNITE-6815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16420872#comment-16420872
>> > ]
>> >
>> > Reed Sandberg edited comment on IGNITE-6815 at 3/30/18 7:50 PM:
>> > 
>> >
>> > The following has fixed the problem in our production environment
>> (stable
>> > for 3 months now)
>> >
>> >
>> >
>> > 2.3:
>> >
>> > [
>> >
>> https://github.com/reed-sandberg/ignite/commit/e6310e8d1481396f8cf3a5ede834989d0b277fc5
>> > ]
>> >
>> >
>> >
>> > 2.4:
>> >
>> > [
>> >
>> https://github.com/reed-sandberg/ignite/commit/29ffe10e7be5ce3193b2fcb89c713c5269761c1c
>> > ]
>> >
>> >
>> >
>> >
>> > was (Author: rsandberg):
>> > The following has fixed the problem in our production environment
>> (stable
>> > for 3 months now)
>> >
>> >
>> >
>> >
>> https://github.com/reed-sandberg/ignite/commit/e6310e8d1481396f8cf3a5ede834989d0b277fc5
>> >
>> >> "Unexpected exception during cache update" via NullPointerException
>> > thrown using TouchedExpiryPolicy
>> >>
>> >
>> 
>> >>
>> >> Key: IGNITE-6815
>> >> URL: https://issues.apache.org/jira/browse/IGNITE-6815
>> >> Project: Ignite
>> >>  Issue Type: Bug
>> >>  Components: cache, streaming
>> >>Affects Versions: 2.2, 2.3
>> >> Environment: 4.10.0-33-generic #37~16.04.1-Ubuntu SMP Fri Aug
>> 11
>> > 14:07:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>> >> Distributor ID:   LinuxMint
>> >> Description:  Linux Mint 18.2 Sonya
>> >> Release:  18.2
>> >> Codename: sonya
>> >>Reporter: Reed Sandberg
>> >>Priority: Major
>> >>
>> >> This is triggered when I apply an expiry on the cache during an import
>> > with StreamLoader, with no expiry on the cache, the import runs fine.
>> >> Somehow the following line of code is hit with val == null:
>> >>
>> >
>> org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:1253
>> >> Stack trace (version 2.3.0 release package from maven public repo):
>> >> {noformat}
>> >> 16:04:25.259 ERROR o.a.i.i.p.c.d.d.a.GridDhtAtomicCache -
>> >  Unexpected exception during cache update
>> >> org.apache.ignite.IgniteException: Runtime failure on search row:
>> > org.apache.ignite.internal.processors.cache.tree.SearchRow@68a4e885
>> >>   at
>> >
>> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1632)
>> >>   at
>> >
>> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1201)
>> >>   at
>> >
>> 

[GitHub] ignite pull request #3726: IGNITE-6815 NPE when using expiry policy

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3726


---

[jira] [Created] (IGNITE-8136) Discovery service wrong works if node stopping by segmentation and hangs

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-8136:
-

 Summary: Discovery service wrong works if node stopping by 
segmentation and hangs
 Key: IGNITE-8136
 URL: https://issues.apache.org/jira/browse/IGNITE-8136
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3749: IGNITE-6892 OOM should be covered by failure hand...

[alex-plekhanov]

GitHub user alex-plekhanov opened a pull request:

https://github.com/apache/ignite/pull/3749

IGNITE-6892 OOM should be covered by failure handler



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/alex-plekhanov/ignite ignite-6892

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3749.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3749


commit e48e8978298995821aa19f8229692ba398ff4bde
Author: Aleksey Plekhanov 
Date:   2018-04-04T13:45:32Z

IGNITE-6892 OOM should be covered by failure handling

commit 2d60b0a760ff88589fe373eba7ebf03ffaeefe1e
Author: Aleksey Plekhanov 
Date:   2018-04-04T15:56:08Z

IGNITE-6892 OOM should be covered by failure handling (unit test)

commit f9af47c175aa78ca6f48b652fe1d76a94d019cb6
Author: Aleksey Plekhanov 
Date:   2018-04-04T16:12:10Z

IGNITE-6892 OOM should be covered by failure handling (typo)




---

Re: [jira] [Comment Edited] (IGNITE-6815) "Unexpected exception during cache update" via NullPointerException thrown using TouchedExpiryPolicy

[Dmitry Pavlov]

Hi Reed,

Could you please update
https://issues.apache.org/jira/browse/IGNITE-6815 status
to Patch Available, so we can proceed with this contribution ?

I saw second PR from you with some proposal for OS config advices. Could
you please create issue corresponding to this PR  and also set to Patch
Available. Probably we could discuss this proposal on dev.list and apply
this PR.

Sincerely,
Dmitriy Pavlov

P.S. full description of contribution process
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

сб, 31 мар. 2018 г. в 21:23, Vyacheslav Daradur :

> Hi Dmitry,
>
> Checkout to new branch and execute:
> git pull https://github.com/reed-sandberg/ignite.git
> rsandberg/IGNITE-6815-expiry-npe
>
> or just download and apply the patch:
> https://patch-diff.githubusercontent.com/raw/apache/ignite/pull/3726.patch
>
>
>
> On Fri, Mar 30, 2018 at 11:44 PM, Dmitry Pavlov 
> wrote:
> > Hi Igniters,
> >
> > Who could advice me how to create PR from these commits? Should PR be
> > always created by commit author?
> >
> > Hi Reed,
> >
> > could you please create PR so we could run tests on continious
> integration?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > -- Forwarded message -
> > From: Reed Sandberg (JIRA) 
> > Date: пт, 30 мар. 2018 г. в 22:51
> > Subject: [jira] [Comment Edited] (IGNITE-6815) "Unexpected exception
> during
> > cache update" via NullPointerException thrown using TouchedExpiryPolicy
> > To: 
> >
> >
> >
> > [
> >
> https://issues.apache.org/jira/browse/IGNITE-6815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16420872#comment-16420872
> > ]
> >
> > Reed Sandberg edited comment on IGNITE-6815 at 3/30/18 7:50 PM:
> > 
> >
> > The following has fixed the problem in our production environment (stable
> > for 3 months now)
> >
> >
> >
> > 2.3:
> >
> > [
> >
> https://github.com/reed-sandberg/ignite/commit/e6310e8d1481396f8cf3a5ede834989d0b277fc5
> > ]
> >
> >
> >
> > 2.4:
> >
> > [
> >
> https://github.com/reed-sandberg/ignite/commit/29ffe10e7be5ce3193b2fcb89c713c5269761c1c
> > ]
> >
> >
> >
> >
> > was (Author: rsandberg):
> > The following has fixed the problem in our production environment (stable
> > for 3 months now)
> >
> >
> >
> >
> https://github.com/reed-sandberg/ignite/commit/e6310e8d1481396f8cf3a5ede834989d0b277fc5
> >
> >> "Unexpected exception during cache update" via NullPointerException
> > thrown using TouchedExpiryPolicy
> >>
> >
> 
> >>
> >> Key: IGNITE-6815
> >> URL: https://issues.apache.org/jira/browse/IGNITE-6815
> >> Project: Ignite
> >>  Issue Type: Bug
> >>  Components: cache, streaming
> >>Affects Versions: 2.2, 2.3
> >> Environment: 4.10.0-33-generic #37~16.04.1-Ubuntu SMP Fri Aug 11
> > 14:07:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> >> Distributor ID:   LinuxMint
> >> Description:  Linux Mint 18.2 Sonya
> >> Release:  18.2
> >> Codename: sonya
> >>Reporter: Reed Sandberg
> >>Priority: Major
> >>
> >> This is triggered when I apply an expiry on the cache during an import
> > with StreamLoader, with no expiry on the cache, the import runs fine.
> >> Somehow the following line of code is hit with val == null:
> >>
> >
> org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:1253
> >> Stack trace (version 2.3.0 release package from maven public repo):
> >> {noformat}
> >> 16:04:25.259 ERROR o.a.i.i.p.c.d.d.a.GridDhtAtomicCache -
> >  Unexpected exception during cache update
> >> org.apache.ignite.IgniteException: Runtime failure on search row:
> > org.apache.ignite.internal.processors.cache.tree.SearchRow@68a4e885
> >>   at
> >
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1632)
> >>   at
> >
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1201)
> >>   at
> >
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:343)
> >>   at
> >
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1693)
> >>   at
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2419)
> >>   at
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1882)
> >>   at
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1735)
> >>   at
> >
> 

Re: Make TC issues seems to be hung up

[Dmitry Pavlov]

Hi Alexey, Dmitriy thank you.

It seems these 3 issues have a chance to be completed.

ср, 4 апр. 2018 г. в 15:29, Alexey Goncharuk :

> Replied in both tickets.
>
> 2018-04-04 11:52 GMT+03:00 Dmitriy Setrakyan :
>
> > Igniters,
> >
> > Dmitriy Pavlov is working very hard on making sure that we do not have
> > failing tests in Ignite. Let's help him in this effort. I would like to
> > encourage the committers responsible for the failing tests to either fix
> > them or remove them.
> >
> > Please respond here.
> >
> > D.
> >
> > On Tue, Apr 3, 2018 at 5:27 AM, Dmitry Pavlov 
> > wrote:
> >
> > > Hi Igniters,
> > >
> > > Following issues for tests fixing seems have no progress . Mainteiners,
> > > please address.
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-7766
> > > - Alexei Scherbakov - not responding, if contributor is not interested
> in
> > > this test anymore, probably we should remove it from code base?
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-7809
> > > - Ilya Lantukh, Alexey Goncharuk - not responding
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-7692
> > > - Alexey Goncharuk, Vladimir Ozerov - not responding
> > >
> > > Folks?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> >
>

[GitHub] ignite pull request #3577: IGNITE-7796: Adopt kNN classification example to ...

[zaleslaw]

Github user zaleslaw closed the pull request at:

https://github.com/apache/ignite/pull/3577


---

[GitHub] ignite pull request #3748: serialize only valuable part of GridLongList

[SharplEr]

GitHub user SharplEr opened a pull request:

https://github.com/apache/ignite/pull/3748

serialize only valuable part of GridLongList

For https://issues.apache.org/jira/browse/IGNITE-8054

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/SharplEr/ignite ignite-8054

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3748.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3748


commit 0f98ce3336aae2380826b4bbaa8c11aaf4fecd30
Author: Alexander Menshikov 
Date:   2018-04-04T15:09:20Z

serialize only valuable part of GridLongList




---

Re: IGNITE-6879

[Dmitry Pavlov]

Hi Igniters,

I am going to review these changes in 3-4 days. If everything is ok and if
there is no objections, I will merge it.

Hi Denis,

are you agree with proposed change?

Sincerely,
Dmitriy Pavlov

ср, 4 апр. 2018 г. в 14:26, Дмитрий Рябов :

> I agree that increasing complexity isn't good idea. Roman, can you document
> the migration guide?
>
> 2018-04-04 13:41 GMT+03:00 Alexey Kukushkin :
>
> > Roman, Dmitry,
> >
> > I also reviewed the fix and the code looks OK to me. But the fix has
> > significant implication - Ignite no longer can be used with spring-data
> 1.0
> > due to no backward compatibility between spring 2.0 and 1.0 APIs. With
> this
> > approach we must remember to add corresponding spring-data migration
> > instructions to the future ignite 2.5 migration guide.
> >
> > We could keep spring 1 support and backward compatibility by creating a
> new
> > module "ignite-spring-2-data" and keeping existing ignite-spring-data as
> > is. I do not like this option since to me increased complexity and
> > maintainability costs overweight the benefits of protecting
> > "Ignite-spring-1" users.
> >
> > I suggest you find a committer (see this list
> > ),
> communicate
> > the implication I mentioned above and say that two people already
> approved
> > the code providing we are OK with the chosen approach.
> >
>

[GitHub] ignite pull request #2796: IGNITE-5504: Fluky test fixed.

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2796


---

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

[jira] [Created] (IGNITE-8135) Missing SQL-DDL Authorization

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-8135:


 Summary: Missing SQL-DDL Authorization
 Key: IGNITE-8135
 URL: https://issues.apache.org/jira/browse/IGNITE-8135
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.5
Reporter: Alexey Kukushkin


Ignite has infrastructure to support 3-rd party security plugins. To support 
authorization, Ignite has security checks spread all over the code delegating 
actual authorization to a 3rd party security plugins if configured.

In addition to existing checks, Ignite 2.5 will authorise "create" and 
"destroy" cache operations.

The problem is authorization is not implemented for SQL at all - even if 
authorization is enabled, it is currently possible to run any SQL to 
create/drop/alter caches and read/modify/remove the cache data thus bypassing 
security. The problem exists for both DDL (create/drop/alter table) and DML 
(select/merge/insert/delete).

This ticket addresses DDL only: DML will be addressed by a different ticket.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3515: IGNITE-7640: make DiscoveryDataClusterState immut...

[SharplEr]

Github user SharplEr closed the pull request at:

https://github.com/apache/ignite/pull/3515


---

[jira] [Created] (IGNITE-8134) Services can't be deployed on servers outside of baseline topology

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-8134:
--

 Summary: Services can't be deployed on servers outside of baseline 
topology
 Key: IGNITE-8134
 URL: https://issues.apache.org/jira/browse/IGNITE-8134
 Project: Ignite
  Issue Type: Bug
  Components: managed services, persistence
Reporter: Stanislav Lukyanov
Assignee: Stanislav Lukyanov


If a node is not a part of the baseline topology, the services will never be 
deployed on it. In particular, if that node calls a synchronous deploy* method, 
the method will hang.
After the node is added to the baseline, all previously initiated deployments 
succeed (and deploy* methods return).

It seems that the issue is with the continuous query started by the 
GridServiceProcessor on the ignite-sys-cache.

Example:
=
public class BltServicesBug {
public static void main(String[] args) {
// start one node
IgniteConfiguration cfg1 = new IgniteConfiguration()
.setIgniteInstanceName("node1")
.setDataStorageConfiguration(
new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(
new DataRegionConfiguration()
.setPersistenceEnabled(true)
)
);
try (Ignite ignite1 = Ignition.start(cfg1)) {

// activate and set baseline topology
ignite1.cluster().active(true);

// start another node
IgniteConfiguration cfg2 = new IgniteConfiguration(cfg1)
.setIgniteInstanceName("node2");
try (Ignite ignite2 = Ignition.start(cfg2)) {
// try to deploy a service;
// this call hangs until the second node is added to the BLT 
(e.g. externally via control.sh)
ignite2.services().deployNodeSingleton("myService", new 
MyServiceImpl());

System.out.println("> Deployed");
}
}

}

private static class MyServiceImpl implements Service {
@Override public void cancel(ServiceContext ctx) { }
@Override public void init(ServiceContext ctx) { }
@Override public void execute(ServiceContext ctx) { }
}
}
=



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Service grid redesign

[Denis Mekhanikov]

Vyacheslav,

I've just posted my first draft of the IEP:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-17%3A+Service+grid+improvements
It's not finished yet, but you can get the idea from it.
If you have some thoughts on your mind, please let me know, I'll add them
to the IEP.

Denis

ср, 4 апр. 2018 г. в 13:09, Vyacheslav Daradur :

> Denis, thanks for the link.
>
> I looked through the task and I think that understand your redesign point
> now.
>
> Do you have a clear plan or IEP for the whole redesign?
>
> I'm interested in this component and I'd like to take part in the
> development.
>
>
>
> On Mon, Apr 2, 2018 at 2:55 PM, Denis Mekhanikov 
> wrote:
> > Vyacheslav,
> >
> > Service deployment design, based on replicated utility cache has proven
> to
> > be unstable and deadlock-prone.
> > You can find a list of JIRA issues, connected to it, in my previous
> letter.
> >
> > The intention behind it is similar to the binary metadata redesign, that
> > happened in the following ticket: IGNITE-4157
> > 
> > This change in service deployment procedure will eliminate need for
> another
> > internal replicated cache
> > and make service deployment more reliable on unstable topology.
> >
> > Denis
> >
> > вт, 27 мар. 2018 г. в 23:21, Vyacheslav Daradur :
> >
> >> Hi, Denis Mekhanikov!
> >>
> >> As far as I know, Ignite services are based on IgniteCache and we have
> >> all its features. We can use listeners or continuous queries for
> >> deployment synchronizations.
> >>
> >> Why do you want using the discovery layer for that?
> >>
> >> One more thing: we can use baseline approach for services, that means
> >> *IgniteService.deploy()* returns ready to work service after
> >> deployment on baseline nodes and deploy to other nodes on demand, for
> >> example when deployed service's loading will be hight.
> >>
> >> About versioning, maybe there is sense to extend public API:
> >> IgniteServices.service(name, *version*)?
> >>
> >> At first deployment, we can compute service's hashcode (just for an
> >> example) and store it, after new deployment request for services with
> >> an existing name we will compute new service's hashcode and compare
> >> them if they have different hashcodes that we will deploy new service
> >> as service with a different version.
> >>
> >>
> >> On Fri, Mar 23, 2018 at 10:03 PM, Denis Magda 
> wrote:
> >> > Denis,
> >> >
> >> > Thanks for the extensive analysis. There is a vast room for
> optimizations
> >> > on the service grid side.
> >> >
> >> > Yakov, Sam, Alex G.,
> >> >
> >> > How do you like the idea of the usage of discovery protocol for the
> >> service
> >> > grid system messages exchange? Any pitfalls?
> >> >
> >> >
> >> > --
> >> > Denis
> >> >
> >> >
> >> > On Fri, Mar 23, 2018 at 8:01 AM, Denis Mekhanikov <
> dmekhani...@gmail.com
> >> >
> >> > wrote:
> >> >
> >> >> Igniters,
> >> >>
> >> >> I'd like to start a discussion on Ignite service grid redesign.
> >> >> We have a number of problems in our current architecture, that have
> to
> >> be
> >> >> addressed.
> >> >>
> >> >> Here are the most severe ones:
> >> >>
> >> >> One of them is lack of guarantee, that service is successfully
> deployed
> >> and
> >> >> ready for work by the time, when *IgniteService.deploy*()* methods
> >> return.
> >> >> Furthermore, if an exception is thrown from *Service.init() *method,
> >> then
> >> >> the deploying side is not able to receive it, or even understand,
> that
> >> >> service is in unusable state.
> >> >> So, you may end up in such situation, when you deployed a service
> >> without
> >> >> receiving any errors, then called a service's method, and hung
> >> indefinitely
> >> >> on this invocation.
> >> >> JIRA ticket: https://issues.apache.org/jira/browse/IGNITE-3392
> >> >>
> >> >> Another problem is locking during service deployment on unstable
> >> topology.
> >> >> This issue is caused by missing updates in continuous query
> listeners on
> >> >> the internal cache.
> >> >> It is hard to reproduce, but it happens sometimes. We shouldn't allow
> >> such
> >> >> possibility, that deployment methods hang without saying anything.
> >> >> JIRA ticket: https://issues.apache.org/jira/browse/IGNITE-6259
> >> >>
> >> >> I think, we should change the deployment procedure to make it more
> >> >> reliable.
> >> >> Moving from operating over internal replicated service cache to
> sending
> >> >> custom discovery events seems to be a good idea.
> >> >> Service deployment may trigger a discovery event, that will make
> chosen
> >> >> nodes deploy the service, and the same event will notify other nodes
> >> about
> >> >> the deployed service instances.
> >> >> It will eliminate the need for distributed transactions on the
> internal
> >> >> replicated system cache, and make the service deployment protocol
> more
> >> >> transparent.
> >> >>
> >> >> 

[jira] [Created] (IGNITE-8133) Baseline topology documentation improvement

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-8133:
--

 Summary: Baseline topology documentation improvement
 Key: IGNITE-8133
 URL: https://issues.apache.org/jira/browse/IGNITE-8133
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Affects Versions: 2.4
Reporter: Stanislav Lukyanov
Assignee: Stanislav Lukyanov


Baseline topology concept was added to Ignite in 2.4 by IEP-4. This changed 
Ignite cluster behavior when persistence is enabled (first of all, activation 
and rebalancing timings).
It seems that the current documentation may be confusing.

For example, the sentence
{quote}Note that the baseline topology is not set when the cluster is started 
for the first time; that's the only time when a manual intervention is 
needed.{quote}
may lead one to thinking that baseline topology is not used by default and 
needs to be enabled only if one wants to use it.

Also, the documentation describes the tools and commands that are used to 
manage the baseline topology and activation, but doesn't give guidelines on 
which nodes should be in the topology, when should it be changed, etc.

The documentation should be enhanced to
- give clear understanding that baseline topology always needs to be considered 
as a part of the cluster architecture when persistence is enabled;
- provide overview of the behavioral changes compared to AI 2.3 (use a 
note/warning block for that to separate it from the main text?);
- provide basic guidelines and suggestions of how one can start a new cluster 
and manage it (when to activate/deactivate, when to change baseline topology, 
what happens and what needs to be done when a node fails or joins, how to use 
consistentId)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Make TC issues seems to be hung up

[Alexey Goncharuk]

Replied in both tickets.

2018-04-04 11:52 GMT+03:00 Dmitriy Setrakyan :

> Igniters,
>
> Dmitriy Pavlov is working very hard on making sure that we do not have
> failing tests in Ignite. Let's help him in this effort. I would like to
> encourage the committers responsible for the failing tests to either fix
> them or remove them.
>
> Please respond here.
>
> D.
>
> On Tue, Apr 3, 2018 at 5:27 AM, Dmitry Pavlov 
> wrote:
>
> > Hi Igniters,
> >
> > Following issues for tests fixing seems have no progress . Mainteiners,
> > please address.
> >
> > https://issues.apache.org/jira/browse/IGNITE-7766
> > - Alexei Scherbakov - not responding, if contributor is not interested in
> > this test anymore, probably we should remove it from code base?
> >
> > https://issues.apache.org/jira/browse/IGNITE-7809
> > - Ilya Lantukh, Alexey Goncharuk - not responding
> >
> > https://issues.apache.org/jira/browse/IGNITE-7692
> > - Alexey Goncharuk, Vladimir Ozerov - not responding
> >
> > Folks?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
>

Re: Memory usage per cache

[Alexey Goncharuk]

Denis,

I think this particular metric should be deprecated. The most we can do
about it is to return the actual allocated size when a cache is the only
cache in a group and return -1 if there are multiple caches in a group.
However, this does not look like a consistent approach to me, so I would
prefer to always return -1 and suggest that users use corresponding cache
group metrics.

--AG

2018-03-30 20:04 GMT+03:00 Denis Magda :

> Dmitriy G., Alexey,
>
> What happens with CacheMetrics.getOffHeapAllocatedSize metric? Don't see
> it
> mentioned in the tickets.
>
>- Will it return a value of a respective cache group if the cache is the
>only one in the group.
>- What will it return if there are several caches in a group?
>
> --
> Denis
>
> On Fri, Mar 30, 2018 at 8:16 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > Yes, I think we can maintain this metric inside lock ownership change
> > callbacks.
> >
> > 2018-03-30 17:34 GMT+03:00 Dmitriy Setrakyan :
> >
> > > I think "getLockedKeysCount" is better. Can we easily return this count
> > > without traversing all the transactions?
> > >
> > >
> > >
> > > On Fri, Mar 30, 2018 at 7:32 AM, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > > > Dmitriy,
> > > >
> > > > getLockedKeys returns only the number of locked keys, not the keys
> > > > themselves. Looks like the method name is confusing, should we rename
> > it
> > > to
> > > > getLockedKeysNumber?
> > > >
> > > > --AG
> > > >
> > > > 2018-03-30 16:24 GMT+03:00 Dmitriy Setrakyan  >:
> > > >
> > > > > Dmitriy,
> > > > >
> > > > > For transactions, are these separate metrics for each transaction
> or
> > > > > aggregates for all of them? If these are aggregates, then methods
> > like
> > > > > "getLockedKeys" may produce a very large collection, which on top
> of
> > > > > everything else, will be very difficult to create.
> > > > >
> > > > > D.
> > > > >
> > > > > On Fri, Mar 30, 2018 at 2:04 AM, Dmitriy Govorukhin <
> > > > > dmitriy.govoruk...@gmail.com> wrote:
> > > > >
> > > > > > Folks,
> > > > > >
> > > > > > I created 2 Jira issue for new metrics. Also, I think they will
> be
> > > > > useful.
> > > > > > Let's discuss in comments.
> > > > > >
> > > > > > - Add new metrics for data storage IGNITE-8078
> > > > > > 
> > > > > > - Implement new JMX metrics for transactions IGNITE-8077
> > > > > > 
> > > > > >
> > > > > > On Thu, Mar 29, 2018 at 8:26 PM, Denis Magda 
> > > > wrote:
> > > > > >
> > > > > > > Alexey,
> > > > > > >
> > > > > > > If to rephrase it differently, if a cache/table belongs to a
> > single
> > > > > cache
> > > > > > > group then its entries will never be mixed with the entries of
> > > > another
> > > > > > > caches/tables in both data and index pages. Please confirm that
> > my
> > > > > > > statement is correct. Also, does that counter accumulates size
> of
> > > > > > > BinaryObjects or the whole data/index pages?
> > > > > > >
> > > > > > > Finally, do you plan to rework CacheMetrics.
> > > getOffHeapAllocatedSize
> > > > > > method
> > > > > > > for this purpose? (btw, to my knowledge the method is broken at
> > the
> > > > > > moment
> > > > > > > and returns 0).
> > > > > > >
> > > > > > > --
> > > > > > > Denis
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Mar 29, 2018 at 1:20 AM, Alexey Goncharuk <
> > > > > > > alexey.goncha...@gmail.com> wrote:
> > > > > > >
> > > > > > > > Denis,
> > > > > > > >
> > > > > > > > Currently there is an easy way to add per-cache-group metrics
> > for
> > > > > data
> > > > > > > and
> > > > > > > > index pages. There is an internal counter, but it is not
> > > published
> > > > as
> > > > > > an
> > > > > > > > MBean metric, we will do this as a part of IEP-6.
> > > > > > > >
> > > > > > > > As for the per-cache metrics, this can be implemented, but it
> > > will
> > > > > > take a
> > > > > > > > significantly greater effort and most likely will affect
> > > > performance.
> > > > > > As
> > > > > > > > Andrey noted, when two caches share the same cache group,
> > > multiple
> > > > > > > entries
> > > > > > > > may be written to the same page, this needs special
> handling. I
> > > > > suggest
> > > > > > > we
> > > > > > > > first start with per-cache-group metrics and then, if there
> is
> > > high
> > > > > > > demand,
> > > > > > > > start thinking about per-cache metrics.
> > > > > > > >
> > > > > > > > --AG
> > > > > > > >
> > > > > > > > 2018-03-27 15:18 GMT+03:00 Andrey Kuznetsov <
> stku...@gmail.com
> > >:
> > > > > > > >
> > > > > > > > > I apologize for the previous message sent in hurry. It's
> > > > imposible
> > > > > to
> > > > > > > > > measure the difference between 'precise' and 'estimated'
> page
> > > > > memory
> > > > > > > > usage
> > > > > > > > > per cache unless we fully 

[GitHub] ignite pull request #3744: Gg 13379 dev

[kukushal]

Github user kukushal closed the pull request at:

https://github.com/apache/ignite/pull/3744


---

[GitHub] ignite pull request #3733: ignite-8112: updated build configuration (direct-...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3733


---

Re: IGNITE-6879

[Дмитрий Рябов]

I agree that increasing complexity isn't good idea. Roman, can you document
the migration guide?

2018-04-04 13:41 GMT+03:00 Alexey Kukushkin :

> Roman, Dmitry,
>
> I also reviewed the fix and the code looks OK to me. But the fix has
> significant implication - Ignite no longer can be used with spring-data 1.0
> due to no backward compatibility between spring 2.0 and 1.0 APIs. With this
> approach we must remember to add corresponding spring-data migration
> instructions to the future ignite 2.5 migration guide.
>
> We could keep spring 1 support and backward compatibility by creating a new
> module "ignite-spring-2-data" and keeping existing ignite-spring-data as
> is. I do not like this option since to me increased complexity and
> maintainability costs overweight the benefits of protecting
> "Ignite-spring-1" users.
>
> I suggest you find a committer (see this list
> ), communicate
> the implication I mentioned above and say that two people already approved
> the code providing we are OK with the chosen approach.
>

[GitHub] ignite pull request #3747: IGNITE-5978

[BiryukovVA]

GitHub user BiryukovVA opened a pull request:

https://github.com/apache/ignite/pull/3747

IGNITE-5978

Test fixed.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/BiryukovVA/ignite IGNITE-5978

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3747.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3747


commit 7ad83373fe097d97fdfc1d6abc1948d1f263d97a
Author: Vitaliy Biryukov 
Date:   2018-04-04T10:50:08Z

IGNITE-5978: Test fixed.




---

[GitHub] ignite pull request #3739: IGNITE-1776

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3739


---

[jira] [Created] (IGNITE-8132) A little re-design of Checkpointing section

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8132:
--

 Summary: A little re-design of Checkpointing section 
 Key: IGNITE-8132
 URL: https://issues.apache.org/jira/browse/IGNITE-8132
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Konstantinov
Assignee: Ilya Borisov
 Attachments: screenshot-1.png





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: IGNITE-6879

[Alexey Kukushkin]

Roman, Dmitry,

I also reviewed the fix and the code looks OK to me. But the fix has
significant implication - Ignite no longer can be used with spring-data 1.0
due to no backward compatibility between spring 2.0 and 1.0 APIs. With this
approach we must remember to add corresponding spring-data migration
instructions to the future ignite 2.5 migration guide.

We could keep spring 1 support and backward compatibility by creating a new
module "ignite-spring-2-data" and keeping existing ignite-spring-data as
is. I do not like this option since to me increased complexity and
maintainability costs overweight the benefits of protecting
"Ignite-spring-1" users.

I suggest you find a committer (see this list
), communicate
the implication I mentioned above and say that two people already approved
the code providing we are OK with the chosen approach.

Re: Service grid redesign

[Vyacheslav Daradur]

Denis, thanks for the link.

I looked through the task and I think that understand your redesign point now.

Do you have a clear plan or IEP for the whole redesign?

I'm interested in this component and I'd like to take part in the development.



On Mon, Apr 2, 2018 at 2:55 PM, Denis Mekhanikov  wrote:
> Vyacheslav,
>
> Service deployment design, based on replicated utility cache has proven to
> be unstable and deadlock-prone.
> You can find a list of JIRA issues, connected to it, in my previous letter.
>
> The intention behind it is similar to the binary metadata redesign, that
> happened in the following ticket: IGNITE-4157
> 
> This change in service deployment procedure will eliminate need for another
> internal replicated cache
> and make service deployment more reliable on unstable topology.
>
> Denis
>
> вт, 27 мар. 2018 г. в 23:21, Vyacheslav Daradur :
>
>> Hi, Denis Mekhanikov!
>>
>> As far as I know, Ignite services are based on IgniteCache and we have
>> all its features. We can use listeners or continuous queries for
>> deployment synchronizations.
>>
>> Why do you want using the discovery layer for that?
>>
>> One more thing: we can use baseline approach for services, that means
>> *IgniteService.deploy()* returns ready to work service after
>> deployment on baseline nodes and deploy to other nodes on demand, for
>> example when deployed service's loading will be hight.
>>
>> About versioning, maybe there is sense to extend public API:
>> IgniteServices.service(name, *version*)?
>>
>> At first deployment, we can compute service's hashcode (just for an
>> example) and store it, after new deployment request for services with
>> an existing name we will compute new service's hashcode and compare
>> them if they have different hashcodes that we will deploy new service
>> as service with a different version.
>>
>>
>> On Fri, Mar 23, 2018 at 10:03 PM, Denis Magda  wrote:
>> > Denis,
>> >
>> > Thanks for the extensive analysis. There is a vast room for optimizations
>> > on the service grid side.
>> >
>> > Yakov, Sam, Alex G.,
>> >
>> > How do you like the idea of the usage of discovery protocol for the
>> service
>> > grid system messages exchange? Any pitfalls?
>> >
>> >
>> > --
>> > Denis
>> >
>> >
>> > On Fri, Mar 23, 2018 at 8:01 AM, Denis Mekhanikov > >
>> > wrote:
>> >
>> >> Igniters,
>> >>
>> >> I'd like to start a discussion on Ignite service grid redesign.
>> >> We have a number of problems in our current architecture, that have to
>> be
>> >> addressed.
>> >>
>> >> Here are the most severe ones:
>> >>
>> >> One of them is lack of guarantee, that service is successfully deployed
>> and
>> >> ready for work by the time, when *IgniteService.deploy*()* methods
>> return.
>> >> Furthermore, if an exception is thrown from *Service.init() *method,
>> then
>> >> the deploying side is not able to receive it, or even understand, that
>> >> service is in unusable state.
>> >> So, you may end up in such situation, when you deployed a service
>> without
>> >> receiving any errors, then called a service's method, and hung
>> indefinitely
>> >> on this invocation.
>> >> JIRA ticket: https://issues.apache.org/jira/browse/IGNITE-3392
>> >>
>> >> Another problem is locking during service deployment on unstable
>> topology.
>> >> This issue is caused by missing updates in continuous query listeners on
>> >> the internal cache.
>> >> It is hard to reproduce, but it happens sometimes. We shouldn't allow
>> such
>> >> possibility, that deployment methods hang without saying anything.
>> >> JIRA ticket: https://issues.apache.org/jira/browse/IGNITE-6259
>> >>
>> >> I think, we should change the deployment procedure to make it more
>> >> reliable.
>> >> Moving from operating over internal replicated service cache to sending
>> >> custom discovery events seems to be a good idea.
>> >> Service deployment may trigger a discovery event, that will make chosen
>> >> nodes deploy the service, and the same event will notify other nodes
>> about
>> >> the deployed service instances.
>> >> It will eliminate the need for distributed transactions on the internal
>> >> replicated system cache, and make the service deployment protocol more
>> >> transparent.
>> >>
>> >> There are a few points, that should be taken into account though.
>> >>
>> >> First of all, we can't wait for services to be deployed and initialised
>> in
>> >> the discovery thread.
>> >> So, we need to make notification about service deployment result
>> >> asynchronous, presumably over communication protocol.
>> >> I can think of a procedure similar to the current exchange protocol,
>> when
>> >> service deployment is initialised with an initial discovery message,
>> >> followed by asynchronous notifications from the hosting servers over
>> >> communication. And finally, one more discovery message will notify all
>> >> 

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
>

[jira] [Created] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-8131:
---

 Summary: 
ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
 Key: IGNITE-8131
 URL: https://issues.apache.org/jira/browse/IGNITE-8131
 Project: Ignite
  Issue Type: Bug
  Components: zookeeper
Reporter: Sergey Chugunov


Two tests always fail on TC with the assertion

{noformat}
junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect 
event.
at 
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
at 
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
at 
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
at 
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
{noformat}

from client disconnect/reconnect events check. Obviously client doesn't 
generate these events as it supposed to do.

It is possible to reproduce test failure locally as well, but with low 
probability: one failure for 50 or even 300 successful executions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[GitHub] ignite pull request #3746: ZK troubleshooting

[Jokser]

GitHub user Jokser opened a pull request:

https://github.com/apache/ignite/pull/3746

ZK troubleshooting



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite 
ignite-zk-sch-troubleshooting

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3746.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3746


commit 11e2567fffa724e6b4af6021cda1bfbcf775370b
Author: sboikov 
Date:   2017-11-16T13:10:04Z

zk

commit 98a171c68a1f5610e5f5830144306ee73df866d6
Author: sboikov 
Date:   2017-11-16T14:42:05Z

zk

commit b389f38cbc59f41dc1c95854684059f15b225b8c
Author: sboikov 
Date:   2017-11-17T06:33:30Z

zk

commit 5793ffbe23a095127cc88c1962785cad7cf2432d
Author: sboikov 
Date:   2017-11-17T09:05:55Z

zk

commit 45e7e40603fa2b496b94f00fc287221d30073c98
Author: sboikov 
Date:   2017-11-20T08:14:36Z

zk

commit a4be5afd03fef3b3fa8ce8c017d24636859c82f3
Author: sboikov 
Date:   2017-11-20T10:27:23Z

zk

commit 97e85179418bc369066c26ec086edd138419c406
Author: sboikov 
Date:   2017-11-20T14:21:33Z

zk

commit fcee8c846274890f8eee8cc8f3644cdda912dedd
Author: sboikov 
Date:   2017-11-21T09:24:58Z

zk

commit fb6bd0ac39f97db0d7e347aff6fa26edda10f940
Author: sboikov 
Date:   2017-11-21T10:43:15Z

zk

commit 1f82a5311d099ad31c22deec391ad91d568f9705
Author: sboikov 
Date:   2017-11-21T12:09:27Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-zk

commit 18527db9ba5d13b0964ec9c87c8b155295921c9a
Author: sboikov 
Date:   2017-11-21T13:54:38Z

zk

commit 7ba0feb55d79794146ea4deb41be2560eec9e42d
Author: sboikov 
Date:   2017-11-21T15:36:29Z

zk

commit 4090eb717f25331c2967645a802714830ac0d4f7
Author: sboikov 
Date:   2017-11-21T15:37:35Z

Merge remote-tracking branch 'origin/ignite-zk' into ignite-zk

commit e0aba812643c0d773359a95b514daead9730ee6e
Author: sboikov 
Date:   2017-11-22T08:47:55Z

zk

commit a6b452823422290e19238238e119f5aaad87b6af
Author: sboikov 
Date:   2017-11-22T10:22:14Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-zk

commit 6cb8c06f73ace3030f47ccfe21e2f46d6b054e5f
Author: sboikov 
Date:   2017-11-22T10:28:51Z

zk

commit 9761a0294e3978120c471dc7bdaa5ad94bbaf1b3
Author: sboikov 
Date:   2017-11-22T10:41:16Z

zk

commit bc297aa4b47cae1e5cb87e5d7863900c82fa90ce
Author: sboikov 
Date:   2017-11-22T10:48:27Z

zk

commit 4749d332c7ec1b6d24f8a8d0f6d5abf50de5d71d
Author: sboikov 
Date:   2017-11-22T11:27:47Z

zk

commit f5f2060aa6978367d4bf160fd96dc4efa57a7a8c
Author: sboikov 
Date:   2017-11-22T13:13:18Z

zk

commit 93dd7ab79c6ed38c29a87ca7a676fbfcefd57273
Author: sboikov 
Date:   2017-11-22T13:22:17Z

zk

commit 8bd1e077aae4cbdd61e3c5ba1dfa1e1f0e18759c
Author: sboikov 
Date:   2017-11-22T13:22:36Z

Merge remote-tracking branch 'origin/ignite-zk' into ignite-zk

commit 42bbed0adda149acb098fddfc830bcea768697d7
Author: sboikov 
Date:   2017-11-22T14:08:56Z

zk

commit d9575aac6137a3d842cac3ba15dab591138c67e2
Author: sboikov 
Date:   2017-11-22T14:53:18Z

zk

commit 97486480276c0563fcebddb56c53130519456b35
Author: sboikov 
Date:   2017-11-23T08:12:52Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-zk

commit 5d8feab45346352aacf1285948c2c9c5125bbabf
Author: sboikov 
Date:   2017-11-23T08:24:26Z

zk

commit 9ffd603d217034247497b6c2734933872c8a78ed
Author: sboikov 
Date:   2017-11-23T09:04:42Z

zk

commit 7611371b94559e3934b1224a17aaf408c735b358
Author: sboikov 
Date:   2017-11-23T10:52:06Z

zk

commit aa78f5c43639526c1f914ca7e3b2d455e012a358
Author: sboikov 
Date:   2017-11-23T10:52:06Z

zk

commit adebbf0753b19d6ca9c831da1d84f57567797d61
Author: sboikov 
Date:   2017-11-23T11:40:41Z

Merge remote-tracking branch 'origin/ignite-zk' into ignite-zk




---

[jira] [Created] (IGNITE-8130) WalModeChangeCoordinatorNotAffinityNodeSelfTest#testLocalCache fails sporadically in master

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8130:


 Summary: 
WalModeChangeCoordinatorNotAffinityNodeSelfTest#testLocalCache fails 
sporadically in master
 Key: IGNITE-8130
 URL: https://issues.apache.org/jira/browse/IGNITE-8130
 Project: Ignite
  Issue Type: Test
Reporter: Alexey Goncharuk


The reason for random failures is a loop in finally block of forAllNodes() 
which destroys caches. This leads to a race when cache destroy request is 
asynchronously sent to other nodes and the cache created in test is destroyed 
by the finally block.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3745: IGNITE-8122 Restore partition in state OWNING

[Jokser]

GitHub user Jokser opened a pull request:

https://github.com/apache/ignite/pull/3745

IGNITE-8122 Restore partition in state OWNING



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8122

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3745.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3745


commit 604ee719b304d0b4cf4caabaa6fa16b5a980e04e
Author: Pavel Kovalenko 
Date:   2018-04-04T09:33:10Z

IGNITE-8122 Restore partition state to OWNING if unable to read from page 
memory.




---

Re: abbrevation rules plugin

[Andrey Gura]

Both prefixes "Grid" and "Ignite" in class names are redundant for most
cases. So there is no any rules for this.

вт, 3 апр. 2018 г., 19:28 Vyacheslav Daradur :

> Hi, Igniters!
>
> I got into the task [1] in agreement with Dmitry.
>
> I’ve prepared the PR [2] with following changes:
> - added Apache 2.0 license to the header of each file
> - replaced prefix ‘Grid’ by ‘Ignite’ in class names
> - added README.md with a simple description
> - changed version 2.6.3 -> 3.0.0 because the project has own GitHub
> releases tab and completely new versioning isn't preferable IMO
>
> Also, I’ve built new artifact and tested it, it works well.
>
> Am I understood the task correct?
> If not, please share your notes I will fix them shortly.
>
> As far as I understand someone of GridGain employee should confirm the
> plugin's code's donation. It’d be great to confirm that by corporate
> email.
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-5698
> [2] https://github.com/dspavlov/ignite-abbrev-plugin/pull/1
>
>
> On Thu, Jul 6, 2017 at 12:30 PM, Dmitry Pavlov 
> wrote:
> > Hi Dmitriy, Denis,
> >
> > Thank you for your effort to find out solution.
> > It sound good for me, I have assigned IGNITE-5698 to myself.
> >
> > Best Regards,
> > Dmitriy Pavlov
> >
> >
> > чт, 6 июл. 2017 г. в 2:45, Denis Magda :
> >
> >> Dmitriy P.,
> >>
> >> Does it sound good to you? If yes, please make sure the plugin is
> >> available via a public GitHub repo and refer to it from the doc.
> >>
> >> —
> >> Denis
> >>
> >> > On Jul 5, 2017, at 4:43 PM, Dmitriy Setrakyan 
> >> wrote:
> >> >
> >> > On Wed, Jul 5, 2017 at 4:41 PM, Denis Magda 
> wrote:
> >> >
> >> >> Ok, what if we make sure the plugin is available on GitHub (not
> Ignite)
> >> >> and give a link to it on the documentation page? This seems to be the
> >> >> easiest way to handle the topic.
> >> >
> >> >
> >> > I think this will work.
> >>
> >>
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Make TC issues seems to be hung up

[Dmitriy Setrakyan]

Igniters,

Dmitriy Pavlov is working very hard on making sure that we do not have
failing tests in Ignite. Let's help him in this effort. I would like to
encourage the committers responsible for the failing tests to either fix
them or remove them.

Please respond here.

D.

On Tue, Apr 3, 2018 at 5:27 AM, Dmitry Pavlov  wrote:

> Hi Igniters,
>
> Following issues for tests fixing seems have no progress . Mainteiners,
> please address.
>
> https://issues.apache.org/jira/browse/IGNITE-7766
> - Alexei Scherbakov - not responding, if contributor is not interested in
> this test anymore, probably we should remove it from code base?
>
> https://issues.apache.org/jira/browse/IGNITE-7809
> - Ilya Lantukh, Alexey Goncharuk - not responding
>
> https://issues.apache.org/jira/browse/IGNITE-7692
> - Alexey Goncharuk, Vladimir Ozerov - not responding
>
> Folks?
>
> Sincerely,
> Dmitriy Pavlov
>

Re: IGNITE-6879

[Дмитрий Рябов]

Hi!
No, it wasn't a joke)

2018-04-04 11:22 GMT+03:00 Роман Меерсон :

> Hi all!
> I suppose Dmity`s message wasn`t april 1st joke)
> So what about my PR? Would it be merged?
>
> вс, 1 апр. 2018 г. в 12:40, Дмитрий Рябов :
>
>> Dmitry, Alexey, code and tests looks good for me.
>>
>> JIRA: https://issues.apache.org/jira/browse/IGNITE-6879
>> PR: https://github.com/apache/ignite/pull/3704
>> Upsource: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-541
>> TeamCity: https://ci.ignite.apache.org/viewLog.html?buildId=1170373=
>> buildResultsDiv=IgniteTests24Java8_RunAll
>>
>> 2018-03-22 21:48 GMT+03:00 Роман Меерсон :
>>
>>> Hi all!
>>>
>>> Dmitriy thank you for review.
>>>
>>> I`ve just fixed all your comments.
>>>
>>> чт, 22 мар. 2018 г. в 20:36, Dmitry Pavlov :
>>>
 HI Dmitriy, thank you!

 Roman, could you please address Dmitriy's comments?

 чт, 22 мар. 2018 г. в 19:18, Дмитрий Рябов :

> Hi Dmitriy,
>
> I took a look for PR, it needs codestyle fixes.
>
> 2018-03-19 14:22 GMT+03:00 Dmitry Pavlov :
>
>> Hi Alexey,
>>
>> Did you find the patch is looking good and is ready to be merged?
>>
>> Sincerely,
>> Dmitriy Pavlov
>>
>> чт, 15 мар. 2018 г. в 11:19, Alexey Kukushkin <
>> kukushkinale...@gmail.com>:
>>
>> > Just found the fix is ready - I will review it today or tomorrow.
>> >
>>
>
>
>>

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: IGNITE-6879

[Роман Меерсон]

Hi all!
I suppose Dmity`s message wasn`t april 1st joke)
So what about my PR? Would it be merged?

вс, 1 апр. 2018 г. в 12:40, Дмитрий Рябов :

> Dmitry, Alexey, code and tests looks good for me.
>
> JIRA: https://issues.apache.org/jira/browse/IGNITE-6879
> PR: https://github.com/apache/ignite/pull/3704
> Upsource: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-541
> TeamCity:
> https://ci.ignite.apache.org/viewLog.html?buildId=1170373=buildResultsDiv=IgniteTests24Java8_RunAll
>
> 2018-03-22 21:48 GMT+03:00 Роман Меерсон :
>
>> Hi all!
>>
>> Dmitriy thank you for review.
>>
>> I`ve just fixed all your comments.
>>
>> чт, 22 мар. 2018 г. в 20:36, Dmitry Pavlov :
>>
>>> HI Dmitriy, thank you!
>>>
>>> Roman, could you please address Dmitriy's comments?
>>>
>>> чт, 22 мар. 2018 г. в 19:18, Дмитрий Рябов :
>>>
 Hi Dmitriy,

 I took a look for PR, it needs codestyle fixes.

 2018-03-19 14:22 GMT+03:00 Dmitry Pavlov :

> Hi Alexey,
>
> Did you find the patch is looking good and is ready to be merged?
>
> Sincerely,
> Dmitriy Pavlov
>
> чт, 15 мар. 2018 г. в 11:19, Alexey Kukushkin <
> kukushkinale...@gmail.com>:
>
> > Just found the fix is ready - I will review it today or tomorrow.
> >
>


>

[jira] [Created] (IGNITE-8129) JDBC: JdbcThinConnectionSSLTest.testDefaultContext

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-8129:


 Summary: JDBC: JdbcThinConnectionSSLTest.testDefaultContext
 Key: IGNITE-8129
 URL: https://issues.apache.org/jira/browse/IGNITE-8129
 Project: Ignite
  Issue Type: Bug
Reporter: Peter Ivanov
Assignee: Taras Ledkov


Test fails under strange conditions: it runs successful if is executed by {{mvn 
test}} command and fails if is executed by {{mvn surefire:test}}. Seems some 
maven reactor dependencies and/or race condition problems.
{code}
[2018-04-04 05:52:26,389][ERROR][main][root] Test failed.
java.sql.SQLException: Failed to SSL connect to server 
[url=jdbc:ignite:thin://127.0.0.1:10800]
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinSSLUtil.createSSLSocket(JdbcThinSSLUtil.java:93)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinTcpIo.connect(JdbcThinTcpIo.java:214)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinTcpIo.start(JdbcThinTcpIo.java:156)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinTcpIo.start(JdbcThinTcpIo.java:131)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.ensureConnected(JdbcThinConnection.java:156)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.(JdbcThinConnection.java:145)
at 
org.apache.ignite.IgniteJdbcThinDriver.connect(IgniteJdbcThinDriver.java:157)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:270)
at 
org.apache.ignite.jdbc.thin.JdbcThinConnectionSSLTest.testDefaultContext(JdbcThinConnectionSSLTest.java:187)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection 
during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:992)
at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinSSLUtil.createSSLSocket(JdbcThinSSLUtil.java:88)
... 18 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(InputRecord.java:505)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
... 22 more
[08:54:52][org.apache.ignite.jdbc.thin.JdbcThinConnectionSSLTest.testDefaultContext]
 java.sql.SQLException: Failed to SSL connect to server 
[url=jdbc:ignite:thin://127.0.0.1:10800]
[08:54:52]
[org.apache.ignite.jdbc.thin.JdbcThinConnectionSSLTest.testDefaultContext] 
java.sql.SQLException: Failed to SSL connect to server 
[url=jdbc:ignite:thin://127.0.0.1:10800]
at 
org.apache.ignite.jdbc.thin.JdbcThinConnectionSSLTest.testDefaultContext(JdbcThinConnectionSSLTest.java:187)
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection 
during handshake
at 
org.apache.ignite.jdbc.thin.JdbcThinConnectionSSLTest.testDefaultContext(JdbcThinConnectionSSLTest.java:187)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at 
org.apache.ignite.jdbc.thin.JdbcThinConnectionSSLTest.testDefaultContext(JdbcThinConnectionSSLTest.java:187)
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)