You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rather than have the tail offset which is incremented on publication claim be the byte offset in the term it can be the number of frame alignments, currently 32-byte alignment, so that it gives a greater margin for error if many concurrent threads where to pass pass under the publication limit at exactly the same time to increment the tail and cause overflow.
For the publication to fail currently it would take 192 threads to be at the same point and term buffers to be 1GB length, with each claiming the maximum 16MB message length, for overflow to happen. Each division of the term length by 2 doubles the number of threads required for overflow at maximum message length.
The text was updated successfully, but these errors were encountered:
Sounds a bit like compressed oops, based on a similar observation on alignment, and with a similar (minor) overhead of "uncompressing" the offset. Cool idea :)
Rather than have the tail offset which is incremented on publication claim be the byte offset in the term it can be the number of frame alignments, currently 32-byte alignment, so that it gives a greater margin for error if many concurrent threads where to pass pass under the publication limit at exactly the same time to increment the tail and cause overflow.
For the publication to fail currently it would take 192 threads to be at the same point and term buffers to be 1GB length, with each claiming the maximum 16MB message length, for overflow to happen. Each division of the term length by 2 doubles the number of threads required for overflow at maximum message length.
The text was updated successfully, but these errors were encountered: