You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We deployed an instance of pushpin on our kubernetes cluster with hint and poll for pushing data down SSE streams. We observed that, after a hint, it's going to send a recover request for each client connected. We know that pushpin aggregates/reuse requests on proxy level using sharing-key. However, it's only happening in kubernetes deployment, not with local docker container. It could also happen on local with docker's kubernetes enabled (not 100% sure about this).
After digging deeper, we see that the difference is in inspect not available log from proxy. We also see the ordering of logs is different. The proxy determines inspect not available before a zrpc sends and receives sharing-key.
The first "batch" of proxy request is going to have inspect not available for each request after a hint. Subsequent "batches" reuses proxy sessions as expected.
This happens on 1.38.0. We reverted to use 1.34.0 (that has zurl) and no longer sees this behavior (didn't test out 1.35.0, 1.36.0, or 1.37.0).
The log below has 4 clients connected to pushpin with param max_open_sessions=2. It is showing the first "batch" of recovery requests for 2 clients.
We see the proxy determines inspect not available and creating proxysession before it receives sharing-key from zrpc server, which seems to be the wrong order.
Hi Justin,
Yes, only for next link fetches. And only after hint. The initial large response on new connections with Grip-Link works fine and reuses proxy sessions as well.
Also just tested with 1.37.0 and that seems to work as well.
I was able to reproduce this. It seems the issue has to do with external routing (when the scheme/domain of the next link is different than that of the original request) rather than pushpin version, although it is possible older versions may have slightly different behavior. Maybe the links differ in your environments.
In any case, this does look like a bug, and will be fixed in the next version very soon.
Hello!
We deployed an instance of pushpin on our kubernetes cluster with hint and poll for pushing data down SSE streams. We observed that, after a hint, it's going to send a recover request for each client connected. We know that pushpin aggregates/reuse requests on proxy level using
sharing-key
. However, it's only happening in kubernetes deployment, not with local docker container. It could also happen on local with docker's kubernetes enabled (not 100% sure about this).After digging deeper, we see that the difference is in
inspect not available
log from proxy. We also see the ordering of logs is different. The proxy determinesinspect not available
before a zrpc sends and receivessharing-key
.The first "batch" of proxy request is going to have
inspect not available
for each request after a hint. Subsequent "batches" reuses proxy sessions as expected.This happens on
1.38.0
. We reverted to use1.34.0
(that has zurl) and no longer sees this behavior (didn't test out 1.35.0, 1.36.0, or 1.37.0).The log below has 4 clients connected to pushpin with param
max_open_sessions=2
. It is showing the first "batch" of recovery requests for 2 clients.We see the proxy determines
inspect not available
andcreating proxysession
before it receivessharing-key
from zrpc server, which seems to be the wrong order.The log below shows the right ordering. First fetch inspect data, then do proxy with the sharing-key available.
Thanks!
The text was updated successfully, but these errors were encountered: