Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

plocal support for distributed databases #1615

Closed
lvca opened this issue Aug 13, 2013 · 5 comments
Closed

plocal support for distributed databases #1615

lvca opened this issue Aug 13, 2013 · 5 comments
Assignees
Milestone

Comments

@lvca
Copy link
Member

lvca commented Aug 13, 2013

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);
          }
        }
@ghost ghost assigned laa Aug 13, 2013
@mattaylor
Copy link
Contributor

Any idea if this is going to be fixed soon?

@laa
Copy link
Member

laa commented Oct 9, 2013

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
Copy link
Member Author

lvca commented Oct 9, 2013

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

@lvca lvca closed this as completed Oct 9, 2013
@mattaylor
Copy link
Contributor

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
Copy link
Member Author

lvca commented Oct 9, 2013

Can you retry with last snapshot please?

@henryzhao81
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants