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

feat(plugins): add new plugin tasks for EventHubs (#38) #56

Merged
merged 1 commit into from
Jan 26, 2024

Conversation

fhussonnois
Copy link
Member

@fhussonnois fhussonnois commented Jan 10, 2024

This commit adds the following tasks types:

  • io.kesta.plugin.azure.messaging.eventhubs.Produce
  • io.kesta.plugin.azure.messaging.eventhubs.Consume
  • io.kesta.plugin.azure.messaging.eventhubs.Trigger

What changes are being made and why?


How the changes have been QAed?


Setup Instructions

@fhussonnois fhussonnois changed the title WIP feat(plugins): add new task Produce for EventHubs (#38) WIP feat(plugins): add new plugin tasks for EventHubs (#38) Jan 10, 2024
@fhussonnois fhussonnois force-pushed the feature/eventhubs-plugins branch 5 times, most recently from 8d8f63b to 7368497 Compare January 12, 2024 12:40
@anna-geller
Copy link
Member

Nice! I see you implemented functionality to consume messages from the EventHubs. Could that be implemented as a trigger in a similar fashion as we support SQS, PubSub or Kafka triggers?

@fhussonnois fhussonnois force-pushed the feature/eventhubs-plugins branch 4 times, most recently from 409db3d to 72540c3 Compare January 12, 2024 14:51
Copy link
Member

@loicmathieu loicmathieu left a comment

Choose a reason for hiding this comment

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

Didn't look everything but there is a lot of interfaces/asbtract classes that are only implemented once, it would be great to remove them to avoid too many classes if they are not that much important.

Also, we have some package naming convention, please move all your classes from io.kestra.plugin.azure.messaging.eventhubs to io.kestra.plugin.azure.eventhubs;.

io.kestra.plugin.azure id the Azure group of plugins and io.kestra.plugin.azure.eventhubs the subgroup of plugins, we didn't use anymore hierarchy and as the FQCN of the task is used it's important not to have too long packages.

build.gradle Outdated Show resolved Hide resolved
Comment on lines 123 to 134
InputStream is = null;
if (this.getFrom() instanceof String data) {
is = reader.read(data);
}

if (this.getFrom() instanceof Map data) {
is = reader.read(data);
}

if (this.getFrom() instanceof List data) {
is = reader.read(data);
}
Copy link
Member

Choose a reason for hiding this comment

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

We usually produce one message by 'line' as we handle data in micro-batch.
If it's a List: one message by element.
If it's a Map, we considered it is an object so a single message.
If it's a String, we consider it is an ION file so one message by line. In this case you should use the FileSerde.read() to read lines and read it in a reactive manner to avoid mounting everything in memory in case the file is big.
You can have a look at an example here: https://github.com/kestra-io/plugin-aws/blob/master/src/main/java/io/kestra/plugin/aws/sns/Publish.java#L68

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, basically the InputDataReader is only responsible for providing an IntputStream of ION file whatever the type of input.
Then the EventHubProducerService uses a reactive approach to read that file and produce one event per line.

@fhussonnois fhussonnois force-pushed the feature/eventhubs-plugins branch 6 times, most recently from ad0096a to 7668250 Compare January 17, 2024 20:06
Copy link
Member

@loicmathieu loicmathieu left a comment

Choose a reason for hiding this comment

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

Two important points:

  • All plugin properties must be annotated with @PluginProperty even if not setting any attributes or they will not be properly documented.
  • All logs are stored in database even if not displayed on the UI so you must restrict for too much logging. I think you can remove some logs

Speaking of logs, you sometimes use if(log.isLevelEnabled) but we're using SLF4J that didn't instanciate strings if the level is not enabled so unless you're competing an expansive parameter you should not do that.


Map<EventHubNamePartition, Integer> result = service.poll(
consumerContext,
new EventHubConsumerService.EventProcessorListener() {
Copy link
Member

Choose a reason for hiding this comment

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

This seems overly complicated to use a listener.
Can't we do without it? After all, the service can return the URI and that it.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, it's perfectly possible to do things differently, but I'm not sure it will be any simpler than it already is. The listener allows to only have to look to the task to understand how events are captured and stored without the need to digging into the consumer polling loop.

@fhussonnois fhussonnois force-pushed the feature/eventhubs-plugins branch 4 times, most recently from a8f5ddc to ca6b7cf Compare January 19, 2024 09:16
Copy link
Member

@loicmathieu loicmathieu left a comment

Choose a reason for hiding this comment

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

LGTM, I spotted some missing @PluginProperty please add the before merging.

@SuperBuilder
@Getter
@NoArgsConstructor
public class Produce extends AbstractEventHubTask implements RunnableTask<Produce.Output> {
Copy link
Member

Choose a reason for hiding this comment

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

It's missing some @PluginProperty

@fhussonnois fhussonnois force-pushed the feature/eventhubs-plugins branch from ca6b7cf to b86c976 Compare January 19, 2024 10:17
This commit adds the following tasks types:
* io.kesta.plugin.azure.messaging.eventhubs.Produce
* io.kesta.plugin.azure.messaging.eventhubs.Consume
* io.kesta.plugin.azure.messaging.eventhubs.Trigger
@fhussonnois fhussonnois force-pushed the feature/eventhubs-plugins branch from b86c976 to 9426b80 Compare January 26, 2024 14:29
@fhussonnois fhussonnois changed the title WIP feat(plugins): add new plugin tasks for EventHubs (#38) feat(plugins): add new plugin tasks for EventHubs (#38) Jan 26, 2024
@fhussonnois fhussonnois merged commit 09fb9b6 into kestra-io:master Jan 26, 2024
1 check failed
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