On 24 Sep 2014, at 16:31, Luca Garulli <[email protected]> wrote:
> Hi guys,
> I've some updates. Using an queue in the middle improved performance.
> Furthermore I've extended the asynchronous also to transactions.
>
> Please could you re-test last version 2.0-M2-SNAPSHOT?
FYI, I get the following error using the latest snapshot in embedded mode with
Java 7:
java.lang.NoSuchMethodError:
java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
I assume this is because the snapshot was built using Java 8, which changed the
return type of keySet for ConcurrentHashMap:
http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html#keySet--
whereas in Java 7 it’s still the plain Set:
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ConcurrentHashMap.html#keySet()
Possible workarounds (assuming the plan is still to support Java 7) is either
build with a version of Java before 8, or use Map or ConcurrentMap for the
field rather than the concrete type:
diff --git
a/core/src/main/java/com/orientechnologies/orient/core/config/OContextConfiguration.java
b/core/src/main/java/com/orientechnologies/orient/core/config/OContextConfiguration.java
index d0dee2b..52c28b4 100644
---
a/core/src/main/java/com/orientechnologies/orient/core/config/OContextConfiguration.java
+++
b/core/src/main/java/com/orientechnologies/orient/core/config/OContextConfiguration.java
@@ -27,7 +27,7 @@ import java.util.concurrent.ConcurrentHashMap;
*
*/
public class OContextConfiguration implements Serializable {
- private final ConcurrentHashMap<String, Object> config = new
ConcurrentHashMap<String, Object>();
+ private final Map<String, Object> config = new ConcurrentHashMap<String,
Object>();
/**
* Empty constructor to create just a proxy for the OGlobalConfiguration. No
values are setted.
( this is the place where the exception originates, there may be a couple of
other fields using ConcurrentHashMap where they could just as well use Map or
ConcurrentMap... )
—
Cheers, Stuart
> Lvc@
>
> On 24 September 2014 11:31, Luca Garulli <[email protected]> wrote:
> Hi Ben,
> I found a bottleneck in Hazelcast:
> https://github.com/hazelcast/hazelcast/issues/3661.
>
> I could put a queue between ODistributedStorage and HZ. Let me try it now.
> Soon a new push.
>
> Lvc@
> ᐧ
>
> On 24 September 2014 10:59, <[email protected]> wrote:
> Hi Luca,
>
> I tested this and now get 0.24sec average inserts, which is the fastest
> distributed performance I've experienced yet.
>
> There still seems to be communication with the remote node before releasing
> the client though.
>
> Regards,
> - Ben
>
> On Wednesday, September 24, 2014 1:24:23 AM UTC+2, Lvc@ wrote:
> Hi Ben,
> I've pushed a new version that reads the configuration from file
> default-distributed-db-config.json, by adding:
>
> "executionMode": "asynchronous",
>
> Lvc@
> ᐧ
>
> On 23 September 2014 21:53, <[email protected]> wrote:
> 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]> 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].
> 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.
