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

[]byte vs io.Reader for message contents #500

Open
markus-wa opened this issue Sep 15, 2020 · 6 comments
Open

[]byte vs io.Reader for message contents #500

markus-wa opened this issue Sep 15, 2020 · 6 comments

Comments

@markus-wa
Copy link
Contributor

markus-wa commented Sep 15, 2020

Hey @Jeffail

First of all, this looks like an awesome project, thanks for building this!

I was wondering if Benthos should support io.Reader in the future for large message contents.
This could be useful for sources with large files (S3. files, etc.), where reading the whole content in at once is not desirable.

I realise this might be a rather large change and if it's not in the scope of the project to support this that is perfectly understandable.

Edit: This would probably only be useful for plugins(?)

@Jeffail
Copy link
Collaborator

Jeffail commented Sep 15, 2020

Hey @markus-wa, this is definitely possible and probably not too much effort since things like structured parsing to/from JSON is already lazily evaluated, so we could expand that concept to include byte consumption being lazily read and offer the io.Reader interface as an advanced API.

However, this will need to wait for a major version bump as it'd definitely involve chopping and restructuring some of the fundamental component APIs. I'm currently in the loose planning phase for a new plugin API (just created a ticket for it) that would start the ball rolling on Benthos V4. Once that's done we can take a look at this and weigh in the pros/cons and think about how the APIs should look.

@markus-wa
Copy link
Contributor Author

Cool, I'd be happy to help out (if I have the time for it). Feel free to give me a ping here whenever you think this is ready to be designed / worked on 🙂

@dilipkk-foyernet
Copy link
Contributor

dilipkk-foyernet commented Sep 16, 2020

Yes, it makes sense to have "io.Reader" exposed else, @Jeffail is it possible to provide configuration options like reading line by line or number of bytes to be read at once, and based on that we can emit one or more messages. I feel this way we don't need to change API drastically, I am still understanding this library so my understanding might be incomplete. Please forgive me in case this is misunderstood.

@nicktelford
Copy link
Contributor

We've been having a problem processing large, compressed batches of messages from S3. Benthos tries to read in and decompress the entire file before processing any of the messages.

I believe switching to io.Reader should enable Benthos to process these files incrementally, including both reading and decompressing.

This is a high priority for us.

@Jeffail
Copy link
Collaborator

Jeffail commented Nov 19, 2020

Just realised that I forgot to update this issue, but as a short term measure I've added a new codec field to a few file-based inputs, which currently includes file as well as the new aws_s3 which will eventually replace s3. These codecs are currently quite limited (line-by-line, tar archives, and csv) but the interface is fairly straight forward to implement so I'm hoping I'll be able to keep on top of any requests for new codecs coming in.

The long term plan is to gradually expand codecs and eventually, once we're happy that their common interface is stable, I will allow you to add codec plugins the same way processor and other plugins are possible now, which would allow you to build custom definitions for how an io.Reader can be streamed into benthos messages.

@markus-wa
Copy link
Contributor Author

nice one @Jeffail - thanks for the update

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants