nonLocal took too long to respond
danielbogomazov opened this issue · 10 comments
I've copy and pasted your example App.tsx
into my project to start out with. It seems to be working as expected inside the WebView
in the app running locally on my Android device.
The issue I'm having is trying to connect to the server from my desktop (same network). I've passed in nonLocal: true
into the constructor to allow for non-local connections but whenever I try to connect to it, my desktop's web browser returns with a ERR_CONNECTION_TIMED_OUT
page (which seems to imply that it's able to find the server but not able to establish a connection?).
I've tried this with v0.8.0, v0.7.13, and v0.7.12 - none fix this issue.
The only error I get is from lighttpd
(pulled from Android Studio):
2023-07-21 10:26:19.822 12214-15837 lighttpd com.storystream E (C:/Users/....../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/server.c.1928) server started (rn-static-server/1.4.71)
Looking at that line in the linked library, it doesn't seem like it's an actual error, just there for logging purposes (I think?).
Here's what I see in metro:
LOG Server #41691.
Origin: New state: "STARTING".
Details: "".
LOG Server #41691.
Origin: http://10.0.0.251:41643 New state: "ACTIVE".
Details: "".
Done in 946.53s.
Opening the origin on my Desktop times out.
- Developing on Windows
- Running on Android
- react v18.2.0
- react-native v0.72.0
Looking at that line in the linked library, it doesn't seem like it's an actual error, just there for logging purposes (I think?)
Correct, it just logs as "errors" both regular log messages, and actual errors.
From what you say you see in the logs, it seems the server has started fine... probably the firewall on your machine blocks the connection?
Doesn't seem to be a firewall issue. I've turned it off on my machine and it still won't connect. I tried connecting using my phone on the network but no luck there either.
I turned on all error logging flags to see if I could find any hint as to what's happening. This was what I found in ERROR_LOG_FILE
after trying and failing to connect to the server a couple times:
2023-07-21 12:43:41: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/server.c.1928) server started (rn-static-server/1.4.71)
2023-07-21 12:43:41: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/configfile.c.1296) WARNING: unknown config-key: debug.log-condition-cache-handling (ignored)
2023-07-21 12:43:41: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/configfile.c.1296) WARNING: unknown config-key: debug.log-ssl-noise (ignored)
2023-07-21 12:45:36: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/server.c.1224) [note] graceful shutdown started
2023-07-21 12:45:36: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/server.c.2336) server stopped by UID = 0 PID = 0
2023-07-21 12:45:38: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/server.c.1928) server started (rn-static-server/1.4.71)
2023-07-21 12:45:38: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/configfile.c.1296) WARNING: unknown config-key: debug.log-condition-cache-handling (ignored)
2023-07-21 12:45:38: (C:/Users/..../node_modules/@dr.pogodin/react-native-static-server/lighttpd1.4/src/configfile.c.1296) WARNING: unknown config-key: debug.log-ssl-noise (ignored)
Only thing that pops out is the "unknown config-key" error. I tried to take a look at the lighttpd1.4 file where this error was logged but it's not immediately obvious to me as to what's actually happening there.
Hmm… looks like there is smith messed up with logging config… though it should not cause troubles you experience. For me it looks like the server is running fine, but for some reason your requests do not arrive to the server, and just do get lost somewhere 🤷♂️
I’ll double check next week if non-local mode works for me in the example app.
Actually, it probably just starts on a wrong network interface, try to use ‘hostname’ argument to explicitly specify the IP of device on your local network.
Adding the hostname did not solve it.
I deleted my app and reinstalled it through Android Studio and now it seems to be working. Maybe something with hot reloading the app over and over again broke something?
I try to hot reload the app while developing. If the library yells at me that there's already a server running after hot reloading, I quit out of metro and restart. I think the hot reload bug that I was facing is referenced in this issue - but it's not consistent for me. When I reload metro, I'm able to start a new server again.
The fix resulting from uninstalling the app leads me to believe that it could have been caused by the server leaking someway, somehow - but I have no idea how lighttpd
works so this is a complete guess.
I'll keep an eye out to see if I can spot any way to reproduce this consistently if I run into it again.
debug.log-ssl-noise
is recognized by lighttpd when a lighttpd TLS module is loaded. If one is not loaded, debug.log-ssl-noise
is an unknown config-key
debug.log-condition-cache-handling
is not a lighttpd config directive (unless @birdofpreyru patched this in). The upstream lighttpd config has debug.log-condition-handling
, which is spelled differently.
@birdofpreyru Regarding #56, why not use a mutex to ensure that only one thread is starting and stopping lighttpd before releasing the mutex for another thread to do so?
Hi @gstrauss , thanks for passing-by to comment on this! :)
Re. debug.log-condition-cache-handling
, I actually just got it from Lighttpd Wiki: https://redmine.lighttpd.net/projects/lighttpd/wiki/DebugVariables
Re. #56 — It was my mistake — I did a similar thing in JS layer from the very beginning, but I haven't thought about advanced scenarios where React Native can re-load my JS module, destroying my synchronization of methods on JS side. Thus, it indeed needed synchronization of threads in the native layer, and presumably I've nailed it now.
@danielbogomazov Regarding your original complain, I finally tried to reproduce your scenario with the Example app, and it worked for me without any issues:
- I used a real Android device. Connected it to my machine and did
to find out its IP address (say
$ adb shell ip addr
111.111.111.111
) on my WiFi network. - Then in the Example app I just added
hostname
andport
(just to simplify the test, I guess, the auto-selected port should work just fine as well) to the Server options on this line:
turning it intolet server: null | Server = new Server({ fileDir, hostname: '111.111.111.111', port: 3000, stopInBackground: true, });
- Then just deployed & run the app on the device, and I could see the test page both in the app on the device, and also by accessing
111.111.111.111:3000
in the browser on my desktop (and here I sure used a new incognito tab, as non-incognito tabs in Chrome have a habit to force connections to automatically force HTTPS connection, and HTTPS is not currently configured by this library).
Thus, I believe no issue here, I'll close this thread later.
P.S.: There is also a related open issue #21, saying that we need to add into the library some features to make it easier to list all connected network interface, or automatically select the interface needed for a particular purpose. The hostname
option allowing to specify the IP to start on is a part of the solution, but beyond that resolving that issue is not on top of my priorities at the moment.
slightly off-topic: Re: debug.log-condition-cache-handling
There is no history of debug.log-condition-cache-handling
in lighttpd git, other than imported invalid doc in the defunct 1.5.x branch, so I updated the wiki to remove debug.log-condition-cache-handling
. Thanks for pointing it out.
/src/configfile.c.1296) WARNING: unknown config-key: debug.log-condition-cache-handling (ignored)
The directive is not recognized by lighttpd and does not do anything, so you probably should remove debug.log-condition-cache-handling
from the config you provide.
Thanks for confirming @gstrauss 👍