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

Ping/ponging opt-in feature at the controller level #5

Open
zkao opened this issue Jun 22, 2022 · 8 comments
Open

Ping/ponging opt-in feature at the controller level #5

zkao opened this issue Jun 22, 2022 · 8 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@zkao
Copy link

zkao commented Jun 22, 2022

We hit this logged error when testing whether a service is online, discussion here, in case it is not. It would be good to have a function for that that doesn't log, so that the broker can test whether other services are up and running.

@zkao
Copy link
Author

zkao commented Jun 22, 2022

The actual error is: service is offline or not responding

@dr-orlovsky dr-orlovsky added enhancement New feature or request question Further information is requested labels Jun 22, 2022
@dr-orlovsky
Copy link
Member

I am afraid ZMQ architecture / protocol design prevents us from doing that. The whole idea of ZMQ sockets is to be automatically re-connectable, i.e. services are allowed to be offline. The only way to test connectivity is to send a message to the other service. Probably we will need some sort of ping/pong workflow internally in the library for that...

@zkao
Copy link
Author

zkao commented Jun 22, 2022

The only way to test connectivity is to send a message to the other service.

Correct

Probably we will need some sort of ping/pong workflow internally in the library for that...

Not sure a ping/pong is needed. Just a on-demand way to send message to another service that doesn't log errors.

@zkao
Copy link
Author

zkao commented Jun 22, 2022

something like this, its copy/paste/modify from send_to function

impl<A> Endpoint<A>
where
    A: ServiceAddress,
{
    pub(self) fn dest_up(&mut self, source: A, dest: A) -> bool {
        // what to put as data, and how to handle receiving it?
        let data = vec![];
        let router = match self.router {
            None => {
                trace!("Sending {} from {} to {} directly", request, source, dest,);
                dest.clone()
            }
            Some(ref router) if &source == router => {
                trace!("Routing {} from {} to {}", request, source, dest,);
                dest.clone()
            }
            Some(ref router) => {
                trace!("Sending {} from {} to {} via router {}", request, source, dest, router,);
                router.clone()
            }
        };
        let src = source.clone();
        let dst = dest.clone();
        match self.session.send_routed_message(&source.into(), &router.into(), &dest.into(), &data)
        {
            Ok(()) => true,
            _ => false,
        }
    }
}

@dr-orlovsky
Copy link
Member

Sorry, I am not getting. Is the logging a problem? If yes, it can be controlled in a standard way with [env_logger](https://docs.rs/env_logger/0.9.0/env_logger/) crate by setting filters via environment variables

@zkao
Copy link
Author

zkao commented Jun 27, 2022

I find the requested feature questionable. The intend was to distinguish between normal error logging, and add the ability to probe for services online by some sort of microservice manager, for example, without logging (this was a concern from another contributor).

I will describe the actual problem.

  1. service A suspects service B is down
  2. so A probes B to see if it is up by sending a msg
    3a. A detects B is down, and relaunch it
    3b. or A detects B is up, and do nothing

the fn above dest_up probes whether service dest is up, and returns a bool.

@zkao zkao closed this as completed Jun 27, 2022
@zkao zkao closed this as not planned Won't fix, can't repro, duplicate, stale Jun 27, 2022
@dr-orlovsky
Copy link
Member

If you will send just an message like in the dest_up fn, it will be a failure on the receiving part since it won't be aple to parse it. So the real way of doing that is ping/ponging, and probably proper way of implementation would be make ping/ponging opt-in feature at the controller level, such that controller will call some Handler dedicated callback and the managing daemon will be able to re-launch failed service. I will work on that, but feel free to do the PR if you'd like.

I think we can leave the issue opened, just change its name

@zkao
Copy link
Author

zkao commented Jun 28, 2022

I will work on that, but feel free to do the PR if you'd like.

Please go ahead, you know exactly how to integrate it in the larger framework :)

@zkao zkao changed the title Test whether a microservice is online in the ESB Ping/ponging opt-in feature at the controller level Jun 28, 2022
@zkao zkao reopened this Jun 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants