I have tried starting firebase firestore and realtime database emulators through both a personal project and the Firebase Emulator Suite Codelab located here:
(https://firebase.google.com/codelabs/firebase-emulator#0)
Working with the codelab, the command line prints the following after 'firebase emulators:start'
[....] codelab-initial-state % firebase emulators:start --import=./seed
i emulators: Starting emulators: auth, functions, firestore, hosting
⚠ functions: The following emulators are not running, calls to these services from the Functions emulator will affect production: database, pubsub, storage
⚠ Your requested "node" version "10" doesn't match your global version "17". Using node#17 from host.
i firestore: Importing data from /Users/lucasfrench/Documents/emulators-codelab/codelab-initial-state/seed/firestore_export/firestore_export.overall_export_metadata
i firestore: downloading cloud-firestore-emulator-v1.13.1.jar...
Progress: =====================================================================================================================================================================> (100% of 61MB)
i firestore: Firestore Emulator logging to firestore-debug.log
i emulators: Shutting down emulators.
i functions: Stopping Functions Emulator
i firestore: Stopping Firestore Emulator
i hub: Stopping emulator hub
Error: TIMEOUT: Port 8080 on localhost was not active within 60000ms
This is the same Error with my personal project utilizing the realtime database emulator. However, I do not have any issues starting emulators for other products such as the auth emulator or with accessing the UI emulator.
This may be related to this issue. The workaround is to specify your localhost address (ex. 127.0.0.1) instead of localhost and add a host attribute inside your firebase.json with 127.0.0.1 also.
https://github.com/firebase/firebase-tools/issues/2379#issuecomment-972852609
"firestore": {
"port": 8080,
"host": "127.0.0.1"
},
Related
I’m having an issue setting up the Firebase Emulator on a Mac Mini with Apple Silicon (M1 chip).
Every request I send to Firestore (using the emulator) takes a very long time to complete (sometimes it never completes and I get a network error saying the backend couldn’t be reached):
#firebase/firestore: Firestore (8.2.5): Could not reach Cloud Firestore backend. Backend didn't respond within 10 seconds.
This typically indicates that your device does not have a healthy Internet connection at the moment. The client will operate in offline mode until it is able to successfully connect to the backend.
It turns out this is happening because I'm setting host to 0.0.0.0 in the firebase.json file. If I remove the host field or if I set it to be localhost, then I don’t have any issues.
This is my firebase.json file:
{
"firestore": {
"rules": "./firestore.rules"
},
"emulators": {
"firestore": {
"host": "0.0.0.0",
"port": 8080
}
}
}
The reason I'm setting it to 0.0.0.0 is because I need to test my app on a different machine (i.e. on a tablet) and the only way we managed to make it work was setting the host to be 0.0.0.0 since this host will resolve all addresses associated with our machine. This way, I can access the emulator using my local IP address (i.e. 192.168.0.1).
I noticed this issue only happens on the new Mac with the M1 Apple Silicon chip. So, I wonder if this has anything to do with the way M1 is resolving the IP address.
Any ideas?
I'm still not sure if this is M1-specific since I haven't been able to test this on another M1 machine but adding my computer's name next to localhost in the hosts file seems to have fixed this issue:
127.0.0.1 localhost Will.local
::1 localhost Will.local
I had the same issue with my new M1 Macbook Pro. The problem did remaining no matter if there were host info on firebase.json. -file.
I found an exciting solution to this problem. I switched my Mac to Google's DNS -servers (8.8.8.8 and 8.8.4.4), and suddenly everything started to work without any significant delays. Before that, the initial call sometimes took 10-15 seconds or even more.
I was wondering if since the 0.15.0 release and switching to cards someone has figured out how to access the same network both locally via the CLI and in the Playground and with the same Fabric runtime.
So far, I have been able to install my network's runtime, start and ping it on the Playground's fabric after creating PeerAdmin card using the script that came with Playground.
However, importing the newly deployed network's admin card fails in the Playground. If, however, I deploy the network via the Playground, export the admin card, download/import the admin card from the Playground and then try to composer ping it, it just sits there timing out after a while. This is MacOS High Sierra. So what gives and what can be done?
Thanks much!
If I understood your issue correctly, this is how you can solve it:
Create your business network in Playground
Export business network card from Playground (download button on card) which produces {nameOfUser}.card file.
Now you transfer this card to wherever you have installed fabric/playground
Run command: composer card import -f {nameOfUser}.card
Now your business card should appear under location {usersHome}/.composer/cards/user#network-name
Inside /cards folder, you should see 2 folders. One is "PeerAdmin" which was created if you followed setup and another one is your imported one
Copy connection.json from "PeerAdmin" to your new card and replace it. (this is most important step)
Run command: composer-rest-server and use as network card: user#network-name - folder that you copied
With all this steps I successfully created and ran server. Now you can access it on port IP:3000/explorer
You can share the Business Network Cards between Playground and the CLI. However it can be a bit more difficult if you are running Playground in a Docker Container.
With the CLI you connect to your Fabric servers on localhost and Docker deals with the Port fowarding into the Containers for the Fabric.
The Fabric Containers (and the Playground if you start it in a container) connect with eachother on 'fake' addresses managed by docker-compose e.g. orderer.example.com:7050
So if you start composer-playground using the CLI any Card you export will have localhost as the addresses of Fabric servers and other CLI commands will be able to utilise it. If however you are using Playground in a container the Card will use the fake addresses and you will not be able to connect from the CLI straightaway.
I assume you are using Playground in a Container and hence having the problem. If you find the connection.json in a location similar to: ~/.composer/cards/admin#*xxxxxx*/connection.json and edit the addresses of the fabric server to be localhost you should be able to use the CLI as expected.
I would like users inside my network to be able to connect the Bot Framework Emulator to a bot running on another machine inside my network. This is possible with ngrok, but it seems like ngrok should not be required since all of the machines are on the same LAN.
It appears that older versions of the emulator had a setting for "Emulator Url" which looks like it might have been useful for this, but that setting is not present in the current version (3.5).
Is this possible?
I have a SocketListener running in an azure worker role. It works fine but I want to debug locally. I can connect to the worker role using localhost but cannot connect from remote clients.
I have tested the router and incoming firewall by using a tcp terminal program I have switched off the firewall on my development pc.
Please can you help me to get remote clients to connect to a worker role listener being debugged on the development machine.
Thank you
The local windows azure development emulator is not designed to support remote connections. I would suggest deploying the application to Windows Azure and remotely debugging to test your scenario.
I need to make my local node.js webapp listen 80 port. Now if run my app on port 80 I get this erro
events.js:72
throw er; // Unhandled 'error' event
^
Error: listen EACCES
at errnoException (net.js:901:11)
at Server._listen2 (net.js:1020:19)
at listen (net.js:1061:10)
at Server.listen (net.js:1127:5)
at Object.<anonymous> (\scripts\server.js:23:4)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
And if run app on 4321 port this error do not reproduced, so it's port depending.
What should I do to be able run my app on port 80 on Windows 7
On windows machine you 80 port probably busy with IIS Server. Try to stop iis first and after run node.js webapp with port 80.
IIS on 80 port is definitely issue. And instead of turning it of you can try IIS node. http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx
Probably you don't need port 80 in local development at all, but if you go in production on Windows machine IIS Node is good choice to load balance.
I had this issue also on my Windows 10 PC.
I followed the command on this link (net stop http): https://stackoverflow.com/a/16243333 in a Command Prompt that I opened up as administrator and got this output:
C:\Users\<user>\Documents\project>net stop http
The following services are dependent on the HTTP Service service. Stopping the HTTP Service service will also stop these services.
World Wide Web Publishing Service
SSDP Discovery
Print Spooler
Function Discovery Provider Host
Do you want to continue this operation? (Y/N) [N]: y
The World Wide Web Publishing Service service is stopping.
The World Wide Web Publishing Service service was stopped successfully.
The SSDP Discovery service is stopping.
The SSDP Discovery service was stopped successfully.
The Print Spooler service is stopping.
The Print Spooler service was stopped successfully.
The Function Discovery Provider Host service is stopping.
The Function Discovery Provider Host service was stopped successfully.
The HTTP Service service was stopped successfully.
C:\Users\<user>\Documents\project>
I then did npm start again on another command prompt where I'm not running it as Administrator, and got this Error Dialogue
I clicked ok to close it and just typed localhost on my browser and my app launched!
What is weird is that I went back to the TaskManager -> Services tab, and I restarted all four services that were stopped. In the screen shot below you can see one of the services that was stopped before (look at the Description column), but now restarted:
But now when I run npm start my node app does get launched still.
So it does seem a little weird for me, that before I stopped those services I couldn't launch my app. After stopping them I now can launch my app. But I can still launch my app even after restarting those services.
Sigh - i just found out that SKYPE.EXE was lurking on my ports 80 and 443. Use netstat -anb to see what might be blocking node.exe from accepting sockets on those ports...
Like #jimme my problem was because I installed skype client for testing another project on the same development machine.
In my case I could }).listen(80); but not }).listen(80, "0.0.0.0"); My server was unreachable from anything but localhost. When I investigated by doing netstat -abn I could see that something was listening on that port but there was no process information. I lucked upon the info that "Windows attempts to accommodate such inflexible services by not binding its dispatch mechanism to port 80 until something actively asks for that. (This is why you won't necessarily see a problem initially, but can run into this issue after some sort of update or config change.)," at https://serverfault.com/questions/65717/port-80-is-being-used-by-system-pid-4-what-is-that which pointed to the article https://www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/.
When I saw that important piece of information and #jimme 's answer I remembered that I had also installed skype. I just made skype not start at startup and I was good.
#CAMD_3441 's extremely useful answer allowed me to launch the SignallingWebServer of my Unreal Engine 5 Pixel Streaming App.
I couldn't get SWS to use (listen) to port 80 and it was giving me this error :
node:events:371 throw er; // Unhandled 'error' event ^ Error: listen EACCES: permission denied 0.0.0.0:80 at Server.setupListenHandle [as _listen2] (node:net:1288:21)
All I had to do to fix that issue was type net stop http, and enter yes.
My SWS was able to launch on port 80 and I was able to view the Pixel Streaming page on 'localhost' using the browser which wasn't working if I connected the SWS to another port beside 80.