plocal support for distributed databases

[lvca]

I'm debugging issues on replications so today I tried switching to plocal:

• open a console and create the "test" database as plocal with the class "Customer"
• exit console
• copy & paste orientdb-graphed-1.6.0-SNAPSHOT in orientdb-graphed-1.6.0-SNAPSHOT2 (so with the same "test" database just created)
• start server 1 -> orientdb-graphed-1.6.0-SNAPSHOT
• start server 2 -> orientdb-graphed-1.6.0-SNAPSHOT2
• 2 servers are in cluster. Ok
• execute the class
  com.orientechnologies.orient.server.distributed.SimulateOperationsAgainstServer (I've only changed threads to 3 and db name to "test")

everything works: the client connects to both servers and replication works like a charm
now I kill server 2

Last time I tried it with local everything worked well but now client received these exceptions:
com.orientechnologies.orient.core.exception.OConcurrentModificationException: Cannot UPDATE the record #9:0 because the version is not the latest. Probably you are updating an old record or it has been modified by another user (db=v-2147483647 your=v0)

What's the version -2147483647 ?

Plocal can't manage update record version. This is needed when the record is aligned from another server. We use to set to Integer.MIN_VALUE + version so if it's < -2 it restored at the original version number and updated. This is the relevant code in local and memory storages on updateRecord() methods:

        default:
          if (version.getCounter() > -1) {
            // MVCC TRANSACTION: CHECK IF VERSION IS THE SAME
            if (!version.equals(ppos.recordVersion))
              if (OFastConcurrentModificationException.enabled())
                throw OFastConcurrentModificationException.instance();
              else
                throw new OConcurrentModificationException(rid, ppos.recordVersion, version, ORecordOperation.UPDATED);
            ppos.recordVersion.increment();
          } else {
            // DOCUMENT ROLLBACKED
            version.clearRollbackMode();
            ppos.recordVersion.copyFrom(version);
            cluster.updateVersion(rid.clusterPosition, ppos.recordVersion);
          }
        }

[mattaylor]

Any idea if this is going to be fixed soon?

[andrii0lomakin]

Actually it seems not the issue now. @lvca should we close it ? Is it correct that we have users who use plocal with new distributed storage without problems ?

[lvca]

Yes, we fixed this about 2 weeks ago. @mattaylor can you retry it please? In case the problem persists I'll reopen it

[mattaylor]

We were struggling with this for a a week now, but it looks like we found our problem - seems to be working ok now, although we are having some issue where only the master node can serve requests as the other nodes keep aligning.

Thanks,
Mat

On Oct 9, 2013, at 10:30 AM, Luca Garulli notifications@github.com wrote:

Yes, we fixed this about 2 weeks ago. @mattaylor can you retry it please? In case the problem persists I'll reopen it

—
Reply to this email directly or view it on GitHub.

[lvca]

Can you retry with last snapshot please?

[henryzhao81]

I got a little concern, now we got 2 threads (one listening on requestQueue, another listening on responseQueue) running on each node. Request Queue listening-thread call onMessage() when request coming, and execute on local node, after done, send response to Response Queue. Response Queue listening-thread execute dispatchResponseToThread() when response coming, and handled in each ODistributedResponseManager by requestID. My question is only 2 threads in each node, if we sending lots of concurrent request, is it means all request will pile up, and executed sequentially? I have not do lot loading testing against latest SNAPSHOT, all based on code reading. Please correct me if i am wrong. BTW, i did not see any place in current code base using config DISTRIBUTED_THREAD_QUEUE_SIZE.