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

Muontrap.Daemon Proposal #30

Open
alde103 opened this issue May 26, 2021 · 8 comments
Open

Muontrap.Daemon Proposal #30

alde103 opened this issue May 26, 2021 · 8 comments

Comments

@alde103
Copy link
Contributor

alde103 commented May 26, 2021

Hello,

Would you be interested in a new feature for Muontrap.Daemon?, the idea is not only to log the messages generated by the OS process supervised by Muontrap.Daemon, but to add the ability to send them to the parent process for further processing.

Greetings.

@fhunleth
Copy link
Owner

Hi @alde103 - That seems like a good feature to add. Perhaps it's a configuration key that specifies a callback and the default callback is to log the message. For your use case, you'd pass a function that sends a message. What do you think of that?

@thdxr
Copy link

thdxr commented May 30, 2021

I'm interested in this as well! Was thinking about hacking the into to pass a collectible that I implement with a callback

@fhunleth
Copy link
Owner

Adding an :into option to MuonTrap.Daemon.start_link sounds like a really good idea.

@alde103
Copy link
Contributor Author

alde103 commented May 30, 2021

Hi all,

@fhunleth, Which one do you like best?

  • Use the using macro with the whole @callback ceremony (the default callback would be logging it).
  • Use a key (:into) in the state for the callback function (anonymous function) that is called every time there is a new message (default the log function).

@alde103
Copy link
Contributor Author

alde103 commented Jun 3, 2021

Hi @fhunleth, Would you be interested in Muontrap.Daemon.Server??, it would be a module that implements a behaviour that wraps MuonTrap.Daemon for handling daemon messages with GenServer's states.

@fhunleth
Copy link
Owner

fhunleth commented Jun 5, 2021

I'm not sure about Muontrap.Daemon.Server. It feels like there should be other ways of accomplishing the same thing that require significantly less code:

  1. Create your own GenServer that runs the muontrap port binary like Muontrap.Daemon, but has your custom code.
  2. Have Muontrap.Daemon emit telemetry events and attach to those. I feel like we're exploring that the PR. I'm also exploring this in another library and will hopefully have stronger opinions on :telemetry soon.
  3. Write a GenServer to monitor your Muontrap.Daemon GenServer that you want to run some code when it exits.

Could you talk about your use case? Perhaps that will help me understand better.

@alde103
Copy link
Contributor Author

alde103 commented Jun 5, 2021

In short, my application will run a configurable number of unspecified daemons (configurable at runtime), whose logs/outputs will be processed based on runtime configurable Regex and are propagated to the rest of the application.

And as you mention, my current approach is to use (1) but I think some features of MuonTrap.Daemon are desirable to make the application more scalable.

Also, I would like to reduce the ceremonial code to the final user, which is one of Muontrap.Daemon.Server purposes.

Muontrap.Daemon.Server could be restructured so that instead of relying on direct messages from MuonTrap.Daemon, it would use telemetry events.

@recursiveGecko
Copy link

Hi, I was recommended this project today (which is great!) but I also ran into this limitation.

I don't know if anything has changed since this discussion, but could this be solved by supplying an optional log_fn/1 to the Daemon? This would allow us to add custom log-processing logic in a relatively straightforward way.

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

No branches or pull requests

4 participants