Hi Luca, Yes, I'm aware of that...
My reference to 1.7.9 was only concerning Christian's suggestion. When I tested 2.0-M2, i still have no improvement. Does it need to be activated for use in the console or binary interface? I do not have Java apps for creating documents. Regards, - Ben On Tuesday, September 23, 2014 9:14:57 PM UTC+2, Lvc@ wrote: > > Hi Ben, > This is supported only in 2.0-M2. > > Lvc@ > > ᐧ > > On 23 September 2014 21:03, <[email protected] <javascript:>> wrote: > >> Hi Christian, >> >> Tried your suggestion too on 1.7.9, unfortunately it hasn't had any >> influence even though it looked promising. >> >> Regards, >> - Ben >> >> >> On Tuesday, September 23, 2014 8:48:00 AM UTC+2, Christian Laakmann wrote: >>> >>> Hi all, Luca, >>> >>> it seems as if you wait for synchronous responses from _all_ available >>> Nodes, even if quorum is set to 0. In >>> ODistributedResponseManager#collectResponse, >>> this code handles the notification of waiting threads after all expected >>> responses have been received. >>> >>> if (receivedResponses >= expectedSynchronousResponses && >>> (!waitForLocalNode || receivedCurrentNode)) { >>> if (completed || isMinimumQuorumReached(false)) { >>> // NOTIFY TO THE WAITER THE RESPONSE IS COMPLETE NOW >>> notifyWaiters(); >>> } >>> } >>> >>> My expectation would be, that #isMinimumQuorumReached() were called as >>> part of the first IF, i.e.: >>> >>> if (completed >>> || isMinimumQuorumReached(false) >>> || (receivedResponses >= expectedSynchronousResponses && >>> (!waitForLocalNode || receivedCurrentNode))) { >>> // NOTIFY TO THE WAITER THE RESPONSE IS COMPLETE NOW >>> notifyWaiters(); >>> } >>> >>> From my understanding, this would notify the waiting thread that pushed >>> the task as soon as the quorum is reached or all responses from the >>> available nodes have been collected. >>> >>> Cheers, >>> Christian >>> >>> >>> On Tuesday, 23 September 2014 00:58:55 UTC+2, [email protected] wrote: >>>> >>>> Hi Luca, >>>> >>>> Since I've been hung out to dry, I've toyed around with the orientdb >>>> sources. I was able to establish that the bottlenecks are indeed >>>> sendRequest and send2Nodes. Removing sleeps in the latest 1.7.9 release >>>> already provided a 50% improvement (From ~1.2sec down to ~0.55sec.). >>>> Clearly we have different views on what is asynchronous. In your methods, >>>> you inarguably wait for a response from the nodes before giving a response >>>> to the client. IMHO asynchronous replication should update the local >>>> database, respond to the client and care about the rest later. I believe >>>> the replication methodology needs a rethink. Whilst in may be suitable to >>>> LAN environments, it is certainly not suitable for WAN. I still wonder if >>>> this is intended or even if it has ever been tested. I see examples with >>>> europe and usa nodes with sharding, etc.. but I can't believe such delays >>>> are accepted or the norm. Other technologies can do it, so should OrientDB. >>>> >>>> Anyway, enough of my ramblings.... Have a good evening. >>>> >>>> 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] <javascript:>. >> 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.
