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

replication log commit failure #172

Open
imzhenyu opened this issue Jan 7, 2016 · 3 comments
Open

replication log commit failure #172

imzhenyu opened this issue Jan 7, 2016 · 3 comments
Labels

Comments

@imzhenyu
Copy link
Owner

imzhenyu commented Jan 7, 2016

dassert(false, "cannot find handler for rpc code %d in %s", code, data_dir().c_str());

in replication_app_base::dispatch_rpc_call.

The root cause is that we store the rpc code as integers in logs. After code change, i.e., more task codes are introduced in this case, the same integer is not mapped to the same rpc string code anymore. Need to be fixed next.

@imzhenyu imzhenyu added the bug label Jan 7, 2016
@imzhenyu imzhenyu changed the title log replication execution failure replication log commit failure Jan 7, 2016
@imzhenyu
Copy link
Owner Author

imzhenyu commented Jan 8, 2016

the fix is still incomplete - the client may have different versions of code compared to the servers, in which case we need to have all task code transmitted as string instead of integers.

@qinzuoyan
Copy link
Collaborator

the above problem is now deal in another issue #180.
close this issue now.

@imzhenyu
Copy link
Owner Author

@qinzuoyan this case is a little bit different compared to error code. Currently for the case of replicated read/write, the task code is embedded as part of the msg body using intergers. There are two ways to fix: (1) change int to string in the msg body - which is a quick way to do; (2) change msg header rpc string to this task code string directly, and using context flags to identify this is a replicated read/write - this is going to be done in later refactoring of the whole 2nd layer. In both cases, the fixes will be different compared to the error code stuff. Consequently, I'm reopening the case.

@imzhenyu imzhenyu reopened this Jan 11, 2016
imzhenyu added a commit that referenced this issue Sep 14, 2016
enhancement in linux deployment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants