Skip to content

Fix compression timestamps#759

Merged
eapache merged 4 commits into
IBM:masterfrom
rtreffer:fix-compression-timestamps
Oct 6, 2016
Merged

Fix compression timestamps#759
eapache merged 4 commits into
IBM:masterfrom
rtreffer:fix-compression-timestamps

Conversation

@rtreffer

@rtreffer rtreffer commented Oct 5, 2016

Copy link
Copy Markdown
Contributor

The wrapper message has to use the "new" format if the compressed messages use it as well.
This will fix #757 #758

@eapache eapache left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this! I believe your logic is correct but it feels a bit complicated.

Per my inline comment, I think it might be better to always use v1 messages if the version supports it, and set the timestamp to time.Now() if the user does not provide one. This should avoid the need to loop over all the messages to determine the correct outer protocol version, plus it provides a sane default for the timestamp.

Comment thread produce_set.go Outdated
}
if ps.parent.conf.Version.IsAtLeast(V0_10_0_0) {
// Compressed messages must use a protocol version
// that is newer than the inner messages version.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor nit-pick: as I understand it (and as you've implemented here) the outer version has to be at least as new as the inner version, not strictly newer.

Comment thread produce_set.go Outdated
for _, msgBlock := range set.setToSend.Messages {
msg := msgBlock.Msg
if msg.Version > compMsg.Version {
compMsg.Version = msg.Version

@eapache eapache Oct 5, 2016

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I was thinking about better ways to accomplish this and I wonder now if the code in produceSet#add is even correct; is it safe to mix v0 and v1 messages in a single compressed batch which we'll do right now if some timestamps are 0? Or should we change to just always using v1 if the version supports it, and let the timestamps be 0 if necessary?

edit: actually this issue goes away if we provide a timestamp of time.Now() by default if you leave the timestamp as 0, which we should probably do for convenience anyway

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think always using v1 would be great, I don't see a reason to switch back at all. Providing a default of time.Now() sounds like a good idea, too.

@rtreffer

rtreffer commented Oct 6, 2016

Copy link
Copy Markdown
Contributor Author

@eapache how about the updated version? Pushing message version 1 if possible and default timestamp of time.Now if unspecified?

Comment thread produce_set.go Outdated
}
if ps.parent.conf.Version.IsAtLeast(V0_10_0_0) {
compMsg.Version = 1
compMsg.Timestamp = time.Now()

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be set.setToSend.Messages[0].Msg.Timestamp so the outer message timestamp is approximately correct if the user provides custom timestamps for the inner messages?

@eapache

eapache commented Oct 6, 2016

Copy link
Copy Markdown
Contributor

Definitely like this version better, thanks for adjusting it. Just one minor comment.

The first messages timestamp of a set is a proxy for the actual
timestamp of the group in many cases.
@rtreffer

rtreffer commented Oct 6, 2016

Copy link
Copy Markdown
Contributor Author

@eapache you are right, the first timestamp would usually be a good proxy for the timestamp of the group.

I've updated the PR, I guess it needs a squash but github can do that on merge anyway.

@eapache eapache merged commit 133322f into IBM:master Oct 6, 2016
@eapache

eapache commented Oct 6, 2016

Copy link
Copy Markdown
Contributor

Thanks!

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.

Can't produce compressed messages with timestamp

3 participants