I forget to attach my configuration (I removed the cache config details)I'm
using the debian package, so I run the cluster with xml
configuration.
Regards,
--
Bastien Durel
DATA
Intégration des données de l'entreprise,
Systèmes d'information décisionnels.
bastien.du...@data.fr
tel : +33 (0)
Hello,
I'm running a 2.9.0 cluster with 2 nodes. I tried to use grid grain's
ControlCenterAgent to investigate a slowdown.
When I removed the agent files from server (I don't like to have to put
it in all clients), the second node cannot join the cluster when I
start it.
If I start node A, then
Hi, could anyone please help understand why the heap of a client app has such
large amounts of data pertaining to binary meta data?
Here it takes up 30mb but in our UAT environment we have approx 50 caches.
The binary meta data that gets added to the client's heap equats to around
220mb (even for
On of these, depending on your query type:
* new ScanQuery() { PageSize = 5 }
* new SqlQuery() { PageSize = 5 }
On Wed, Oct 28, 2020 at 5:24 PM Ravi Makwana
wrote:
> Hi Paval,
>
> As we are not setting explicitly QueryBase.Pagesize for SqlQuery and
> SqlFieldQuery so default will be used as
Hi Paval,
As we are not setting explicitly QueryBase.Pagesize for SqlQuery and
SqlFieldQuery so default will be used as 1024.
We have not found so far any example by looking the same we can try to
explicitly set the Query base.Pagesize.
Can we have any reference by checking that we can try to
On Wed, 28 Oct, 2020, 5:55 pm Pavel Tupitsyn, wrote:
> I found a bug in Ignite [1] which probably causes the issue on your side.
>
> Looks like you are running a query (is it a ScanQuery or SqlQuery?) and
> the size of one results page exceeds 2GB.
> Please try using a smaller value for
I found a bug in Ignite [1] which probably causes the issue on your side.
Looks like you are running a query (is it a ScanQuery or SqlQuery?) and the
size of one results page exceeds 2GB.
Please try using a smaller value for *QueryBase.PageSize*.
If you use the default value of 1024, your cache
Thanks Pavel for the replies.
I did a quick/basic benchmark of IgniteAtomicLong, and IgniteAtomicLong,
with only two ignite nodes, with 1,000,000 iterations. Unless, I am doing
something wrong, the result was very disappointing.
With IgniteAtomicSequence, the iterations took about 30 seconds.
Hi,
Our service is running with 64 bit and we have verified the same in our app
server too.
Any finding from the logs?
Is there any way to replicate it?
Thanks,
On Wed, 28 Oct 2020 at 15:47, Pavel Tupitsyn wrote:
> Looks like the app is running in 32 bit mode, which can't use more than
>
The atomic sequence/long could be persisted if the default data region is
persistent[1].
One of the use cases for IgniteAtomicSequence is to generate unique IDs.
You could estimate the volume implicitly by getting metrics from the
default data region[2].
[1]
Looks like the app is running in 32 bit mode, which can't use more than 2GB
of memory.
JVM and memory regions pre-allocate all of it, leaving nothing for .NET to
use.
Please check the `Platform` column in the Task Manager - does it say `32
bit`?
If yes, then try disabling `Prefer 32 bit` in the
11 matches
Mail list logo
