Hi,
thanks for your answer. Where can I get the latest snapshot? I use 1.7 RC2 
and I've downloaded it on the 1st of April 2014.
Ok, when I set hotAlignment = false, I receive the latest update. But I've 
tested sth.: let's say one node gets "offline" because there's no more 
network connection. Then let's suppose I create some local changes at the 
same property for both nodes, for example: NODE1: Name = test; @Version = 
1; NODE2: Name = noTest; @Version = 1; When the network connection returns, 
then I received the following messages in a loop: 

WARN  [WaitNotifyServiceImpl$WaitingOp] [161.228.100.233]:2434 class 
com.hazelcast.spi.exception.WrongTargetException: WrongTarget! 
this:Address[161.228.100.233]:2434, target:Address[161.228.100.221]:2434, 
partitionId: 166, replicaIndex: 0, operation: 
com.hazelcast.spi.impl.WaitNotifyServiceImpl$WaitingOp, service: 
hz:impl:queueService

Is this because I changed the same property at two nodes? How could I 
configure the bevaiour of the merging? I would like to be informed when 
there's such a conflict: either I would like the user to solve that issue 
manually or the "newest" (by timestamp) version should replace the older 
(by timestamp) one? Where could I configure that? Can I change that by 
coding?
When I restart the whole server than the restarted node gets the data from 
the running one ... but as I said, I would like to have the "newest" (by 
timestamp) data or that the user could solve that manually ... How could I 
achieve that?

Thanks.

Am Sonntag, 20. April 2014 10:54:27 UTC+2 schrieb Lvc@:
>
> Hi,
> Sorry for such delay on answer. We're improving the distributed part in 
> these days by enriching the documentation with new example for replication 
> and sharding. Stay tuned!
>
> In the meanwhile may you try last 1.7-SNAPSHOT? We fixed some issues about 
> replication. And if the synchronization with offline nodes has problem, 
> please report issues like you did, but to avoid to be stuck with such 
> problems set hotAlignment = false in distributed-config.json file. Every 
> time the node will return back online, the database is transparently copied 
> to the new server.
>
> Lvc@
>
>
>
> On 19 April 2014 11:16, OK <[email protected] <javascript:>> wrote:
>
>> Hi,
>>
>> I really would like to use OrientDB for my project but I think that it is 
>> compared to other databases not well documented!!
>> The functions like auto-deploy of databases and auto-recognition of new 
>> member nodes are really awesome.
>> Moreover the database is very fast and the development with Java is very 
>> easy.
>> But the distributed section with replication etc. and the configuration 
>> of a distributed scenario like my described one is absolutely horror ...
>> There are no examples of configuration files and the possible options are 
>> not described ...
>> It's really urgent for me to have a working database for my project. 
>> Because of that I tried to use DB4o yesterday and I successfully tested my 
>> described replicated scenario ... and it worked in less than 2 hours ... 
>> but you have to code every single step.
>> With OrientDB, coding is easier but I tried three whole days to configure 
>> the distributed replication scenario without success!!!
>> So please help me with the config-files or please tell me if my scenario 
>> is possible to configure with OrientDB.
>>
>> Once again my scenario:
>>
>> local OrientDB: storing "POJOS" (documents) and is sometimes offline
>>
>> When the local DB has a network connection, it should be replicated with 
>> a central OrientDB on a central server that is always online.
>> The central server also gets some data from other machines.
>> Because of that I need to have a bi-directional asynchronous, 
>> multi-master (peer-to-peer) replication configuration with some nodes that 
>> can go "offline" and gets the up-to-date data when they return back 
>> "online".
>> Which configuration files do I need to configure???
>>
>> I hope that someone could help me soon or give me some hints.
>>
>> Thanks.
>>
>>
>>  -- 
>>
>> --- 
>> 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.

Reply via email to