The documentation describes the use case where a node is stopped and removed
from the baseline, which reduces the number of backups/replicas when the
node is stopped.
I assume that there is no current code to support removing the node from the
baseline first, so that at least desired number of bac
In our case we're only using the receiver as you describe, to update the key
that it was invoked for. Our actual use case is that the incoming stream of
data sometimes sends us old data, which we want to discard rather than
cache. So the StreamReceiver examines the value already in the cache and
ei
Thanks! Wasn't aware of these!
On Fri, Jun 22, 2018 at 7:14 AM, David Wimsey wrote:
> Are you enabling the extra flags required for the JVM work detect memory
> and work properly?
>
> Specifically adding the following options to the JVM options when starting
> ignite
>
> -XX:+UseCGroupMemoryLimi
One node per container. Configuration below, key values come from env vars.
IGNITE_DATA_REGION_MAX_SIZE_MB=16384
IGNITE_DATA_REGION_MAX_SIZE=$(( $PIPE_IGNITE_DATA_REGION_MAX_SIZE_MB * 1024
* 1024 )) # 17179869184
IGNITE_JVM_OPTS='-Xms8g -Xmx8g'
IGNITE_PERSISTENCE_ENABLED=true
IGNITE_TEST_CACHE_BA
Well, that’s diving a bit deeper than the “don’t do cache operations” rule of
thumb, but let’s do that.
When receiver is invoked for key K, it’s holding the lock for K.
It is safe to do invoke on that K (especially if you control the invoked code)
since it is locked already.
But it is not safe t
Hi Stan,
Thanks for your analysis.
We have increased the on heap cache size 50 and added expiry policy
[30mins].
The expiry policy is expiring the entries and the cache is never reaching to
it's max size.
But now we see high heap usage because of that GCs are happening frequently
and FULL GC
Hi Stan,
Thanks for taking a look. I'm having trouble finding anywhere that it's
documented what I can or can't call inside a receiver. Is it just
put()/get() that are allowed?
Also, I noticed that the default StreamTransformer implementation calls
invoke() from within a receiver. So is that
Are you enabling the extra flags required for the JVM work detect memory and
work properly?
Specifically adding the following options to the JVM options when starting
ignite
-XX:+UseCGroupMemoryLimitForHeap. The -XX:+UnlockExperimentalVMOptions
See:
https://blogs.oracle.com/java-platform-grou
Hi,
Could you please provide your configuration files? How many nodes did you
start in your container?
BR,
Andrei
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi,
We've found and fixed few issues related to ExpiryPolicy usage.
Most likely, your issue is [1] and it is planned to ignite 2.6 release.
[1] https://issues.apache.org/jira/browse/IGNITE-8659
On Fri, Jun 22, 2018 at 8:43 AM Olexandr K
wrote:
> Hi Team,
>
> Issue is still there in 2.5.0
>
>
Hi,
No 11211 is a default ignite TCP port. For every new node, it will be
incremented 11211, 11212, 11213, etc.
Also please check that you didn't overwrite it.
https://www.gridgain.com/sdk/pe/latest/javadoc/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.html#setLocalPort-int-
And yes igni
Hi,
At least one backup, got it.
Thank you.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi Alex,
It accepts an IP and port as an argument. Do I need to enable ignite rest
and expose rest endpoints on cluster nodes for this to work?
Thanks,
Arun
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
14 matches
Mail list logo