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

Upgrade azure-eventhub input to the modern Event Hub SDK #1

Closed
wants to merge 41 commits into from

Conversation

zmoog
Copy link
Owner

@zmoog zmoog commented May 20, 2024

Proposed commit message

Checklist

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have made corresponding change to the default configuration files
  • I have added tests that prove my fix is effective or that my feature works
  • I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Disruptive User Impact

Author's Checklist

  • [ ]

How to test this PR locally

Related issues

Use cases

Screenshots

Logs

@zmoog zmoog self-assigned this May 21, 2024
zmoog and others added 7 commits May 21, 2024 13:31
The existing input version does not handle publishing acks from the
Beats pipeline. The input API v1 does not seem to offer this feature.

With the transition to the input API v2, we have acks management.
However, the legacy event hub SDK internally updates the checkpoint
info after a successful handler call, and does not seem to offer hooks
for acks management.

Since the new modern SDK offers better checkpoint management, we keep
the current behavior intact, and we'll implement ACKs in the
event hub input v2.
Co-authored-by: Tiago Queiroz <me@tiago.life>
zmoog added 12 commits June 4, 2024 17:50
Alongside the partition ID, users can optional send event with a
partition key.

Add an (optional) partition key to the event hub metadata.
The new migrate_checkpoint config option controls if the input v2
should perform a migration check on start.

If migrate_checkpoint is true, the input checks and performs the
migration (if v1 info exists) on the very first v2 run.

If migrate_checkpoint is false, the input will skip the migration
assistant and will not perform any checks or migration.
Expand processor options by adding a new `start_position`
configuration.

Possible values for `start_position` are:

- "earliest" to start from the beginning of the event hub retention
  period.
- "latest" to start from new events.

The input uses the 'start_position' option when checkpoint information
from the storage account container is unavailable (on the input's
first start).
Makes the receive configuration settings available for customization
on the input settings.

The current default values (receive_timeout: 5s, receive_count: 100)
are probably fine, but it is better to make these options available
to users.
@zmoog zmoog force-pushed the zmoog/azure-eventhub-sdk-upgrade branch from 9ca5a04 to bca6e63 Compare June 4, 2024 16:03
@zmoog
Copy link
Owner Author

zmoog commented Jun 4, 2024

Replaced by elastic#39796 in the upstream repo.

@zmoog zmoog closed this Jun 4, 2024
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.

1 participant