:-)
ᐧ

On 24 September 2014 23:48, <[email protected]> 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@ wrote:
>>
>> 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, <[email protected]> wrote:
>>
>>> 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 also tried to
>>> follow the WAN Replication features of Hazelcast at
>>> http://hazelcast.org/docs/3.1/manual/html/ch12.html, however OrientDB
>>> does not seem to do any replication in this mode. The docs aren't really
>>> clear on the steps involved other than alledging asynchronous replication
>>> is achieved by simply setting writeQuorum to 1.
>>>
>>> I don't know what other people do with OrientDB, but having our servers
>>> in sync is a must have feature for us. We were looking at purchasing the
>>> Enterprise Edition, though with the lack of feedback arising from this
>>> issue decided against doing so.
>>>
>>> Perhaps in the future OrientDB will support the features we require.
>>>
>>>
>>>
>>> On Saturday, September 6, 2014 4:43:36 PM UTC+2, [email protected]
>>> wrote:
>>>>
>>>> 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 glad to assist. On the other hand, if everything appears to be working
>>>> as it should, I would appreciate if you could let me know so we can move 
>>>> on.
>>>>
>>>> Thanks for your understanding.
>>>>
>>>> Regards,
>>>> - Ben
>>>>
>>>> On Friday, August 22, 2014 1:13:32 PM UTC+2, [email protected] wrote:
>>>>>
>>>>> Hi Luca,
>>>>>
>>>>> As requested, dserver test (writeQuorum 1):
>>>>>
>>>>> orientdb {GratefulDeadConcerts}> jss for(i=0;i<10000;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}> end
>>>>>
>>>>> Server side script executed in *7278.426758* sec(s). Value returned
>>>>> is: followed_by#11:17663{out:#9:1,in:#9:1,weight:1} v1
>>>>>
>>>>> Results in avg of *0.72784*.. seconds per insert.
>>>>>
>>>>> In contrast, server:
>>>>>
>>>>> orientdb {GratefulDeadConcerts}> jss for(i=0;i<10000;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}> end
>>>>>
>>>>>
>>>>> Server side script executed in *1.995000* sec(s). Value returned is:
>>>>> followed_by#11:27663{out:#9:1,in:#9:1,weight:1} v1
>>>>>
>>>>> Results in avg of *0.00019*.. seconds per insert.
>>>>>
>>>>> Regards,
>>>>> - Ben
>>>>>
>>>>> On Thursday, August 21, 2014 11:19:07 AM UTC+2, Lvc@ wrote:
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Lvc@
>>>>>> ᐧ
>>>>>>
>>>>>>
>>>>>> On 21 August 2014 10:04, <[email protected]> wrote:
>>>>>>
>>>>>>> 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,
>>>>>>> - Ben
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thursday, August 14, 2014 11:01:42 PM UTC+2, Lvc@ wrote:
>>>>>>>
>>>>>>>> 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/orientdb-server-log.properties and put
>>>>>>>> these lines
>>>>>>>>
>>>>>>>> .level = INFO
>>>>>>>> com.orientechnologies.level = INFO
>>>>>>>> com.orientechnologies.orient.server.distributed.level = FINE
>>>>>>>> com.orientechnologies.orient.server.hazelcast.level = FINE
>>>>>>>> com.orientechnologies.orient.server.journal.level = FINE
>>>>>>>>
>>>>>>>> At the restart you should have much more logging information, then
>>>>>>>> send us the log for the insert.
>>>>>>>>
>>>>>>>> Lvc@
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 14 August 2014 20:38, <[email protected]> wrote:
>>>>>>>>
>>>>>>>>> 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 {GratefulDeadConcerts}> insert into followed_by (out,
>>>>>>>>> in, weight) values (#9:1, #9:1, 1)
>>>>>>>>>
>>>>>>>>>  Inserted record 'followed_by#11:7061{out:#9:1,in:#9:1,weight:1}
>>>>>>>>> v1' in 0.953000 sec(s).
>>>>>>>>>
>>>>>>>>> When I don't run in distributed mode, I have:
>>>>>>>>>
>>>>>>>>>  orientdb {GratefulDeadConcerts}> insert into followed_by (out,
>>>>>>>>> in, weight) values (#9:1, #9:1, 1)
>>>>>>>>>
>>>>>>>>>  Inserted record 'followed_by#11:7063{out:#9:1,in:#9:1,weight:1}
>>>>>>>>> v1' in 0.002000 sec(s).
>>>>>>>>>
>>>>>>>>> writeQuorum 1 has no effect, I've tried several releases from the
>>>>>>>>> 1.7 branch and even 2.0, all with the same result. It is important to 
>>>>>>>>> note
>>>>>>>>> that the nodes are each located on a different continent.
>>>>>>>>> OrientDB looks great and I would really like to use it. Any advice
>>>>>>>>> on how to achieve asynchronous replication is greatly appreciated.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> - Ben
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>> Groups "OrientDB" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to [email protected].
>>>>>>>>>
>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>
>>>>>>>>
>>>>>>>>  --
>>>>>>>
>>>>>>> ---
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "OrientDB" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to [email protected].
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>>  --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "OrientDB" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to