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

Question about PULL PUSH and module overall #2

Open
funny-falcon opened this issue Mar 19, 2012 · 7 comments
Open

Question about PULL PUSH and module overall #2

funny-falcon opened this issue Mar 19, 2012 · 7 comments

Comments

@funny-falcon
Copy link

Good day.

First of all, excuse me for asking the question instead of reading sources.

  1. Are zmq sockets integrated to nginx event loop? I believe so, but still want to get definite answer
  2. Could you provide example config where both PUSH and PULL configured for upstream?
    1. Will nginx will detect message incoming to PULL socket as an answer for message sent into PUSH socket? How does he do it if so?
    2. Which way client should determine address of PULL socket configured in Nginx?

With respect,
Yura

@deepfryed
Copy link

I have not looked at the PULL/PUSH mechanism in this code yet but I don't see a way for it to work other than maintain connection identity in the request and response headers to and from the upstream worker.

browser ------> nginx zmq --- [connection id: 1] --- [PULL] ---> worker
                   ^                                              |
                   |                                              |
                   +--------- [connection id: 1] --- [PUSH] ------+

@funny-falcon
Copy link
Author

@deepfryed , I agree with you, more over: we ought to pass nginx's PULL socket address if we wish one worker to serve several nginx

@deepfryed
Copy link

sounds like over-engineering - i'd rather put a load balancer in the middle instead

@PiotrSikora
Copy link
Contributor

Hi guys,
sorry for the late reply.

Are zmq sockets integrated to nginx event loop? I believe so, but still want to get definite answer.

Yes.

Could you provide example config where both PUSH and PULL configured for upstream?

upstream {
    zeromq_remote PUSH 127.0.0.1:10000;
    zeromq_local  PULL 127.0.0.1:*;
}

Will nginx will detect message incoming to PULL socket as an answer for message sent into PUSH socket? How does he do it if so?

For now, all sockets are transient per-request, so there is no problem with that.

This will obviously change (it's still very much work in progress) and then you will need to pass identification header that came with the request.

Which way client should determine address of PULL socket configured in Nginx?

There is X-ZeroMQ-RespondTo header in the request, which contains that information.

sounds like over-engineering - i'd rather put a load balancer in the middle instead

For simple request/response - agreed, but that's not the point of this module.

@funny-falcon
Copy link
Author

@PiotrSikora, it sounds very promising :) Will take an eye on this project

This will obviously change (it's still very much work in progress) and then you will need to pass identification header that came with the request.

Then there could be bound PULL socket and connected-to-many PUSH socket - simple load balancer with fail tolerance enabled :) - had I got the idea?

@deepfryed
Copy link

@PiotrSikora re. over-engineering, i meant the single worker serving multiple nginx instances workflow.

@funny-falcon
Copy link
Author

@PiotrSikora re. over-engineering, i meant the single worker serving multiple nginx instances workflow.

@deepfryed, I'm thinking about multiple workers serving multiple nginx instances, so that fail of any worker or fail of any nginx doesn't break the whole thing. Any nginx's request will PULLed by any alive worker using balancing property of PUSH-PULL chain, and worker will PUSH reply, marked by request handle, to nginx's PULL socket, which address also will be encoded in a request.

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

3 participants