Re: Possible starvation in striped pool. message

[ezhuravlev]

peerClassLoading used only for compute, for example for sharing job classes
between nodes, it's not working for objects that put into cache. If you want
to work without this classes on nodes, take a look to BinaryObjects:
https://apacheignite.readme.io/v2.0/docs/binary-marshaller

Evgenii



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Possible starvation in striped pool. message

[kestas]

I did try your suggestion. My code:
 some = ignite.compute().affinityCall(CACHE_NAME,1, () ->
cacheBinary.get(1).field("some"));
And i get ClassNotFoundException for the object class which is put into
cache. peerClassLoadingEnabled is set to true.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Possible-starvation-in-striped-pool-message-tp15993p16482.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Possible starvation in striped pool. message

[Yakov Zhdanov]

Well, we need to take a closer look then. This may be affected by
transaction protocol. Viacheslav Koptilin, can you please create a test and
see what time goes to?

kestas, you can switch to Ignite.compute().affinityCall("key", () ->
{return cacheBinary.get("key").field("f"));}); This should work fine for
both transactional and atomic caches.

Thanks!
--
Yakov Zhdanov, Director R&D
*GridGain Systems*
www.gridgain.com

2017-08-09 16:30 GMT+03:00 kestas :

> I did some testing on #invoke vs #get performance. It works as expected on
> ATOMIC cache, however on TRANSACTIONAL cache #invoke has even lower
> performance than pure #get. Is this to be expected?
>
> simplified code:
> some = cacheBinary.invoke(1,(mutableEntry, objects) ->
> mutableEntry.getValue().field("some"));
> and
> some = cache.get(1).getSome();
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Possible-starvation-in-striped-pool-
> message-tp15993p16081.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Possible starvation in striped pool. message

[kestas]

I did some testing on #invoke vs #get performance. It works as expected on
ATOMIC cache, however on TRANSACTIONAL cache #invoke has even lower
performance than pure #get. Is this to be expected?

simplified code:
some = cacheBinary.invoke(1,(mutableEntry, objects) ->
mutableEntry.getValue().field("some"));
and
some = cache.get(1).getSome();



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Possible-starvation-in-striped-pool-message-tp15993p16081.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Possible starvation in striped pool. message

[Yakov Zhdanov]

Hi!

Ignite prints stacktrace of an internal thread if it detects that thread
runs the same task (single get response in your case) for a long time,
which is 30 seconds by default.

Of course, getting large objects from remote nodes is expensive. Can you
please estimate the value size?

Possible ways of speeding up the application:
1. Refactor object model to reduce values size
2. use org.apache.ignite.IgniteCache#withKeepBinary - this will return
IgniteCache that will not deserialize binary objects, therefore there will
be no deserialization. Take a look at this page for info -
https://apacheignite.readme.io/docs/binary-marshaller
3. use org.apache.ignite.IgniteCache#invoke(K,
org.apache.ignite.cache.CacheEntryProcessor, java.lang.Object...)
instead of pure get() providing the processor that will not be altering the
value, but return only some part of the object (e.g. tuple of last name and
city instead of returning the entire User object).
4. confiure NearCache - https://apacheignite.readme.io/docs/near-caches and
set copy on read
(org.apache.ignite.configuration.CacheConfiguration#isCopyOnRead) to false
- however, bringing large objects to client may overload the client and
introduce new problems.

I would first try 1-3. Please let us know the results.

--Yakov

Re: Possible starvation in striped pool. message

[kestas]

Yes, this seems to appear when we start working with large objects. Is there
a way to solve this? Does it affect cache put/get operations performance
directly ?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Possible-starvation-in-striped-pool-message-tp15993p16025.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Possible starvation in striped pool. message

[slava.koptilin]

Hi Kestas,

There are several possible reasons for that.
In your case, I think you are trying to put or get huge objects, that
contain internal collections and so on.

>at
> o.a.i.i.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2016) 
>at
> o.a.i.i.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1904) 
...
>at
> o.a.i.i.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2016) 
>at
> o.a.i.i.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1904) 

Another possible reason is intensive use of getAll()/putAll() methods from
different threads.
In that case, you need to sort collection of keys before, because batch
operation on the same entries in different order could lead to deadlock.


Thanks.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Possible-starvation-in-striped-pool-message-tp15993p16002.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.