Re: Workaround for possible NPE in Selector.open()

[Ivan Pavlukhin]

Igniters,

Please review PR for the subject
https://issues.apache.org/jira/browse/IGNITE-12787

Best regards,
Ivan Pavlukhin

пн, 16 мар. 2020 г. в 00:38, Ivan Pavlukhin :
>
> Folks,
>
> I created a ticket [1] and raised PR. TC is in progress.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12787
>
> Best regards,
> Ivan Pavlukhin
>
> вт, 10 мар. 2020 г. в 16:56, Ilya Kasnacheev :
> >
> > Hello!
> >
> > Feel free to file a ticket, contribute a fix.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > вт, 10 мар. 2020 г. в 16:38, Seliverstov Igor :
> >
> > > Hi Igniters,
> > >
> > > Today I noticed quite old code aimed to workaround an old bug in 1.5 JDK
> > > revision which was fixed in rev 1.7
> > >
> > > org/apache/ignite/internal/util/nio/GridNioServer.java:161
> > >
> > > Since we widely use lambdas now (so Ignite requires at least Java 1.8) do
> > > we really need it now?
> > >
> > > I would like to remove it.
> > >
> > > Regards,
> > > Igor

Re: [DISCUSSION] Changes in Ignite release process related to documentation

[Denis Magda]

Hi Pavel,

We're thinking about the same in regards to the future of Ignite
documentation :) Artem and I had some kitchen talks recently and we'll
restart that activity. Ignite definitely deserves and requires next-gen
docs. Artem promised to share his thoughts soon.

Btw, check out How to write effective documentation for your open-source
projec t article that I
found in one of my newsletters today. It feels like it can be used as a
reference by Igniters on some best practices.

Denis Magda


On Tue, Mar 17, 2020 at 1:03 PM Pavel Tupitsyn  wrote:

> I agree with Andrey.
>
> And I'd like to reopen the discussion on "moving docs from readme.io to
> git" [1] [2]
> Looks like we reached some agreement there but never moved on with the
> migration.
>
>
> [1]
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html
> [2] https://issues.apache.org/jira/browse/IGNITE-7595
>
> On Tue, Mar 17, 2020 at 9:48 PM Denis Magda  wrote:
>
> > Andrey,
> >
> > Thanks for sharing your thoughts. Your second point made me recall
> several
> > occasions when only after a release of some public APIs we had a chance
> to
> > complete documentation and discovered the APIs' ineffectiveness and
> oddness
> > from the user usage perspective. But it was already late.
> >
> > Generally, if to move incrementally with documentation process changes,
> > "documentation readiness before the vote" should work as the first step
> for
> > us. There will be delays with the vote for sure because we have to get
> used
> > to this change, but over time we should get to the point when
> documentation
> > will be prepared upon overall task resolution. Andrey, Artem, do you
> agree
> > with that?
> >
> > Other community members, please share your thoughts. If we don't hear any
> > opposite opinions, then I would update our release procedures with this
> > change.
> >
> > -
> > Denis
> >
> >
> > On Mon, Mar 16, 2020 at 9:44 AM Andrey Gura  wrote:
> >
> > > Denis,
> > >
> > > I agree with you.
> > >
> > > Also I think that we should move to process which will require
> > > documentation updates during work on issue/feature and will part of
> > > code review process. Such approach has some useful benefits:
> > >
> > > - Documentation readiness at the same time when fix/implementation is
> > > ready (remember, documentation is part of a product).
> > > - Work on documentation and review could discover incompleteness of a
> > > fix or a feature on earlier stage (It is usual situation when some
> > > aspects were just forgotten, but documentation writing could spotlight
> > > such things).
> > >
> > > On Thu, Mar 12, 2020 at 7:49 PM Denis Magda  wrote:
> > > >
> > > > Igniters,
> > > >
> > > > With the final 2.8 release steps checked out today by announcing the
> > > > version globally (congrats!), it's a proper time to consider and
> tweak
> > > our
> > > > release process, making completion of some phases more predictable
> and
> > > > aligned. I would like to dedicate this thread solely to changes
> related
> > > to
> > > > the documentation.
> > > >
> > > > If to do a recap, Ignite 2.8 announcement went out of sync with the
> > > > publication of binaries, Maven and other artifacts because our
> > technical
> > > > documentation was completed long after the vote had been closed.
> > > >
> > > > We can easily eliminate such glitches for future releases if agree to
> > > start
> > > > a vote only if Ignite docs are ready and can be published the same
> day
> > > with
> > > > other release artifacts. If the docs are completed and available
> > > > internally while the vote goes then we can work on a release blog
> post
> > > > (referring to docs details) and announce the release the same day
> when
> > > the
> > > > binaries/docs availability.
> > > >
> > > > Thoughts? Let's change the process ensuring that the vote can be
> > started
> > > > only if technical documentation is ready to be released?
> > > >
> > > > -
> > > > Denis
> > >
> >
>

Re: [DISCUSSION] Further development ignitevisorcmd

[Denis Magda]

Hi Nikolay,

I think that your proposal is reasonable. Agree, that all exceptions need
to be signaled properly - either with an ERROR message or by failing an
operation initiated by Visor CMD (you can return some error code and the
tool needs to process it properly). It's up to you and other Visor
maintainers to decide what's the best way to handle such exceptions.

-
Denis


On Tue, Mar 17, 2020 at 12:13 AM Nikolai Kulagin 
wrote:

> Hello, Igniters!
>
> I would like to raise a question on the work of the ignitevisorcmd.
> Currently, part of the exceptions in the ignitevisorcmd is not thrown and
> displayed on the console as WARNING. Example:
> VisorOpenCommand#open(String).
>
> The result of this is:
> 1. Complicated perception of an exception by the user. It seems to me that
> if a fat client throws an exception, the ignitevisorcmd should show this as
> an exception (or ERROR).
> 2. Most tests in the ignitevisorcmd do not have a final verification of the
> conditions. For example, the VisorKillCommandSpec test is successful,
> although the ignitevisorcmd cannot even connect to the cluster. The test
> falls only in case of an exception, but some of the exceptions are not
> thrown and are displayed as WARNING. Paradox.
>
> And it seems to me that there are two ways to solve the problem:
> 1. We throw exceptions. In this case, some of the tests begin to work;
>or
> 2. We continue to display exceptions like WARNING (or ERROR). Then we need
> to do the following:
> - Correct the tests so that they check the fulfillment of the conditions;
> - It might be worth displaying exceptions as an ERROR.
>
> A good example is IGNITE-12757. All tests pass successfully, although the
> ignitevisorcmd on default configs does not even connect to the cluster.
>
> WDYT?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12757
>

Re: [DISCUSSION] Changes in Ignite release process related to documentation

[Pavel Tupitsyn]

I agree with Andrey.

And I'd like to reopen the discussion on "moving docs from readme.io to
git" [1] [2]
Looks like we reached some agreement there but never moved on with the
migration.


[1]
http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html
[2] https://issues.apache.org/jira/browse/IGNITE-7595

On Tue, Mar 17, 2020 at 9:48 PM Denis Magda  wrote:

> Andrey,
>
> Thanks for sharing your thoughts. Your second point made me recall several
> occasions when only after a release of some public APIs we had a chance to
> complete documentation and discovered the APIs' ineffectiveness and oddness
> from the user usage perspective. But it was already late.
>
> Generally, if to move incrementally with documentation process changes,
> "documentation readiness before the vote" should work as the first step for
> us. There will be delays with the vote for sure because we have to get used
> to this change, but over time we should get to the point when documentation
> will be prepared upon overall task resolution. Andrey, Artem, do you agree
> with that?
>
> Other community members, please share your thoughts. If we don't hear any
> opposite opinions, then I would update our release procedures with this
> change.
>
> -
> Denis
>
>
> On Mon, Mar 16, 2020 at 9:44 AM Andrey Gura  wrote:
>
> > Denis,
> >
> > I agree with you.
> >
> > Also I think that we should move to process which will require
> > documentation updates during work on issue/feature and will part of
> > code review process. Such approach has some useful benefits:
> >
> > - Documentation readiness at the same time when fix/implementation is
> > ready (remember, documentation is part of a product).
> > - Work on documentation and review could discover incompleteness of a
> > fix or a feature on earlier stage (It is usual situation when some
> > aspects were just forgotten, but documentation writing could spotlight
> > such things).
> >
> > On Thu, Mar 12, 2020 at 7:49 PM Denis Magda  wrote:
> > >
> > > Igniters,
> > >
> > > With the final 2.8 release steps checked out today by announcing the
> > > version globally (congrats!), it's a proper time to consider and tweak
> > our
> > > release process, making completion of some phases more predictable and
> > > aligned. I would like to dedicate this thread solely to changes related
> > to
> > > the documentation.
> > >
> > > If to do a recap, Ignite 2.8 announcement went out of sync with the
> > > publication of binaries, Maven and other artifacts because our
> technical
> > > documentation was completed long after the vote had been closed.
> > >
> > > We can easily eliminate such glitches for future releases if agree to
> > start
> > > a vote only if Ignite docs are ready and can be published the same day
> > with
> > > other release artifacts. If the docs are completed and available
> > > internally while the vote goes then we can work on a release blog post
> > > (referring to docs details) and announce the release the same day when
> > the
> > > binaries/docs availability.
> > >
> > > Thoughts? Let's change the process ensuring that the vote can be
> started
> > > only if technical documentation is ready to be released?
> > >
> > > -
> > > Denis
> >
>

Re: [DISCUSSION] Changes in Ignite release process related to documentation

[Denis Magda]

Andrey,

Thanks for sharing your thoughts. Your second point made me recall several
occasions when only after a release of some public APIs we had a chance to
complete documentation and discovered the APIs' ineffectiveness and oddness
from the user usage perspective. But it was already late.

Generally, if to move incrementally with documentation process changes,
"documentation readiness before the vote" should work as the first step for
us. There will be delays with the vote for sure because we have to get used
to this change, but over time we should get to the point when documentation
will be prepared upon overall task resolution. Andrey, Artem, do you agree
with that?

Other community members, please share your thoughts. If we don't hear any
opposite opinions, then I would update our release procedures with this
change.

-
Denis


On Mon, Mar 16, 2020 at 9:44 AM Andrey Gura  wrote:

> Denis,
>
> I agree with you.
>
> Also I think that we should move to process which will require
> documentation updates during work on issue/feature and will part of
> code review process. Such approach has some useful benefits:
>
> - Documentation readiness at the same time when fix/implementation is
> ready (remember, documentation is part of a product).
> - Work on documentation and review could discover incompleteness of a
> fix or a feature on earlier stage (It is usual situation when some
> aspects were just forgotten, but documentation writing could spotlight
> such things).
>
> On Thu, Mar 12, 2020 at 7:49 PM Denis Magda  wrote:
> >
> > Igniters,
> >
> > With the final 2.8 release steps checked out today by announcing the
> > version globally (congrats!), it's a proper time to consider and tweak
> our
> > release process, making completion of some phases more predictable and
> > aligned. I would like to dedicate this thread solely to changes related
> to
> > the documentation.
> >
> > If to do a recap, Ignite 2.8 announcement went out of sync with the
> > publication of binaries, Maven and other artifacts because our technical
> > documentation was completed long after the vote had been closed.
> >
> > We can easily eliminate such glitches for future releases if agree to
> start
> > a vote only if Ignite docs are ready and can be published the same day
> with
> > other release artifacts. If the docs are completed and available
> > internally while the vote goes then we can work on a release blog post
> > (referring to docs details) and announce the release the same day when
> the
> > binaries/docs availability.
> >
> > Thoughts? Let's change the process ensuring that the vote can be started
> > only if technical documentation is ready to be released?
> >
> > -
> > Denis
>

[jira] [Created] (IGNITE-12797) Add command line option to CommandHandler to be able to see full stack trace and cause exception in log in case of error.

[Kirill Tkalenko (Jira)]

Kirill Tkalenko created IGNITE-12797:


 Summary: Add command line option to CommandHandler to be able to 
see full stack trace and cause exception in log in case of error.
 Key: IGNITE-12797
 URL: https://issues.apache.org/jira/browse/IGNITE-12797
 Project: Ignite
  Issue Type: Improvement
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko


In case of error control.sh can print common error message without any 
information about root cause of error. Printing full stack trace and cause can 
ease the analysis. User should be able to turn it on when launching control.sh 
with specific option.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Reference of local service.

[Vladimir Steshin]

Andrey,

>>> Is it possible to return actual class instance instead of interface 
from serviceProxy() method?


No, it is not possible. IgniteServiceImpl doesn't allow that:

