Hello,
I have recently encountered this "long-running cache future" message while
doing stress tests on Ignite (we run it embedded inside an application
server). I put CPU pressure on two out of four nodes using stress-ng, that
rendered the two nodes irresponsive for the duration of the test, and
Would it be correct to extrapolate this statement and say that Ignite
should be started as a standalone application as opposed to being embedded
inside an application server that has its own lifecycle and additional
responsibilities?
On Thu, Jun 13, 2019 at 7:48 AM Stephen Darlington <
stephen.d
Hello,
I am using Ignite 2.7 embedded inside a Tomcat application, and have run
into an issue where the application does not shut down due to a blocked
Ignite thread. I think it would be good for Ignite to avoid hanging in this
situation, what do you think? Here are the details:
1. Ignite node ge
That sounds very useful for a "what not to do example", could you please
give a little more detail (big lines) on how the business code could starve
the Ignite thread pool? And if using entry processors, how come the
operations were not executed atomically - i.e. what made the race condition
possib
Yes, thank you, I guess I missed setting the IGNITE_QUIET to false when I
tried it out.
As far as performance overhead, do you have any pointers? Of course, every
environment is different, but I am hoping setting the 'metricsLogFrequency'
to something like once every 5 minutes would not be too bad
Hello,
I would like to see some periodic basic topology health statistics in the
logs, such as CPU, heap/off heap usage etc. What would be a preferred way
to configure that in a production like environment, without a significant
performance overhead?
Thank you,
Loredana Radulescu Ivanoff
Hello,
Would you happen to have any news about the 2.7.5 release date?
Thank you,
Loredana
Hello,
I am very interested in this topic as well so I've been following up. So,
if I understand correctly, there is no other way to access the needed API's
without these flags, and the following (extract from Java documentation) is
an accepted risk?
"*The --add-exports and --add-opens options mu
Windows. Falling back to TLSv1.2 could help, but,
>>>
>>> 2) on Windows SSL fails to work on Java 11 due to mistake in Ignite's
>>> NIO code. I also has created the ticket and currently devising a patch:
>>> https://issues.apache.org/jira/browse/IGNITE-11299
r options are limited on Windows - use older Java or move to
> Linux.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 8 февр. 2019 г. в 02:31, Loredana Radulescu Ivanoff <
> lradu...@tibco.com>:
>
>> Hello,
>>
>> I would like to restart this topic
guration, but with the sslContextFactory bean commented out.
Any help on the issue would be greatly appreciated. Thank you!
On Thu, Oct 18, 2018 at 2:56 PM Loredana Radulescu Ivanoff <
lradu...@tibco.com> wrote:
> Hello,
>
> I can consistently reproduce this issue with Ignite 2.6.
Hello,
Following this bug fix - https://issues.apache.org/jira/browse/IGNITE-7824,
I think the documentation needs to be updated too, right? It still mentions
20% RAM, and it should be 80%.
This is the documentation I'm referring to:
https://apacheignite.readme.io/docs/memory-configuration
As an Ignite user, here are my two cents:
- if you were never able to get the node to join the cluster, check that
there are no firewalls/rules blocking the Ignite ports (telnet might be a
quick way to do that)
- check that the IPs printed by TcpDiscoverySpi are the correct ones; if
you have virtu
I can run it in 2.6 by adding these to the JVM
arguments: --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED
--add-exports=java.base/sun.nio.ch=ALL-UNNAMED
I haven't had a chance to try with 2.7 yet, I would have expected it to
work without these, though. Is this going to be addressed in 2.8, m
Hello,
We've been witnessing a similar set of logs from Apache Ignite after
upgrading to 2.7 (from 2.6) in a couple of different environments, one of
which had only one Ignite node. Very frequently, ignite will log the
message "Blocked system-critical thread has been detected. This can lead to
clu
Hello,
The current plan is that Oracle will stop updates for Java 8 commercial
users after January 2019, and Java 11 is the next LTS release, so is there
a plan to have Ignite working with Java 11 by then?
Thank you.
On Thu, Nov 22, 2018 at 10:49 PM Petr Ivanov wrote:
> Hi!
>
>
> Full Java 9+
n Mon, Oct 22, 2018 at 12:31 AM Ilya Kasnacheev
wrote:
> Hello!
>
> I would suggest regular (or DEBUG) Ignite logs + SSL debug logs.
>
>
> https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html
>
> Regards,
> --
> Ilya Kasnacheev
>
&g
is moment. However, I was
> able to run SSL test (TcpDiscoverySslTrustedUntrustedTest) and it turned
> out mostly fine.
>
> More info is needed from your side, such as full instances logs.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 19 окт. 2018 г. в 0:56, Loredana
Hello,
I can consistently reproduce this issue with Ignite 2.6.0, JDK 11 and SSL
enabled:
- the second node that I bring up joins, and then shortly after freezes
and prints this message every minute:
"WARN ...[*Initialization*]
processors.cache.GridCachePartitionExchangeManager: Still wai
19 matches
Mail list logo