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.

Sign up for GitHub

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

Jump to bottom

Function worker uses raw webService Port against adverisedListener and advertisedAddress #10951

Closed
abhilashmandaliya opened this issue Jun 17, 2021 · 5 comments · Fixed by #10961
Closed

Function worker uses raw webService Port against adverisedListener and advertisedAddress #10951

abhilashmandaliya opened this issue Jun 17, 2021 · 5 comments · Fixed by #10961
Labels
type/bug The PR fixed a bug or issue reported a bug

Comments

@abhilashmandaliya
Copy link
Contributor

abhilashmandaliya commented Jun 17, 2021 •
edited
Loading

Describe the bug
I am running Pulsar broker on docker and trying to run function worker as part of the broker. My advertisedListener IP is the IP of my host machine and I have a mapped worker port as well. But here, we are calling getAppliedAdvertisedAddress which returns my advertisedListner address and we are using the raw webServicePort against it. That code is 2 lines above. So it is forming a weird address advertisedAddress:webServicePort (hostMachineIP:dockerContainerPort) which is not allowing function workers to start. This has broken from Pulsar 2.8.0.

To Reproduce
Steps to reproduce the behavior:

  1. Run any of the sink connectors in the broker.
  2. Configure advertisedListner with the address that is different from the address where the broker is running.

Expected behavior
There should be consistency in address formation. Either we should use advertisedListner/advertisedAddress with its port or we should use both raw broker address and raw webServicePort.
@abhilashmandaliya abhilashmandaliya added the type/bug The PR fixed a bug or issue reported a bug label Jun 17, 2021
@abhilashmandaliya
Copy link
Contributor Author

abhilashmandaliya commented Jun 17, 2021 •
edited
Loading

the same thing has happened with the broker address here. my health check is failing because of this.
Seems like commit [#10312] has caused this.

@sijie sijie mentioned this issue Jun 17, 2021
Closed
@lhotari
Copy link
Member

lhotari commented Jun 17, 2021

@315157973 Would you mind checking this?

@315157973
Copy link
Contributor

Now the order of address acquisition is advertisedAddress, then advertisedListner, then hostname.
The problem now is that the address does not correspond to the port, right? @abhilashmandaliya

@315157973 315157973 mentioned this issue Jun 17, 2021
Merged
@abhilashmandaliya
Copy link
Contributor Author

Now the order of address acquisition is advertisedAddress, then advertisedListner, then hostname.
The problem now is that the address does not correspond to the port, right? @abhilashmandaliya

@315157973 yes. that's correct.

sijie pushed a commit that referenced this issue Jun 22, 2021
@315157973
Fix incorrect port of advertisedListener (#10961)
99c84c4 
Fixes #10951

### Motivation
The advertisedListener has its own port, and now we have no way to obtain the port of TLS and non-TLS advertisedListener except by setting the listenerName through the client.
Therefore, brokerServiceUrl and webServiceUrl do not return the address and port of the advertisedListener
yangl pushed a commit to yangl/pulsar that referenced this issue Jun 23, 2021
@315157973 @yangl
Fix incorrect port of advertisedListener (apache#10961)
ca705ee 
Fixes apache#10951

### Motivation
The advertisedListener has its own port, and now we have no way to obtain the port of TLS and non-TLS advertisedListener except by setting the listenerName through the client.
Therefore, brokerServiceUrl and webServiceUrl do not return the address and port of the advertisedListener
codelipenghui pushed a commit that referenced this issue Jun 25, 2021
@315157973 @codelipenghui
Fix incorrect port of advertisedListener (#10961)
d7bff1e 
Fixes #10951

### Motivation
The advertisedListener has its own port, and now we have no way to obtain the port of TLS and non-TLS advertisedListener except by setting the listenerName through the client.
Therefore, brokerServiceUrl and webServiceUrl do not return the address and port of the advertisedListener


(cherry picked from commit 99c84c4)
@EronWright
Copy link
Contributor

EronWright commented Sep 7, 2021 •
edited
Loading

I believe that the root cause is that Pulsar is erroneously using the configured advertisedListeners to formulate the web service endpoint in some cases. A reasonable fix would be to use only advertisedAddress:webServicePort for that purpose, and allow advertisedListeners to also be configured for the broker service endpoint.

@EronWright EronWright mentioned this issue Oct 13, 2021
Merged
2 tasks
bharanic-dev pushed a commit to bharanic-dev/pulsar that referenced this issue Mar 18, 2022
@315157973 @ciaocloud
Fix incorrect port of advertisedListener (apache#10961)
eb0b319 
Fixes apache#10951

### Motivation
The advertisedListener has its own port, and now we have no way to obtain the port of TLS and non-TLS advertisedListener except by setting the listenerName through the client.
Therefore, brokerServiceUrl and webServiceUrl do not return the address and port of the advertisedListener
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type/bug The PR fixed a bug or issue reported a bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix incorrect port of advertisedListener 315157973/pulsar
4 participants
@lhotari @EronWright @315157973 @abhilashmandaliya