Nitrogen console unresponsive while downloading a large file

[Ramkrishna Kulkarni]

I was testing the latest version with Cowboy flavor and found the console to be unresponsive till the download finished. All other requests were also stuck.

I placed a large file under ../static/nitrogen directory and tried a wget on that file.

Are there any Cowboy settings I'm missing? This is the first time I'm trying with Cowboy. I generally use inets.

[Jesse Gumm]

Weird. Especially weird that the console was hanging with the download.

I'll play around with this over the weekend to see what I can uncover.

-Jesse

> --
> You received this message because you are subscribed to the Google Groups
> "Nitrogen Project / The Nitrogen Web Framework for Erlang" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nitrogenweb...@googlegroups.com.
> To post to this group, send email to nitro...@googlegroups.com.
> Visit this group at http://groups.google.com/group/nitrogenweb.
> For more options, visit https://groups.google.com/d/optout.



--
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

[Ramkrishna Kulkarni]

Bit more information hoping it'll help.

This happens when I call "ls()." from the console while the large download is on. This is not reproducible with inets.

Thanks.

You received this message because you are subscribed to a topic in the Google Groups "Nitrogen Project / The Nitrogen Web Framework for Erlang" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nitrogenweb/LeU3yQ3XIik/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nitrogenweb...@googlegroups.com.

[Jesse Gumm]

Thanks for the followup.

I did some experimenting, and was not able to reproduce the console
hanging, even with the `ls` command, but the fact that postbacks don't
work during download is noticeable. The workaround that worked was to
use the new=true attribute in links that allowed download.

I'm still looking into it though, as the static files aren't even
handled by nitrogen, but instead are handled directly by cowboy
(that's that whole routing table). I've got a thing going on over the
weekend so I won't have time to play with it more deeply until after
the weekend.

-Jesse

[Jesse Gumm]

Just an update. I'm still working on this one. I have it partially
worked out, but I haven't yet figured out why cowboy seems to be
pausing some connection attempts while a download is happening. But
it seems intermittent with my fixes.

-Jesse

[Jesse Gumm]

Hi Ram,

I've done some heavy digging into the cowboy side of things and here's
what I've uncovered (and made a video to help demonstrate it):
https://github.com/ninenines/cowboy/issues/794

I'm curious to see what kind of suggestions there are for fixing it.

[Ramkrishna Kulkarni]

Thanks Jesse. This is really strange indeed. I hope we are not missing some very obvious config setting.

[Jesse Gumm]

Looks like it's a VM issue on older Erlangs (in my case, the server I
was testing on was running R16B). The fix is adding `+A 0` to the
erlang invocation. You can edit etc/vm.args and change the +A 5 line
to +A 0, and that'll fix it.

Weird, but at least we have answers. I putzed around with this error
for a good 4-5 hours yesterday.

Nothing quite like a fix where more hours were spent than characters
required to fix.

-Jesse

On Tue, Feb 17, 2015 at 2:02 AM, Ramkrishna Kulkarni

[Jesse Gumm]

Oh, and there's also a client-side fix required for it if your users
are downloading by clicking a link on the page (no longer required the
new=true workaround).

Here's that relevant commit:
https://github.com/choptastic/nitrogen_core/commit/8b7d0f9c5d788a447f255317a4fc0c391a803ef8

Turns out the fix to stop the "Disconnected" notification from popping
on firefox when you clicked a link was also being triggered with
download links. This fix no longer stops the event loop, but stalls
any "Disconnected" notification from popping immediately, allowing
events to properly pass through.

At this point, I feel pretty good about merging these in, possibly
adding a few more tests and tagging a version 2.3.1.

I've been hesitant about announcing the 2.3 release with the couple of
bugs brought up these past two weeks, but I feel better about it.

Now if only my Raspberry Pi 2 would be delivered so I can make the
rasppi binaries (my rasppi is no longer stable).

Anyway, enough rambling for me.

-Jesse

[Ramkrishna Kulkarni]

In Erlang docs:

"+A size: Sets the number of threads in async thread pool, valid range is 0-1024. If thread support is available, the default is 10."

So, setting this to 0 might impact performance negatively.

[Jesse Gumm]

It might, if you're using any async threads. But if you're using an OS
that properly uses sendfile, it shouldn't be a problem.

Or updating the VM should fix it, too.

What version of Erlang are you currently running?

On Tue, Feb 17, 2015 at 9:36 AM, Ramkrishna Kulkarni

[Ramkrishna Kulkarni]

I see. I'm running R16B01. I'm anyways planning to to move to OTP 17 along with Nitrogen v 2.3.x. Thanks.