:-)
ᐧ
On 24 September 2014 23:48, wrote:
> And as such, I would like to retract my previous disgruntled statement.
>
> As of the latest 2.0-M2-SNAPSHOT, OrientDB indeed supports *true*
> asynchronous replication.
>
> Regards,
> - Ben
>
> On Wednesday, September 24, 2014 5:32:45 PM UTC+2, Lvc@ wr
And as such, I would like to retract my previous disgruntled statement.
As of the latest 2.0-M2-SNAPSHOT, OrientDB indeed supports *true*
asynchronous replication.
Regards,
- Ben
On Wednesday, September 24, 2014 5:32:45 PM UTC+2, Lvc@ wrote:
>
> Hi,
> I'd like to update this thread too by tryin
Hi,
I'd like to update this thread too by trying last 2.0-M2-SNAPSHOT where now
it's asynchronous apart form Hazelcast.
Lvc@
ᐧ
On 9 September 2014 11:24, wrote:
> So here is my final report...
>
> We have scoured all the available docs and come to the conclusion that
> OrientDB *does not* supp
So here is my final report...
We have scoured all the available docs and come to the conclusion that
OrientDB *does not* support 100% asynchronous replication.
writeQuorum 1 is just as fast as writeQuorum 2 which leads me to believe
this flag has no effect in the sources. Alternatively we have
Hi Luca,
I've just tested orientdb-community-1.7.9-20140906.091114-5 SNAPSHOT and
unfortunately I see no improvement. I'm inclined to open an issue on
github, but I have no idea if this issue is actually worked on or not.
Please advise if there is anything else you need from my side. I would be
Hi Luca,
As requested, dserver test (writeQuorum 1):
orientdb {GratefulDeadConcerts}> jss for(i=0;i<1;i++)
{db.command('insert into followed_by (out, in, weight) values (#9:1, #9:1,
1)');}
[Started multi-line command. Type just 'end' to finish and execute]
orientdb {GratefulDeadConcerts}> e
Hi Ben,
Sorry for delay. That is not the time of each insert. Please try to do the
same in a loop of 10k times and get the average time per cycle.
However I'm working on a separate branch to speed up distributed
configuration. We have good numbers so far, but we need more days to merge
with 1.7.9.
Dear Luca,
I've sent you the log last Friday. I urgently need to move forward on this.
If nothing can be done to get OrientDB to work asynchronously, I have to
look at alternatives.
OrientDB appears interesting for numerous reasons though, which is why I'd
like to stick with it.
Regards,
- Be
Hi Lvc,
Do you have any updates concerning this issue? Are there are any temporary
fixes we can implement to allow us to use distributed mode asynchronously?
Regards,
- Ben
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from
Hi Lvc,
Thanks for quick response. I've updated the log settings as you specified
and attached the output for the following insert (still with writeQuorum 1):
orientdb {GratefulDeadConcerts}> insert into followed_by (out, in, weight)
values (#9:1, #9:1, 1)
Inserted record 'followed_by#11:706
Hi Ben,
setting writeQuorum = 1 in your scenario means that the server node where
the client is connected should be the first to respond (for obvious
reasons), so it's crazy it takes 1 second for 1 insert.
To know more try to enable logging on the server where the client is
connected. Edit config/
Dear colleagues,
I am trying to figure out how to deploy a distributed orientdb setup. I've
followed the manuals, which explicitly state that writeQuorum 1 will result
in 100% asynchronous mode, however I am faced with inserts taking up to 1
second or more. Example:
orientdb {GratefulDeadConc
12 matches
Mail list logo
