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]> 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]. > 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.