public  T serviceProxy(final String name, final Class 
svcItf, final boolean sticky, final long timeout) {

    ...
    A.ensure(svcItf.isInterface(), "Service class must be an interface: 
" + svcItf);


    ...

}


17.03.2020 17:34, Andrey Gura пишет:

Vladimir,


Why not using IgniteServices.serviceProxy() for that? Since it requires an 
interface, It could return proxy for local service too and
keep backward compatibility at the same time.

Is it possible to return actual class instance instead of interface
from serviceProxy() method? E.g. could I get ServiceImpl as result of
method call instead of ServiceItf?

On Tue, Mar 17, 2020 at 9:50 AM Vladimir Steshin  wrote:

Andrey,


IgniteServices.service() method could return actual interface implementation 
instead of interface itself.


IgniteServices.service() always return actual local service instance, no proxy, 
might be without any interface but except Service.


If yes then we can add new method IgniteService.serviceLocalProxy().
It will not break backward compatibility and will always return proxy.

Why not using IgniteServices.serviceProxy() for that? Since it requires an 
interface, It could return proxy for local service too and
keep backward compatibility at the same time.

16.03.2020 20:21, Andrey Gura пишет:

Vladimir,


We won’t affect existing services

How exactly will we affect services without special interface? Please see
the benchmarks in previous email.

I talk about backward compatibility, not about performance. But it
doesn't matter because... see below.

My fault. From discussion I realized that services doesn't require
interface. But indeed it does require.

If I understand correctly, IgniteServices.service() method could
return actual interface implementation instead of interface itself.
Am I right?

If yes then we can add new method IgniteService.serviceLocalProxy().
It will not break backward compatibility and will always return proxy.

On Thu, Mar 12, 2020 at 2:25 PM Vladimir Steshin  wrote:

Andrey, hi.


We won’t affect existing services

How exactly will we affect services without special interface? Please see
the benchmarks in previous email.



what if we generate will generate proxy that collects service’s metrics

only if service will implement some special interface?


I don’t like idea enabling/disabling metrics involves code change,
compilation. I believe it should be an external option, probably available
at runtime through JMX.



we can impose additional requirement for services that want use metrics

out of box. … service must have own interface and only invocations of
methods of this interface will be taken into account for metrics collection.

Why one more interface? To work via proxy, with remote services user
already has to use an interface additionally to Service. If we introduce
proxy for local services too (as suggested earlier), an interface will be
required. Current IgniteService#serviceProxy() already requires interface
even for local service. I don’t think we need one more special interface.



user always can use own metrics framework.

Since we do not significantly affect services user can use both or disable
our by an option.


With the discussion before and the benchmark I propose:


- Let IgniteService#serviceProxy() give GridServiceProxy for local services
too. It already requires to work via interface. So it’s safe for user code.


- Deprecate IgniteService#service()


- Make service metrics enabled by default for all services.


- Bring system param which disables metrics by default for all services.


- Bring parameter/method in MetricsMxBean which allows disabling/enabling
metrics for all services at run time.

Makes sense?

чт, 5 мар. 2020 г., 16:48 Andrey Gura :


Hi there,

what if we will generate proxy that collects service's metrics only if
service will implement some special interface? In such case:

- we won't affect existing services at all.
- we can impose additional requirement for services that want use
metrics out of box (i.e. service that implements our special interface
*must* also have own interface and only invocations of methods of this
interface will be taken into account for metrics collection).
- user always can use own metrics framework instead of our (just do
not implement this new special interface).

About metrics enabling/disabling. At present IGNITE-11927 doesn't
solve this problem. Just because there is no metrics implementation
for services :)
Anyway we should provide a way for configuring service metrics (in
sense of enabled/disabled) during service deploy. It's easy for cases
where deploy() methods have ServiceConfiguration as parameter. But
there are "short cut" methods like deployXxxSingleton(). I have ideas
how to solve this problem. For example we can introduce "short cut"
factory 

[jira] [Created] (IGNITE-12796) pendingTree of the persisted cache data store must be marked as destroyed

[Maxim Muzafarov (Jira)]

Maxim Muzafarov created IGNITE-12796:


 Summary: pendingTree of the persisted cache data store must be 
marked as destroyed
 Key: IGNITE-12796
 URL: https://issues.apache.org/jira/browse/IGNITE-12796
 Project: Ignite
  Issue Type: Task
Reporter: Maxim Muzafarov


