The deployed version of awesome-panel.org very often places the header, sidebar and main Columns outside the template sections!

[MarcSkovMadsen]

System Info

• Panel: 0.7.0
• Bokeh: 1.4.0
• Tornado 5.1.11
• Python: 3.7.4
• OS: Windows 8.1
• Browser: Chrome

Behaviour

My app deployed at awesome-panel.org often places my header, sidebar and main Columns at the bottom of the HTML document instead of in the sections of the template. It's difficult to explain the behaviour so I've inserted a small video of the behaviour.

I cannot reproduce the issue locally when running Panel in a terminal (localhost example below) or inside Docker container (192.168.99.100 below). The Docker container is the exact same container as deployed.

Additional info

I've attached the html code generated for one of the failed layouts. If you inspect the html file then you will see that my Columns have just been placed at the bottom of the html document outside my template.

awesome-panel-html.zip

The problem has not always been there in production. I have not recorded exactly when it started.

But for now my hypothesis is that it started when @philippjfr helped me improve the speed/ responsiveness of my app by changing my template to a css grid (?) based on sections. It's probably this commit awesome-panel/awesome-panel@965a66a

The docker container currently deployed to production is available via docker pull marcskovmadsen/awesome-panel:151.

[MarcSkovMadsen]

I will try to find the problem my self. But right now this seems like finding a needle in a haystack so if anyone has any ideas of why this can happen then that info would be much appreciated.

[MarcSkovMadsen]

I have seen the behaviour in Chrome and Firefox on my windows laptop and in Safari on my Iphone.

I've tried clearing my history in Firefox. But it does not change anything.

[MarcSkovMadsen]

I tried simplifying the template so that it does not use the css grid.

But the problem is still there. So it's not a problem with the CSS grid.

<!-- This template is inspired by
- Bokeh Template. See https://panel.pyviz.org/user_guide/Templates.html
-->
{% extends base %}

<!-- goes in head -->
{% block postamble %}
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<link
  href="data:image/x-icon;base64,AAABAAEAEBAQAAEABAAoAQAAFgAAACgAAAAQAAAAIAAAAAEABAAAAAAAgAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAA////AL12KgAWi/IAKrUoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiIiIiAAAAAAIiIiAAAAAAACIiAAAAAiIiIiIiIiACERERERERIAISITMUQREgAhIhMxRBESACEiEzFEERIAISITMUQREgAhERMxRBESACEREzFEERIAIREREUQREgAhERERRBESACERERERERIAIiIiIiIiIgAAAAAAAAAADwDwAA+B8AAPw/AACAAQAAgAEAAIABAACAAQAAgAEAAIABAACAAQAAgAEAAIABAACAAQAAgAEAAIABAAD//wAA"
  rel="icon" type="image/x-icon" />
{% endblock %}

<!-- goes in body -->
{% block contents %}

<div style="background:blue;">
  {{ embed(roots.header) }}
  {{ embed(roots.sidebar) }}
  {{ embed(roots.main) }}
</div>

<!-- <section id="page">
  <header>

  </header>

  <nav>
    {{ embed(roots.sidebar) }}
  </nav>

  <main>

  </main>
</section> -->

{% endblock %}

[MarcSkovMadsen]

I've tried removing --num-procs 0 in my Dockerfile i.e. changing

ENTRYPOINT [ "panel", "serve", "app.py", "--address", "0.0.0.0", "--port", "80", "--num-procs", "0"]

to

ENTRYPOINT [ "panel", "serve", "app.py", "--address", "0.0.0.0", "--port", "80"]

and the problem goes away.

[MarcSkovMadsen]

I've got this response on the gitter channel

When you connect to a bokeh server with an HTTP(S) request Bokeh returns a template, and that template immediately turns arounds and makes a websocket connection back to the Bokeh server. But with --num-procs > 1 there is no guarantee that the websocket connection lands on the same original process. That's why e.g. the full HTTP request is not available in the app code— if the websocket lands on a new process, that new process never saw the HTTP request, knows nothing about, can't even in principle provide it.

[MarcSkovMadsen]

@philippjfr . I've closed this one. But I think there should be and issue/ feature request somewhere on the problem and solution you have discussed. But I just don't know where.

[philippjfr]

There is a bokeh issue about it and it'll be fixed in bokeh/bokeh#9536