[meta] Status of this project?

[riazarbi]

Hello,

Could the maintainers of this repository provide some clarity on the status of this project? It's a great jupyterhub component that many of us find useful, but I'm starting to get nervous that it has been abandoned.

For instance, I can only get it working when I use the version on PyPi, which is not available if I build from source from this repository.

There are a few of us who have been commenting in the issues to help each other get around broken bits that crop up from time to time, but I don't think we have the skill to actually implement fixes in the code.

@ryanlovett @yuvipanda could you please give us some comment?

[ryanlovett]

Hi @riazarbi, I apologize for the lack of activity and communication. It hasn't been abandoned though it may seem that way. I haven't had as much time as I'd like to devote to it. I was hoping I'd be able to get to it this semester but there have been unforeseen tasks getting in the way. Unfortunately I can't predict when I'll revisit it though I'd like to get to it before December.

[riazarbi]

Thanks for the clarity @ryanlovett. Great, good to know. We'll keep relying on it then :)

I can't speak for everyone, but it seems to me that a big source of confusion at present it that the PyPi, Conda and GitHub source versions are out of sync.

From what I can gather, the only current version of this proxy which works with jupyter v1 is the PyPi version of jupyter-rsession-proxy which works with z2jh v0.9.*beta. Tagging the source code of the v1.0.dev0 release on this repo would go some way towards clearing up confusion. We could then sort the issues according to tagged release; some of these issues may already have been addressed between v0.8.0 and v1.0.dev0

[ryanlovett]

Hi @riazarbi, I've tagged v1.0 and uploaded to pypi.

[riazarbi]

Ok, I've triggered a rebuild of my docker image, will spin up when done and confirm all works correctly.

[riazarbi]

I've tested this in a single container and it worked fine. Then I tested it as part of a kubernetes-based jupyterhub deployment and it seemed to work - I can spin up an Rstudio session easily and write code.

BUT when I switch projects, I get a 500 internal server error. This seems to be happening inside the rstudio container. This error is not fatel. I can just refresh the url and end up in the right place - but it is jarring, and shouldn't happen.

Relevant error log from the container (I've redacted some sensitive info) -

[E 2020-03-05 11:30:42.242 SingleUserNotebookApp web:1788] Uncaught exception GET /workbench/user/rarbi/rstudio/ (10.244.4.1)

    HTTPServerRequest(protocol='http', host='REDACTED', method='GET', uri='/workbench/user/rarbi/rstudio/', version='HTTP/1.1', remote_ip='10.244.4.1')

    Traceback (most recent call last):

      File "/usr/local/lib/python3.6/dist-packages/tornado/web.py", line 1699, in _execute

        result = await result

      File "/usr/local/lib/python3.6/dist-packages/jupyter_server_proxy/websocket.py", line 96, in get

        return await self.http_get(*args, **kwargs)

      File "/usr/local/lib/python3.6/dist-packages/jupyter_server_proxy/handlers.py", line 507, in http_get

        return await self.proxy(self.port, path)

      File "/usr/local/lib/python3.6/dist-packages/jupyter_server_proxy/handlers.py", line 503, in proxy

        return await super().proxy(self.port, path)

      File "/usr/local/lib/python3.6/dist-packages/jupyter_server_proxy/handlers.py", line 213, in proxy

        response = await client.fetch(req, raise_error=False)

    tornado.simple_httpclient.HTTPStreamClosedError: Stream closed

[E 2020-03-05 11:30:42.247 SingleUserNotebookApp log:166] {

      "X-Real-Ip": "10.244.4.1",

      "X-Forwarded-Server": "traefik-ingress-controller-55bf9bb5cb-t4kcf",

      "X-Forwarded-Proto": "https,http",

      "X-Forwarded-Port": "443,80",

      "X-Forwarded-Host": "REDACTED",

      "X-Forwarded-For": "10.244.4.1,10.244.4.221",

      "Upgrade-Insecure-Requests": "1",

      "Te": "trailers",

      "Referer": "https://REDACTED/workbench/user/rarbi/rstudio/",

      "Dnt": "1",

      "Cookie": "port-token=[secret]; jupyterhub-user-rarbi=[secret]; _xsrf=[secret]; cl__cauid=[secret]; cl__caz=[secret]; cl__calts=[secret]; cl__userid=[secret]; jupyterhub-session-id=[secret]; csrf-token=[secret]; SAPWP_active=[secret]; session=[secret]; cl___cav=[secret]; cl__pts=[secret]; cl__cass=[secret]; cl_sf=[secret]; cl_lvu=[secret]; MYSAPSSO2=[secret]",

      "Accept-Language": "en-US,en;q=0.5",

      "Accept-Encoding": "gzip, deflate, br",

      "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",

      "User-Agent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0",

      "Host": "REDACTED",

      "Connection": "close"

    }

[E 2020-03-05 11:30:42.247 SingleUserNotebookApp log:174] 500 GET /workbench/user/rarbi/rstudio/ (rarbi@10.244.4.1) 4027.84ms

Listener bound to address 127.0.0.1 port 42312

[riazarbi]

Also, terminal fuctionality is broken. Turning off websockets fixes it.

[riazarbi]

Ok, @ryanlovett in the interests of trying to pitch in and help, I built a diff of the source code of the current head of this repo and the source of the last version that worked in my environment - that would be pypi version 1.0b6.

The diff can be found at the link below. Note that the red on the left is your current head, and the green on the right is the old version 1.0b6:

https://github.com/jupyterhub/jupyter-rsession-proxy/compare/master...riazarbi:master

Now, I am not a programmer by any stretch of the imagination, so I may be drawing silly conclusions. But it looks to me that the current version is using rsession and the old working version is using rserver. So I went to the pull request that kicked off this confusion - #57 - and looked at @yuvipanda 's init_py and it looks a lot like the source code of pypi v 1.0b6:

https://github.com/yuvipanda/nbrsessionproxy/blob/rserver-again/jupyter_rsession_proxy/__init__.py

So, this leads me to think that what happened is @yuvipanda created the pull request, assumed it would be merged, and pushed his version to pypi. Which is to say, I've been using the rserver 'alternate' version this whole time.

If using rserver is what solves my problems, I have a new problem. There are two open merge requests intended to switch from rsession to rserver - #84 and #57.

Ok, so now I have some questions -

1. is the above theory correct?
2. Can the maintainers please choose one merge request of the two mentioned above, and kill the other one?
3. Can you provide some indication of the merge path in the coming weeks/months? This needs to be clearly signalled because the people who depend on the pypi package will have a situation where they were using rserver for the last year, now it's switched to rsession, and it'll switch back to rserver when the merge request is approved.

[riazarbi]

For anyone else in the same boat as me, I'm currently dealing with this by locking the pip install command in my Dockerfile like so:

python3 -m pip install jupyter-rsession-proxy==1.0b6

My docker build hasn't finished yet but I expect this will do the trick.

[ryanlovett]

Hi @riazarbi:

1. Yes, 1.0b6 uses rserver.
2. Yes.
3. Yes, this should happen by this week or next.

[ryanlovett]

Hi @riazarbi,

I've pushed v1.1 which uses rserver. Everything <= 1.0, except the untagged 1.0b6, used rsession.

[riazarbi]

Feedback. Our build is using pip v 1.1 and everything is working smoothly.

[riazarbi]

Closing because original question has been addressed. Thanks @ryanlovett !!