{{pendingTree}} of the persisted cache data store ({{GridCacheDataStore}} may 
fail to find rows during concurrent cache stop operation or {{purgeExpired}} 
with simultaneously partition eviction occurred (e.g. moved to another node on 
a new node joins).

Probably we should mark {{pendingTree}} as destroyed 
{{BPlusTree#markDestroyed}} the same way as it happens for 
{{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#dataTree}}.

Investigation and reproducer required. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Reference of local service.

[Andrey Gura]

Vladimir,

> Why not using IgniteServices.serviceProxy() for that? Since it requires an 
> interface, It could return proxy for local service too and
> keep backward compatibility at the same time.

Is it possible to return actual class instance instead of interface
from serviceProxy() method? E.g. could I get ServiceImpl as result of
method call instead of ServiceItf?

On Tue, Mar 17, 2020 at 9:50 AM Vladimir Steshin  wrote:
>
> Andrey,
>
> >>> IgniteServices.service() method could return actual interface 
> >>> implementation instead of interface itself.
>
>
> IgniteServices.service() always return actual local service instance, no 
> proxy, might be without any interface but except Service.
>
> >>> If yes then we can add new method IgniteService.serviceLocalProxy().
> >>> It will not break backward compatibility and will always return proxy.
>
> Why not using IgniteServices.serviceProxy() for that? Since it requires an 
> interface, It could return proxy for local service too and
> keep backward compatibility at the same time.
>
> 16.03.2020 20:21, Andrey Gura пишет:
> > Vladimir,
> >
> >>> We won’t affect existing services
> >> How exactly will we affect services without special interface? Please see
> >> the benchmarks in previous email.
> > I talk about backward compatibility, not about performance. But it
> > doesn't matter because... see below.
> >
> > My fault. From discussion I realized that services doesn't require
> > interface. But indeed it does require.
> >
> > If I understand correctly, IgniteServices.service() method could
> > return actual interface implementation instead of interface itself.
> > Am I right?
> >
> > If yes then we can add new method IgniteService.serviceLocalProxy().
> > It will not break backward compatibility and will always return proxy.
> >
> > On Thu, Mar 12, 2020 at 2:25 PM Vladimir Steshin  wrote:
> >> Andrey, hi.
> >>
>  We won’t affect existing services
> >> How exactly will we affect services without special interface? Please see
> >> the benchmarks in previous email.
> >>
> >>
> > what if we generate will generate proxy that collects service’s metrics
> >> only if service will implement some special interface?
> >>
> >>
> >> I don’t like idea enabling/disabling metrics involves code change,
> >> compilation. I believe it should be an external option, probably available
> >> at runtime through JMX.
> >>
> >>
>  we can impose additional requirement for services that want use metrics
> >> out of box. … service must have own interface and only invocations of
> >> methods of this interface will be taken into account for metrics 
> >> collection.
> >>
> >> Why one more interface? To work via proxy, with remote services user
> >> already has to use an interface additionally to Service. If we introduce
> >> proxy for local services too (as suggested earlier), an interface will be
> >> required. Current IgniteService#serviceProxy() already requires interface
> >> even for local service. I don’t think we need one more special interface.
> >>
> >>
>  user always can use own metrics framework.
> >>
> >> Since we do not significantly affect services user can use both or disable
> >> our by an option.
> >>
> >>
> >> With the discussion before and the benchmark I propose:
> >>
> >>
> >> - Let IgniteService#serviceProxy() give GridServiceProxy for local services
> >> too. It already requires to work via interface. So it’s safe for user code.
> >>
> >>
> >> - Deprecate IgniteService#service()
> >>
> >>
> >> - Make service metrics enabled by default for all services.
> >>
> >>
> >> - Bring system param which disables metrics by default for all services.
> >>
> >>
> >> - Bring parameter/method in MetricsMxBean which allows disabling/enabling
> >> metrics for all services at run time.
> >>
> >> Makes sense?
> >>
> >> чт, 5 мар. 2020 г., 16:48 Andrey Gura :
> >>
> >>> Hi there,
> >>>
> >>> what if we will generate proxy that collects service's metrics only if
> >>> service will implement some special interface? In such case:
> >>>
> >>> - we won't affect existing services at all.
> >>> - we can impose additional requirement for services that want use
> >>> metrics out of box (i.e. service that implements our special interface
> >>> *must* also have own interface and only invocations of methods of this
> >>> interface will be taken into account for metrics collection).
> >>> - user always can use own metrics framework instead of our (just do
> >>> not implement this new special interface).
> >>>
> >>> About metrics enabling/disabling. At present IGNITE-11927 doesn't
> >>> solve this problem. Just because there is no metrics implementation
> >>> for services :)
> >>> Anyway we should provide a way for configuring service metrics (in
> >>> sense of enabled/disabled) during service deploy. It's easy for cases
> >>> where deploy() methods have ServiceConfiguration as parameter. But
> >>> there are "short cut" methods like deployXxxSingleton(). I have ideas
> >>> how to 

[jira] [Created] (IGNITE-12795) Partially revert changes to atomic caches introduced in IGNITE-11797

[Alexey Scherbakov (Jira)]

Alexey Scherbakov created IGNITE-12795:
--

 Summary: Partially revert changes to atomic caches introduced in 
IGNITE-11797
 Key: IGNITE-12795
 URL: https://issues.apache.org/jira/browse/IGNITE-12795
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.8
Reporter: Alexey Scherbakov
Assignee: Alexey Scherbakov
 Fix For: 2.8.1


These changes can trigger node failure during update on backup:
Better fix for atomics is needed.

{noformat}
class org.apache.ignite.IgniteCheckedException: Failed to update the counter 
[newVal=173, curState=Counter [lwm=172, holes={173=Item [start=173, delta=1]}, 
maxApplied=174, hwm=173]]
at 
org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.update(PartitionUpdateCounterTrackingImpl.java:152)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateCounter(IgniteCacheOffheapManagerImpl.java:1578)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:2198)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.nextUpdateCounter(GridDhtLocalPartition.java:995)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.nextPartitionCounter(GridDhtCacheEntry.java:104)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6434)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:6190)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:5881)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3995)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$5700(BPlusTree.java:3889)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:2020)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1904)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1656)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1639)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:2450)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:436)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2311)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processDhtAtomicUpdateRequest(GridDhtAtomicCache.java:3362)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:139)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:311)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:306)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1637)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1257)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:144)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1146)
at 
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:50)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
at 

[jira] [Created] (IGNITE-12794) Scan query fails with an assertion error: Unexpected row key

[Denis Mekhanikov (Jira)]

Denis Mekhanikov created IGNITE-12794:
-

 Summary: Scan query fails with an assertion error: Unexpected row 
