Hi Igniters -
I tried to dump the thread stacks, but I don't know how to dump the
thread stacks from a docker container since it only contains a simplified
JRE, does not have JSTACK tools, and I also googled a lot of information but
found that there is no suitable method.
--
Sent from:
Hello
We are facing this exception when multiple clients are trying to read a big
cached object using the standard value = cache.get(key).
The cached object is a big serialized object that can reach hundreds of MB in
size. The server node has 16GB of heap which should be fairly enough for
Hi Ilya,
I am not able reproduce this issue in small reproducer project but this is
consistently happening in my project. So I debugged this issue and attached
the screenshot in this mail.
*NOTE: *This issue occurs if the statistics are enabled on cache
configuration level
awsCredentialsProvider is just a property of the TcpDiscoveryS3IpFinder.
If the class is loaded then the property should also be there.
I’ll try this as well and let you know if that works for me.
Stan
From: Max Barrios
Sent: 11 января 2019 г. 4:47
To: user@ignite.apache.org
Subject: Re:
Hello!
Turns out this issue isn't known yet. Can you file a ticket against Apache
Ignite JIRA?
Regards,
--
Ilya Kasnacheev
вс, 6 янв. 2019 г. в 10:39, yangjiajun <1371549...@qq.com>:
> Hello.
>
> I experiment on Ignite 2.7.The issue still appears.
>
>
> Denis Magda-2 wrote
> > Hello,
> >
> >
Hi,
we already do that by using an IgniteSet which contains consistent IDs of
the nodes that are ready, but it's very error-prone and unnecessarily
complex. Delaying joining the cluster would make everything simpler.
On Thu, Jan 10, 2019 at 1:38 PM Ilya Kasnacheev
wrote:
> Hello!
>
> I think
Running the query the first time isn’t really like loading all data into memory
and then doing the query. I would assume that
it is much less efficient – all kinds of locking and contention may be
involved. Also, the reads are done via random disk access, while when reading
from
CSV you’re
Currently we have no integration with DL4j in ignite ML and have no such
plans in roadmap.
The TF is the best platform for the Deep Learning now and we spend time on
integration with TF first of all.
Maybe, in future, direct integration between DL4j and ignite will be added.
But it costst a
FTR there is a JIRA issue for that fixed in 2.8
https://issues.apache.org/jira/browse/IGNITE-10856.
Stan
From: Serg
Sent: 2 января 2019 г. 15:51
To: user@ignite.apache.org
Subject: Re: ignite-cassandra-store module has incorrect dependencies
Unfortunately I could not just change my pom
Yes, that’s how EternalExpiryPolicy works. You can achieve the same by just not
using an expiry policy at all – Ignite doesn’t evict entries by default.
Stan
From: rick_tem
Sent: 7 января 2019 г. 12:38
To: user@ignite.apache.org
Subject: Re: Do elements with EternalExpiryPolicy in cache ever
Yes, I agree with your conclusion. I have no benchmarks, of course, but it
seems that no speedup in DL4j on Spark on Ignite RDD
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
I know one way to do that – connect via SQLLine and execute !indexes command.
Check out this doc https://apacheignite-sql.readme.io/docs/sqlline
Stan
From: Shravya Nethula
Sent: 7 января 2019 г. 13:49
To: user@ignite.apache.org
Subject: Re: Failing to create index on Ignite table column
Hi,
Is
+1 to all points.
Generally, the message “Local node SEGMENTED” generally means that the cluster
decided that the node is dead and kicked it out.
The next time the node tried to send a message to the cluster, it received an
answer “you’re segmented” meaning “we’ve kicked you out, sorry”.
It
Hello!
It is a known regression in 2.7:
http://apache-ignite-developers.2346864.n4.nabble.com/System-Worker-Failure-Handler-on-local-laptop-tp39810p39812.html
"To workaround the issue, you should set
DataStorageConfiguration#setCheckpointReadLockTimeout
to 0."
Increasing failureDetectionTimeout
Well, it means that node 6 didn’t answer to the node 2.
Was the node 6 dropped from the cluster after that?
It could happen because of a network issue, GC on the node 6, perhaps some
OS/VM issue.
Can’t say anything more specific with that little info.
Stan
From: sehii
Sent: 4 января 2019 г.
Thank you Rohan
972.900.1561
Scott Cote
From: Stephen Darlington
Sent: Friday, January 11, 2019 5:31:12 AM
To: user@ignite.apache.org
Subject: Re: Pain points of Ignite user community
Nice work!
On 10 Jan 2019, at 15:26, Stanislav Lukyanov
Hello!
I'm afraid that visor will try to connect to your client and will wait
until this is successful.
Regards,
--
Ilya Kasnacheev
пт, 11 янв. 2019 г. в 20:01, John Smith :
> Humm maybe not. The client is running on my laptop through the wi-fi. But
> the cluster and visor are on the dev
That's the thing... There is none. It just seems to pause and wait. The
moment I close my client application it just resumes...
But other commands like top work fine...
On Fri, 11 Jan 2019 at 12:15, Ilya Kasnacheev
wrote:
> Hello!
>
> If they're on the same network it is not obvious what
Hello!
You can always do Ingnition.getOrStart(), it will be an effective singleton.
Same with getOrCreateCache().
Keeping an instance might be slightly faster but that should not be very
important.
However, if you have more than one node you better keep explicit references
to them to avoid
Hello!
If they're on the same network it is not obvious what happens here, but I
have just performed the steps you have mentioned without problems.
Can you collect stack traces from all nodes when this hang happens?
Regards,
--
Ilya Kasnacheev
пт, 11 янв. 2019 г. в 20:12, Ilya Kasnacheev :
Hi,
No, I am not using JDBC driver.
Re switching to the pessimistic transaction, tried but is not working
correctly in some cases, for instance, .clear() on caches and some more...
which is fine as Igniters state it's not production ready yet. Obviously
happy guys you are adding new transaction
Some java code that helps me on node startup:
// Call for each partition in parallel
private void preloadPartition(int partition) {
IgniteCache cache = ignite
.cache("test_cache")
.withKeepBinary();
ScanQuery query = new
ScanQuery<>(partition, (k,
Hello!
You can decrease number of stripes but it will also hamper your
performance. Moreover maybe queue will just be redistributed.
Have you tried decreasing rebalance throughput?
https://apacheignite.readme.io/docs/rebalancing#rebalance-thread-pool-tuning
Regards,
--
Ilya Kasnacheev
пт, 4
Hi,
Currently, after cluster activation, if a node with native persistence
is enabled terminates abnormally,when the node is restarted, it cannot
join the cluster.
So the question is:
1.If the node terminates abnormally, how can the node rejoin the cluster?
2.How to restart the node
Hello!
thanks for prompt resolution, will try once 2.8 is out.
Best!
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Nice work!
> On 10 Jan 2019, at 15:26, Stanislav Lukyanov wrote:
>
> Hi Rohan,
>
> Sorry, the publishing took some time.
> In case you’re still interested, here’s the article:
> https://www.gridgain.com/resources/blog/checklist-assembling-your-first-apacher-ignitetm-cluster
>
>
Hello!
Can you show what you get in logs as your nodes attempt to join the cluster?
Regards,
--
Ilya Kasnacheev
пт, 11 янв. 2019 г. в 19:43, 李玉珏@163 <18624049...@163.com>:
> Hi,
>
> Currently, after cluster activation, if a node with native persistence
> is enabled terminates abnormally,when
Humm maybe not. The client is running on my laptop through the wi-fi. But
the cluster and visor are on the dev network. But the client on my laptop
is capable of joining the cluster through the wi-fi and processing requests
no problems.
On Fri, 11 Jan 2019 at 10:56, Ilya Kasnacheev
wrote:
>
Hello!
Have you tried enabling Zookeeper in your reproducer? I have a hunch that
they are linked: this behavior is affected by zookeeper discovery.
Regards,
--
Ilya Kasnacheev
пт, 11 янв. 2019 г. в 17:44, Prasad Bhalerao :
> I tried to reproduce this in standalone program. But the thing is
Hello!
I'm afraid you will have to avoid using visor, use web console instead. The
issue should only arise if there are daemon nodes, such as Visor.
Otherwise, if you need node to rejoin cluster & do not mind data, you can
remove Ignite work dir in order to start anew.
Regards,
--
Ilya
Hello!
Are you sure that your Visor node is able to connect to client node via
communication port? Nodes in cluster need to be able to do that, which is
somewhat unexpected in case of client node.
Regards,
--
Ilya Kasnacheev
пт, 11 янв. 2019 г. в 18:36, John Smith :
> Hi, sorry if this a
I have in doubt. In last mail you said that dl4j over ignite have no speed
up and you say now maybe develope in future.is it worthwhile for doing it?
On Friday, January 11, 2019, zaleslaw wrote:
> Currently we have no integration with DL4j in ignite ML and have no such
> plans in roadmap.
> The
Hello!
Actually, delaying joining the cluster is complex enough since it will add
a lot of unexpected concerns.
There are ClusterGroup's precisely for that purpose.
Regards,
--
Ilya Kasnacheev
пт, 11 янв. 2019 г. в 15:58, Lukas Polacek :
> Hi,
> we already do that by using an IgniteSet
Is there a command that one can/needs to run to load the data into memory
after restart of Ignite? The documentation suggests that at least for 2.7
that is not necessary, and I have not found a command that would start the
loading into memory from persistence. It looks like one can write some Java
Hello.
I have created it:
https://issues.apache.org/jira/browse/IGNITE-10897
ilya.kasnacheev wrote
> Hello!
>
> Turns out this issue isn't known yet. Can you file a ticket against Apache
> Ignite JIRA?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вс, 6 янв. 2019 г. в 10:39, yangjiajun <
>
Hello!
I think the problem was introduced by
https://issues.apache.org/jira/browse/IGNITE-6846 which does look very
suspicious, however it is strange that it does not reproduce right away.
I could try and devise a fix but I could not reproduce this behavior in any
of tests. If you could do a
Hi, sorry if this a double post I tried through nabble and I don't think it
came through...
So using 2.7...
I have a 3 node cluster started with ignite.sh and that works perfectly
fine. I'm also able to connect to the cluster with visor and I can also run
top, cache etc... commands no problem.
And it seems to say like that indefinitely. I let it go for 5 minutes and
nothing has printed to the console or logs.
On Fri, 11 Jan 2019 at 12:49, John Smith wrote:
> I can confirm I just tested it. There is no stack trace. Basically the
> client connects, no errors, the cache command
Yeah this doesn't work on the dev environment either, because the
application is running in docker on bridge mode, but the cluster is on
standard VM hosts. I'm using DC/OS...
Does the Mesos deployment support DC/OS? If not I can create custom
marathon docker images for it...
On Fri, 11 Jan 2019
No I am not using zookeeper discovery.
Using TcpDiscoveryVmIpFinder.
Can someone please explain on what event cacheMetrics in TcpDiscoveryNode
gets populated. It is not getting populated in standalone program.
If it gets populated then I might be able to reproduce this case.
On Fri 11 Jan,
Yeath, set a larger MaxDirectMemorySize .
But, I am afraid of when nodes size be more larger.The directmemory will be
larger with node sizes.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
When a client node start with zk discovery and persistence enabled,Some null
point exceptions will be throw (when the node start on a new machine )
The exception traces as follows:
12:26:03.288 [zk-172_22_29_108_SEARCH_NODE_8100-EventThread] ERROR
o.a.i.i.p.c.GridContinuousProcessor - Failed to
42 matches
Mail list logo