Hi Luca, Thank you for looking into this. Just downloaded the latest M2 snapshot.
But as I do not use Java to interface with OrientDB, how do I achieve *ASYNCHRONOUS_NOANSWER* over the binary interface or the console? Can the dserver configuration xml be extended to do the same globally? Regards, - Ben On Tuesday, September 23, 2014 6:38:41 PM UTC+2, Lvc@ wrote: > > Hi guys, > I've just pushed to "develop" branch this fix: > > https://github.com/orientechnologies/orientdb/issues/2833 > > To enable true asynchronous operations also in ODistributedStorage. > Example: > > database.save(document, > *ODatabaseComplex.OPERATION_MODE.ASYNCHRONOUS_NOANSWER*, false, null, > null); > > *ASYNCHRONOUS_NOANSWER* means it doesn't wait for the response, but it's > executed asynchronously. > > Please could you test this mode on last OrientDB 2.0-M2-SNAPSHOT? > > Lvc@ > > On 23 September 2014 08:47, Christian Laakmann <[email protected] > <javascript:>> 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.
