Hi, fix [1] already in master.
[1] https://issues.apache.org/jira/browse/IGNITE-14076
>
>Hi !
>
>
>
>>Hi,
>>
>>Because of the kind of product we have to develop, we currently have a set
>>of scenarios with this kind of transactions and we're evaluating several
>>datastores as RocksDB and,
Hello!
FYI: https://issues.apache.org/jira/browse/IGNITE-14165
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hello!
Answering to myself:
Should I get a better performance in a multi-node cluster? Of course!
We have switched to a 4-node cluster and reading times dropped drastically.
We are really looking forward the PutAll bug to be fixed to perform writing
tests.
--
Sent from:
Hi, thanks for pointing it out
This confirms our tests... moving from a single-node cluster to a two-nodes
one dropped the read timings to less than the half!
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
I’ve not been following this thread closely, so I apologise if I’ve missed
something.
> - Should I get a better performance in a multi-node cluster? Read/Write/Both?
As per the documentation:
“Ignite is designed and optimized for distributed computing scenarios. Deploy
and benchmark a
Hello!
That's exactly the reason why we would prefer to choose Ignite over RocksDB.
Otherwise, we will have to implement scalability by ourselves and, believe
me, that's not something we would like to do.
We also know they're not directly comparable. We would agree to pay the
price for
Hello!
RocksDB is an embedded database whereas Apache Ignite is a *distributed*
database.
Regards,
--
Ilya Kasnacheev
ср, 10 февр. 2021 г. в 16:11, jjimeno :
> Hi,
>
> Because of the kind of product we have to develop, we currently have a set
> of scenarios with this kind of transactions and
Hi,
Because of the kind of product we have to develop, we currently have a set
of scenarios with this kind of transactions and we're evaluating several
datastores as RocksDB and, sadly, timings there are quite better than the
ones I've got in Ignite... :(
Data streamer is not available in C++
Hello!
I think you need to register first.
Btw, why do you need such large transactions? Have you considered data
streamer instead?
Regards,
--
Ilya Kasnacheev
ср, 10 февр. 2021 г. в 15:28, jjimeno :
> I wouldn't mind, but I'm afraid I'm not allowed to... at least, I couldn't
> find the
I wouldn't mind, but I'm afraid I'm not allowed to... at least, I couldn't
find the option on that page :)
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hello!
Would you care to create a JIRA ticket for that issue?
https://issues.apache.org/jira/projects/IGNITE/issues
Regards,
--
Ilya Kasnacheev
ср, 10 февр. 2021 г. в 14:18, jjimeno :
> Hi,
>
> First off, thanks for your help.
>
> In the test, I'm using a single server node cluster with the
Hello Ilya,
Yes, but it has nothing to do with suspending an active transaction... the
problem is that transaction never reaches ACTIVE state because it takes a
long time creating the tcp message.
Please, take a look to my previous post.
--
Sent from:
Hi,
First off, thanks for your help.
In the test, I'm using a single server node cluster with the official 2.9.1
version. Client is a C++ Thin Client with transactions support (commit
685c1b70ca from master branch).
The test is very simple:
struct Blob
{
int8_t
Hello!
I can see that the only occurrence of transaction suspending in our own
code is in thin client implementation.
Do you happen to use thin client for this operation?
Regards,
--
Ilya Kasnacheev
пн, 8 февр. 2021 г. в 20:32, akorensh :
> I would also recommend taking a thread dump to see
I would also recommend taking a thread dump to see where this suspension is
coming from.
Attach this thread dump here along w/the reproducer.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi,
Make sure that your code is not suspending these transactions under high
load conditions.
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/transactions/Transaction.html#suspend--
See this guide:
https://ignite.apache.org/docs/latest/key-value-api/transactions
Try
Another test with 2M keys and 1GB also remains in SUSPENDED state after 11
minutes...
I don't understand where the difference between this one and the successful
1.2M keys and 600MB could be. Any idea is welcomed
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi again,
For an smaller succeeding transaction 1.2M keys and 600MB in size, I noticed
it changed its state something similar as follows:
SUSPENDED -> ACTIVE -> COMMITTING
... and it takes around 3 min to finish.
For another test with 4M keys and 2GB it is still in SUSPENDED state after
30
18 matches
Mail list logo