key
 Key: IGNITE-12794
 URL: https://issues.apache.org/jira/browse/IGNITE-12794
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov
 Attachments: ScanQueryExample.java

Scan query fails with an exception:
{noformat}
Exception in thread "main" java.lang.AssertionError: Unexpected row key
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:548)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:512)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3045)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:127)
at scan.ScanQueryExample.main(ScanQueryExample.java:31)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)"
{noformat}
The issue is reproduced when performing concurrent scan queries and updates. A 
reproducer is attached. You will need to enable asserts in order to reproduce 
this issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Data vanished from cluster after INACTIVE/ACTIVE switch

[Vladimir Steshin]

Nikolay, I think we should reconsider clearing at least system caches 
when deactivating.


17.03.2020 14:18, Nikolay Izhikov пишет:

Hello, Vladimir.

I don’t get it.

What is your proposal?
What we should do?


17 марта 2020 г., в 14:11, Vladimir Steshin  написал(а):

Nikolay, hi.


And should be covered with the  —force parameter we added.

As fix for user cases - yes. My idea is to emphasize overall ability to lose 
various objects, not only data. Probably might be reconsidered in future.


17.03.2020 13:49, Nikolay Izhikov пишет:

Hello, Vladimir.

If there is at lease one persistent data region then system data region also 
becomes persistent.
Your example applies only to pure in-memory clusters.

And should be covered with the —force parameter we added.

What do you think?


17 марта 2020 г., в 13:45, Vladimir Steshin  написал(а):

 Hi, all.

Fixes for control.sh and the REST have been merged. Could anyone take a look to 
the previous email with an issue? Isn't this conductvery wierd?

Re: Data vanished from cluster after INACTIVE/ACTIVE switch

[Nikolay Izhikov]

Hello, Vladimir.

I don’t get it.

What is your proposal?
What we should do?

> 17 марта 2020 г., в 14:11, Vladimir Steshin  написал(а):
> 
> Nikolay, hi.
> 
 And should be covered with the  —force parameter we added.
> 
> As fix for user cases - yes. My idea is to emphasize overall ability to lose 
> various objects, not only data. Probably might be reconsidered in future.
> 
> 
> 17.03.2020 13:49, Nikolay Izhikov пишет:
>> Hello, Vladimir.
>> 
>> If there is at lease one persistent data region then system data region also 
>> becomes persistent.
>> Your example applies only to pure in-memory clusters.
>> 
>> And should be covered with the —force parameter we added.
>> 
>> What do you think?
>> 
>>> 17 марта 2020 г., в 13:45, Vladimir Steshin  написал(а):
>>> 
>>> Hi, all.
>>> 
>>> Fixes for control.sh and the REST have been merged. Could anyone take a 
>>> look to the previous email with an issue? Isn't this conductvery wierd?
>>> 

Re: Data vanished from cluster after INACTIVE/ACTIVE switch

[Vladimir Steshin]

Nikolay, hi.


And should be covered with the  —force parameter we added.


As fix for user cases - yes. My idea is to emphasize overall ability to 
lose various objects, not only data. Probably might be reconsidered in 
future.



17.03.2020 13:49, Nikolay Izhikov пишет:

Hello, Vladimir.

If there is at lease one persistent data region then system data region also 
becomes persistent.
Your example applies only to pure in-memory clusters.

And should be covered with the —force parameter we added.

What do you think?


17 марта 2020 г., в 13:45, Vladimir Steshin  написал(а):

 Hi, all.

Fixes for control.sh and the REST have been merged. Could anyone take a look to 
the previous email with an issue? Isn't this conductvery wierd?

Re: Data vanished from cluster after INACTIVE/ACTIVE switch

[Nikolay Izhikov]

Hello, Vladimir.

If there is at lease one persistent data region then system data region also 
becomes persistent.
Your example applies only to pure in-memory clusters.

And should be covered with the —force parameter we added.

What do you think?

> 17 марта 2020 г., в 13:45, Vladimir Steshin  написал(а):
> 
> Hi, all.
> 
> Fixes for control.sh and the REST have been merged. Could anyone take a look 
> to the previous email with an issue? Isn't this conductvery wierd?
> 

Re: Data vanished from cluster after INACTIVE/ACTIVE switch

[Vladimir Steshin]

    Hi, all.

Fixes for control.sh and the REST have been merged. Could anyone take a 
look to the previous email with an issue? Isn't this conductvery wierd?

RE: deadlock in system pool on meta update

[Sergey-A Kosarev]

Classification: Public

Hi Sergey,
Ticket is here https://issues.apache.org/jira/browse/IGNITE-12793

I will try to make reproducer in the coming days.

Kind regards,
Sergey Kosarev

-Original Message-
From: Sergey Chugunov [mailto:sergey.chugu...@gmail.com]
Sent: 17 March 2020 09:45
To: dev 
Subject: Re: deadlock in system pool on meta update

Hello Sergey,

Your analysis looks valid to me, we definitely need to investigate this 
deadlock and find out how to fix it.

Could you create a ticket and write a test that reproduces the issue with 
sufficient probability?

Thanks!

On Mon, Mar 16, 2020 at 8:22 PM Sergey-A Kosarev 
wrote:

> Classification: Public
>
> Hi,
> I've recently tried to apply Ilya's idea (
> https://issues.apache.org/jira/browse/IGNITE-12663) of minimizing
> thread pools and tried to set system pool to 3 in my own tests.
> It caused deadlock on a client node and I think it can happen not only
> on such small pool values.
>
> Details are following:
> I'm not using persistence currently (if it matters).
> On the client note I use ignite compute to  call   a job on every server
> node (there are 3 server nodes in the tests).
>
> Then I've found in logs:
>
> [10:55:21] : [Step 1/1] [2020-03-13 10:55:21,773] {
> grid-timeout-worker-#8} [WARN] [o.a.i.i.IgniteKernal] - Possible
> thread pool starvation detected (no task completed in last 3ms, is
> system thread pool size large enough?)
> [10:55:21] : [Step 1/1] ^-- System thread pool [active=3, idle=0,
> qSize=9]
>
>
> I see in threaddumps that all 3 system pool workers do the same -
> processing of job responses:
>
> "sys-#26" #605 daemon prio=5 os_prio=0 tid=0x64a0a800
> nid=0x1f34 waiting on condition [0x7b91d000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:749)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:250)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1169)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:285)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:184)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:306)
> at
> 

[jira] [Created] (IGNITE-12793) Deadlock in the System Pool on Metadata processing

[Sergey Kosarev (Jira)]

Sergey Kosarev created IGNITE-12793:
---

 Summary: Deadlock in the System Pool on Metadata processing
 Key: IGNITE-12793
 URL: https://issues.apache.org/jira/browse/IGNITE-12793
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7.6
Reporter: Sergey Kosarev






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12792) Calcite integration. Update Calcite version to 1.22.0

[Igor Seliverstov (Jira)]

Igor Seliverstov created IGNITE-12792:
-

 Summary: Calcite integration. Update Calcite version to 1.22.0
 Key: IGNITE-12792
 URL: https://issues.apache.org/jira/browse/IGNITE-12792
 Project: Ignite
  Issue Type: Improvement
Reporter: Igor Seliverstov
Assignee: Igor Seliverstov






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[DISCUSSION] Further development ignitevisorcmd

[Nikolai Kulagin]

Hello, Igniters!

I would like to raise a question on the work of the ignitevisorcmd.
Currently, part of the exceptions in the ignitevisorcmd is not thrown and
displayed on the console as WARNING. Example:
VisorOpenCommand#open(String).

The result of this is:
1. Complicated perception of an exception by the user. It seems to me that
if a fat client throws an exception, the ignitevisorcmd should show this as
an exception (or ERROR).
2. Most tests in the ignitevisorcmd do not have a final verification of the
conditions. For example, the VisorKillCommandSpec test is successful,
although the ignitevisorcmd cannot even connect to the cluster. The test
falls only in case of an exception, but some of the exceptions are not
thrown and are displayed as WARNING. Paradox.

And it seems to me that there are two ways to solve the problem:
1. We throw exceptions. In this case, some of the tests begin to work;
   or
2. We continue to display exceptions like WARNING (or ERROR). Then we need
to do the following:
- Correct the tests so that they check the fulfillment of the conditions;
- It might be worth displaying exceptions as an ERROR.

A good example is IGNITE-12757. All tests pass successfully, although the
ignitevisorcmd on default configs does not even connect to the cluster.

WDYT?

[1] https://issues.apache.org/jira/browse/IGNITE-12757

Re: Reference of local service.

[Vladimir Steshin]

Andrey,


IgniteServices.service() method could return actual interface implementation 
instead of interface itself.



IgniteServices.service() always return actual local service instance, no proxy, 
might be without any interface but except Service.


If yes then we can add new method IgniteService.serviceLocalProxy().
It will not break backward compatibility and will always return proxy.


Why not using IgniteServices.serviceProxy() for that? Since it requires an 
interface, It could return proxy for local service too and
keep backward compatibility at the same time.

16.03.2020 20:21, Andrey Gura пишет:

Vladimir,


We won’t affect existing services

How exactly will we affect services without special interface? Please see
the benchmarks in previous email.

I talk about backward compatibility, not about performance. But it
doesn't matter because... see below.

My fault. From discussion I realized that services doesn't require
interface. But indeed it does require.

If I understand correctly, IgniteServices.service() method could
return actual interface implementation instead of interface itself.
Am I right?

If yes then we can add new method IgniteService.serviceLocalProxy().
It will not break backward compatibility and will always return proxy.

On Thu, Mar 12, 2020 at 2:25 PM Vladimir Steshin  wrote:

Andrey, hi.


We won’t affect existing services

How exactly will we affect services without special interface? Please see
the benchmarks in previous email.



what if we generate will generate proxy that collects service’s metrics

only if service will implement some special interface?


I don’t like idea enabling/disabling metrics involves code change,
compilation. I believe it should be an external option, probably available
at runtime through JMX.



we can impose additional requirement for services that want use metrics

out of box. … service must have own interface and only invocations of
methods of this interface will be taken into account for metrics collection.

Why one more interface? To work via proxy, with remote services user
already has to use an interface additionally to Service. If we introduce
proxy for local services too (as suggested earlier), an interface will be
required. Current IgniteService#serviceProxy() already requires interface
even for local service. I don’t think we need one more special interface.



user always can use own metrics framework.


Since we do not significantly affect services user can use both or disable
our by an option.


With the discussion before and the benchmark I propose:


- Let IgniteService#serviceProxy() give GridServiceProxy for local services
too. It already requires to work via interface. So it’s safe for user code.


- Deprecate IgniteService#service()


- Make service metrics enabled by default for all services.


- Bring system param which disables metrics by default for all services.


- Bring parameter/method in MetricsMxBean which allows disabling/enabling
metrics for all services at run time.

Makes sense?

чт, 5 мар. 2020 г., 16:48 Andrey Gura :


Hi there,

what if we will generate proxy that collects service's metrics only if
service will implement some special interface? In such case:

- we won't affect existing services at all.
- we can impose additional requirement for services that want use
metrics out of box (i.e. service that implements our special interface
*must* also have own interface and only invocations of methods of this
interface will be taken into account for metrics collection).
- user always can use own metrics framework instead of our (just do
not implement this new special interface).

About metrics enabling/disabling. At present IGNITE-11927 doesn't
solve this problem. Just because there is no metrics implementation
for services :)
Anyway we should provide a way for configuring service metrics (in
sense of enabled/disabled) during service deploy. It's easy for cases
where deploy() methods have ServiceConfiguration as parameter. But
there are "short cut" methods like deployXxxSingleton(). I have ideas
how to solve this problem. For example we can introduce "short cut"
factory methods like nodeSingletonConfiguration(String name, Service
service) and clusterSingletonConfiguration(String name, Service
service). This methods will return configuration which has parameters
for given type of deployment and could be modified, e.g. metrics could
be enabled.

WDYT?

On Wed, Mar 4, 2020 at 8:42 PM Vladimir Steshin 
wrote:

Vyacheslav, Denis, hi again.




I agree with the proposal to introduce a new method which returns

proxy

include the case of locally deployed services.



I see one is restricted to use an interface for service with
IgniteServiceProcessor#serviceProxy(…):



A.ensure(svcItf.isInterface(), "Service class must be an interface: " +
svcItf);



What if we change IgniteService#serviceProxy(...) so that it will return
proxy everytime? That looks safe for user code. Doing so we might only
deprecate 

Re: deadlock in system pool on meta update

[Sergey Chugunov]

Hello Sergey,

Your analysis looks valid to me, we definitely need to investigate this
deadlock and find out how to fix it.

Could you create a ticket and write a test that reproduces the issue with
sufficient probability?

Thanks!

On Mon, Mar 16, 2020 at 8:22 PM Sergey-A Kosarev 
wrote:

> Classification: Public
>
> Hi,
> I've recently tried to apply Ilya's idea (
> https://issues.apache.org/jira/browse/IGNITE-12663) of minimizing thread
> pools and tried to set system pool to 3 in my own tests.
> It caused deadlock on a client node and I think it can happen not only on
> such small pool values.
>
> Details are following:
> I'm not using persistence currently (if it matters).
> On the client note I use ignite compute to  call   a job on every server
> node (there are 3 server nodes in the tests).
>
> Then I've found in logs:
>
> [10:55:21] : [Step 1/1] [2020-03-13 10:55:21,773] {
> grid-timeout-worker-#8} [WARN] [o.a.i.i.IgniteKernal] - Possible thread
> pool starvation detected (no task completed in last 3ms, is system
> thread pool size large enough?)
> [10:55:21] : [Step 1/1] ^-- System thread pool [active=3, idle=0,
> qSize=9]
>
>
> I see in threaddumps that all 3 system pool workers do the same -
> processing of job responses:
>
> "sys-#26" #605 daemon prio=5 os_prio=0 tid=0x64a0a800 nid=0x1f34
> waiting on condition [0x7b91d000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:749)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:250)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1169)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:285)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:184)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:306)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10493)
> at
>