Hello, Eugene!
> 2) How come Non-heap memory usage is minimal?
"Non-heap memory" here it's JVM managed memory regions other then heap used
for internal JVM purposes (JIT compiler, method area, etc.), it's not a
memory used by Ignite to store data (information about this memory can be
obtained by
Hi,
Sounds fantastic!
There is no separate repository for benchmarks, the latest version you can
find is in master branch here:
https://github.com/apache/ignite/tree/master/modules/yardstick.
Discussions and contributions are always welcome, if you have some insights
on what could be
Yes,I came the reason ,i have changed already existing object field
type(string to date ) which ignite don't support ,that is the reason its
trowed serialization exception .
Thanks *akurbanov *for your support.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Vishwas,
You may clone Ignite repo and cherry-pick a commit.
And build from sources.
Will this work for you?
On Fri, Aug 17, 2018 at 5:27 PM vbm wrote:
> Hi,
>
> Can this fix be backported to 2.5 or 2.6 version ?
>
> Regards,
> Vishwas
>
>
>
> --
> Sent from:
Hi!
> 1) In Data region metrics, why is everything 0?
Did you enable metrics?
See:
DataRegionConfiguration dataRegionCfg = new DataRegionConfiguration();
dataRegionCfg.setMetricsEnabled(true);
> 4) Total busy time is 15s, the upload took longer than that.
This is actually time spend in
Hello,
I am running a single Ignite node on a r4.8xlarge EC2 node. I am using the
default settings with 132G allocated for the default memory region. So far
I have uploaded 1 large table 60M rows using Spark
The output of node and cache commands is pasted bellow.
A few questions
1) In Data
Hello!
Please try notifying Ignite about your types so that you can use them
immediately (without putting to cache first):
ignite.GetBinary().GetBinaryType(typeof(TestEntityKey));
ignite.GetBinary().GetBinaryType(typeof(TestEntity));
that before your Console.WriteLine()
I’v got an ignite java server node and a client node which is c#
application
public partial class TestEntityKey
{
public string s1 { get; set; }
public string s2 { get; set; }
}
public partial class TestEntity
{
public string v1 { get;
The above error appears to be an issue in
org.apache.ignite.internal.processors.cache.CacheMetricsSnapshot in a
mismatch between the readExternal() and writeExternal() methods.
I've made a change locally and it fixed the error and also the testing so
far seems to show that the queries return the
Thx... will yry the fix.
Regards,
Igor
On Fri, Aug 17, 2018 at 11:24 Denis Mekhanikov
wrote:
> Igor,
>
> The fix for this issue is merged to master. It will be included into
> Ignite 2.7.
> Until then you can use one of the nightly builds, available at
>
Hi ,
The issue is
failed to set up benchmark drivers java.lang.nullpointerexception
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi,
Can this fix be backported to 2.5 or 2.6 version ?
Regards,
Vishwas
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Igor,
The fix for this issue is merged to master. It will be included into Ignite
2.7.
Until then you can use one of the nightly builds, available at
https://ci.ignite.apache.org/viewLog.html?buildId=lastSuccessful=Releases_NightlyRelease_RunApacheIgniteNightlyRelease=artifacts=1
Denis
пн, 6
Hello,
As I mentioned above, this exception indicates that the cache with the
given name already exists in the cluster.
Thanks,
S.
пт, 17 авг. 2018 г., 10:52 daya airody :
> Hi Slava,
>
> other reply is about issues in caching Spring proxied objects.
>
> I am also seeing "Cache already
Thank you Alex, but why one of my ignite nodes went down abnormally?
发件人: Alex Plehanov
发送时间: 2018年8月17日 15:58:07
收件人: user@ignite.apache.org
主题: Re: why my ignite cluster went to compatibility mode
Hi, Huang,
Already was discussed here [1]. You probably run
Hello @sv
Problem is fixed and will be available in Ignite 2.7.
As a workaround you can download a valid configuration immediately after
configuration page refresh.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi, Huang,
Already was discussed here [1]. You probably run visor (daemon node) to
join cluster, which switch cluster to compatibility mode. You can restart
to switch it to normal state again. Fix (ticket IGNITE-8774) will be
available in Ignite 2.7
[1]:
Hi Slava,
other reply is about issues in caching Spring proxied objects.
I am also seeing "Cache already exists" issue. Could you please throw some
light on this?
Thanks in advance,
--daya--
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Thanks Ivan.
If methodCache is marked as transient, proxied objects are not meant to be
cached. Since this object is returned by spring JPA, hibernate second level
caching might be enough. Looks like we should not cache JPA returned objects
at method level.
--
Sent from:
Hi all,
I'm new to ignite, I started a ignite cluster with three nodes yesterday(with
command: ./ignite.sh -v -np
/root/apache-ignite-fabric-2.6.0-bin/examples/config/persistentstore/examples-persistent-store.xml),
I found one node is down without any log today, and when I try to restart the
20 matches
Mail list logo