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

Failing event deserialization test #52

Merged
merged 1 commit into from Jul 4, 2017
Merged

Conversation

zbartos
Copy link
Contributor

@zbartos zbartos commented Jul 4, 2017

We've an issue with some particular serialized events and metadata.

The metadata attached as well as two serialized events so the test emulates real case... BtdbMissingMetadataException thrown for second event although it shouldn't.

@Bobris Bobris merged commit 531e433 into Bobris:master Jul 4, 2017
@Bobris
Copy link
Owner

Bobris commented Jul 4, 2017

61 at beggining means type DiskInfoAdded. First field is List so next number is number of items + 1. Clearly 62 is totally wrong. So we have to find out how this was created in first place.

@zbartos
Copy link
Contributor Author

zbartos commented Jul 4, 2017

So does it mean that event serialized bytes are wrong by itself (metadata independent)? It's very hard to find out how it was created because data were produced by three QA guys installation and I guess nobody knows what they really did... There was three-nodes cluster but another back-end services were running there too. Kafka request log was by default turned off. Despite of that we think that events and corresponding metadata should be produced info Kafka correctly even in case of more back-end services...

@Bobris
Copy link
Owner

Bobris commented Jul 4, 2017

Yes this is just corrupted no problem in metadata. Will try later to skip first 61 and start directly with 62.

@Bobris
Copy link
Owner

Bobris commented Jul 4, 2017

Hmm 62 is "type" of first field, the List<DbDriveInfo>. But that's wrong because List should be always written as inline. It does not look like corruption, there is probably some mistake, but we need to reproduce.

@Bobris
Copy link
Owner

Bobris commented Jul 4, 2017

It would be interesting to have all such events starting 61 and as second byte something else than 4.

@zbartos
Copy link
Contributor Author

zbartos commented Jul 7, 2017

I've extracted required test data (all events starting 61 and as second byte something else than 4) from the Kafka topic and created pull request. Later I've seen in QA guys provided log files that another back-end services were older versions. But I don't know whether they directed them to this Kafka or another Kafka instance, mess in that... I guess it's possible that older back-end fed events into this Kafka topics, newer back-end started then..., perhaps could it cause the issue?

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

Successfully merging this pull request may close these issues.

None yet

2 participants