Hi Evgenii, did you have a chance to look at the latest logs?
On Thu, 25 Jun 2020 at 11:32, John Smith wrote:
> Ok
>
> stdout.copy.zip
>
> https://www.dropbox.com/sh/ejcddp2gcml8qz2/AAD_VfUecE0hSNZX7wGbfDh3a?dl=0
>
> On Thu, 25 Jun 2020 at 11:01, John Smith wrote:
>
>> Because in between it's
Hello!
There is now a ticket about this issue, which I indeed can see:
https://issues.apache.org/jira/browse/IGNITE-13212
While it is not fixed, you will have to make sure that filter code is
deployed to all nodes.
Regards,
--
Ilya Kasnacheev
пт, 3 июл. 2020 г. в 15:50, Rafael Troilo :
>
Has anyone ever deployed ignite2.7.6 on kubernetes based on coredns? According
to my analysis, it is a bug.I found that there is access to DNS through podname
in the packet capture, but the code has not been located. This will cause DNS
parsing failure and cause timeout. Is there anyone who
Sorry I messed up the ScanQueryWithTransform.java a little bit.
This is the clean version.
Thank you.
On 7/3/20 2:19 PM, Rafael Troilo wrote:
> Hi Ilya, hey Denis,
>
> thank you both of you for taking a look into this problem.
>
> How would you like get the reproducing stand-alone runnable?
>
Hi Ilya, hey Denis,
thank you both of you for taking a look into this problem.
How would you like get the reproducing stand-alone runnable?
I attached a single file which reproduces the problem.
Do you like to have it in any other way?
Some comments:
In this issue, it does not matter if the
It’s like a traditional database in this sense: everything that’s in memory is
on disk; not everything on disk is guaranteed to be in memory. If you have less
than 41Mb of data, everything will be stored both in memory and on disk. If you
have more than 41Mb, all will be on disk, some will be
Hello,
I found in log file if i set DataRegion for PersistenceEnabled=true
There are
off-heap
-- DataRegion_Name region [used=41MB, free=50.95%, comm=15MB]
and
Ignite Persistence
-- DataRegion_Name region [used=41MB]
Is it stored equally in disk and off-heap area(41MB)?
and If i
Thanks - the issue I have now is how can I confirm that the local listen has
returned before executing my code?
e.g. in the local listen I can set a flag, and then the local listen returns
- but the thread that detects this flag and runs the task could still be
scheduled to run before the local
Hello!
Yes, you need to return from event listener as soon as you can.
Regards,
--
Ilya Kasnacheev
пт, 3 июл. 2020 г. в 12:03, ssansoy :
> Hi Ilya, thanks for the quick help!
> Within the local listen, I am adding a task to an executor - so the cache
> operations happen in a different
Hi Ilya, thanks for the quick help!
Within the local listen, I am adding a task to an executor - so the cache
operations happen in a different thread. However, is the key thing here that
the local listen handler metho needs to have returned?
E.g. the local listen may not have fully completed by
Hello!
Do you issue your cache operations from event listener thread? This might
be unsafe and also not return the expected results. Event listeners are
invoked from internal threads.
Consider issuing a task to public pool from event listener, and then
returning. I would expect that task will
Thank you so much!
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi Ignite users,
I have 3 nodes running, with a cache with the following configuration:
cacheConfiguration.setCacheMode(CacheMode.PARTITIONED);
cacheConfiguration.setBackups(1);
cacheConfiguration.setRebalanceMode(CacheRebalanceMode.SYNC);
13 matches
Mail list logo
