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

Release 1.4.0 #232

Merged
merged 1 commit into from
May 20, 2024
Merged

Release 1.4.0 #232

merged 1 commit into from
May 20, 2024

Conversation

oleg-jukovec
Copy link
Collaborator

The release introduces an experimental storage_mode option for the utube and utubettl drivers with the memtx engine. It could be used to create a utube or utubettl queue with an additional buffer space that stores only ready to take tasks.

local tube = queue.create_tube('utube_with_ready_buffer', 'utube',
    {storage_mode = queue.driver.utube.STORAGE_MODE_READY_BUFFER})
local tube = queue.create_tube('utubettl_with_ready_buffer', 'utubettl',
    {storage_mode = queue.driver.utubettl.STORAGE_MODE_READY_BUFFER})

The storage mode slower in general cases, but a much faster in cases when you have utubes with many tasks (see README.md for the performance comparison). So you should make your choice carefully.

Added

  • Experimental storage_mode option for creating a utube and utubettl tube (utubettl: slow take #228). It enables the workaround for slow takes while working with busy tubes.

Fixed

  • Stuck in INIT state if an instance failed to enter the running mode in time (queue stuck in INIT state on tarantool 3 #226). This fix works only for Tarantool versions >= 2.10.0.
  • Slow takes on busy utube and utubettl tubes (utubettl: slow take #228). The workaround could be enabled by passing the storage_mode = "ready_buffer" option while creating the tube.

@DifferentialOrange
Copy link
Member

Isn't it more like 1.4.0?

@oleg-jukovec
Copy link
Collaborator Author

https://semver.org/spec/v2.0.0.html

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

It seems we need 1.4.0.

@oleg-jukovec oleg-jukovec force-pushed the oleg-jukovec/release-1.3.4 branch from 5c8bdd6 to 0554f13 Compare May 20, 2024 07:31
@oleg-jukovec oleg-jukovec changed the title Release 1.3.4 Release 1.4.0 May 20, 2024
@oleg-jukovec
Copy link
Collaborator Author

Isn't it more like 1.4.0?

Thank you, updated.

@oleg-jukovec oleg-jukovec force-pushed the oleg-jukovec/release-1.3.4 branch from 0554f13 to bf1e093 Compare May 20, 2024 07:33
@oleg-jukovec oleg-jukovec merged commit f6c0770 into master May 20, 2024
23 checks passed
@oleg-jukovec oleg-jukovec deleted the oleg-jukovec/release-1.3.4 branch May 20, 2024 09:14
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.

3 participants