I have MozRepl installed in my browser and set to start on startup and accept outside connections.
So my questions are as follows
1) will simply running the code my $mech = WWW::Mechanize::Firefox->new(); launch the firefox browser?
2) I have set MozRepl to accept outside connections however, while firefox is not launched, when my script reaches the code in 1), it tells me unable to connect, problem connecting to localhost, on port 4242. I tried to debug by doing telnet localhost 4242 with firefox browser not launched. It also gives me this error Could not open connection to the host, on port 4242: Connect failed.
Should i be expecting this result?
3) Given the difficulties I'm experiencing above, I decided to use system() to launch the browser before creating mechanize::firefox instance. The browser is able to start, however it never reaches the code where mechanize::firefox instance is to be created.
#where i manually fire up firefox.
system('"C:\Program Files\Mozilla Firefox\firefox.exe"');
my $mech = WWW::Mechanize::Firefox->new(ssl_opts => { verify_hostname => 0});
$mech->get( 'https://192.168.1.23' );
What can i do to make sure firefox browser can be launched yet it will not affect the sequence of the code, such that mechanize::firefox instance can be created to manipulate the browser?
You have to start your browser before your test, it is not started automaticaly.
I takes time to start firefox, but system returns instantly after firefox started. I takes some seconds to initialize all of its plugins, etc.
The easiest thing is to wait 30 sec via sleep, or you start a while loop to wait until it is responding.
It is possible that a firewall rule prevent you access mozrepl. The default port is 4242.
check the port via telnet:
telnet 192.168.1.23 4242
telnet 127.0.0.1 4242
Related
I am running Xdebug extension on PHP webserver (IIS), and VSCode on different development machine.
When I start listening for Xdebug session in VSCode (with Felix Becker's PHP Debug) without proxy, everything works as expected.
Now I am trying to use dbgpProxy because there are multiple devs on the development machine.
I have tried to run dbgpProxy on the webserver and register to it by activating proxy settings in VSCode, but it fails with Connection refused. At the same time, Xdebug connects to the proxy just fine and proxy tries to forward incoming session based on IDE key but of course cannot find it because the registration failed.
So I tried running dbgpProxy on the development machine. This time VSCode registered successfully with the proxy, but when Xdebug tried to connect to the listening proxy, it failed.
I was pretty sure I knew what I was doing, ports were open, everything SHOULD work but it didn't.
It turned out to be a problem in the IP addresses.
I ran the proxy with default settings, which is localhost (127.0.0.1) for both server and client part with respective ports 9000 and 9001. Which was wrong (for my situation).
To listen to the incoming connections from another machine, proxy has to be configured with real IP address of the machine it is running on, otherwise it won't listen.
In my case I have decided to run the proxy on the server, so I run it with just one parameter for the incoming client connections and leave the server parameter default (which is 127.0.0.1:9000 and of course configure XDebug in php.ini to this address and port).
dbgpProxy.exe -i 10.123.54.76:9001
I have a server running on weblogic 12c. But it is running on localhost:7001/myapp/.. I can run it by http://localhost:7001/myapp/... or http://127.0.01/myapp/... But only on the computer that weblogic is installed. I need to access from other computers. I have changed the Listen Address from localhost to my public IP, but when i did it, my server did not run anymore, it shows an error "Could not find lock file. Maybe the server is already running" something like that. I have already tried to delete the .lok file, but that did not work either. Tried to change the config.xml file, but that did not work either. Have this happenned to someone? How do I fix this?
I faced the same issue and below the answer, for stand alone Weblogic and even for embedded one, You want to change Listen Address, Just do the following steps:
If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit (see Use the Change Center).
In the left pane of the Console, expand Environment and select Servers.
On the Servers page, click the name of the server.
Select Configuration > General.
On the Severs: Configuration: General page, enter a value in Listen Address.
Click Save.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
Not all changes take effect immediately—some require a restart (see Use the Change Center).
For (integrated weblogic only) on JDeveloper, open Application servers from windows menu, select Integrated weblogic, right-click on it, select Properties, select Configuration tab, Change hostname with the same IP address you put in Console
if your Weblogic server isn't production server, just ignore steps (1 & 7)
reference : https://docs.oracle.com/cd/E50629_01/wls/WLACH/taskhelp/channels/ConfigureListenAddresses.html
First you need to check what is running on 7001 port:
On windows use: netstat -ano|find /i "7001" it will give you something like :
TCP 0.0.0.0:7001 0.0.0.0 TIME_WAIT 1028
then you can kill that process using
taskkill /F /PID 1028 (java process started on 7001)
Now try to delete *.lok file from Domain/servers/AdminServer Path
and start admin server .
If you have nothing specified in listen address field it will listen on all the available network interfaces which can be check by ipconfig command on window
On linux use netstat -tulp|grep 7001 to find process
Did you see check if there is another application running on your public ip and the same port ?
Your Question is not at all clear. You say your server is running on a server and you can access it using the url http://localhost:7001/myapp/...
So that bit is clear.
Then you try to access your application from another machine. This where it gets confusing.
You say - "I have changed the Listen Address from localhost to my public IP, but when i did it, my server did not run anymore, it shows an error "Could not find lock file. Maybe the server is already running" something like that."
Why would your server stop running if all you did was try to access from a different machine ?
" The error could not find lock file " is usually seen when you try to start a server on a machine where there might be another server already running. But since your aim is only to access your already running server from a different machine you would do that using a browser, why start another instance ?
Could you throw some more light on what exactly you are doing and the result.
Few tips -
Check the listen address of your weblogic server from admin console.
Check if the server you are running weblogic has more than 1 ip. Run ifconfig or ipconfig to get the IP's
I am trying to run the socket api example provided by goggle native client.(path : nacl_sdk\pepper_35\examples\api\socket)
I am able to build and run this example using make command, also it is displayed properly on chrome browser. But when I try to connect to some TCP port it always fails irrespective of IP and PORT.Though I have created an application which listens on a specific port on my machine.
Following is the error message:
tcp
Resolving ...
Resolve failed.
I can not even create the local server by providing only the port number.It says:
Starting server on port: 8080
server: Bind failed with: -7
Following changes are already done:
enable nacl on chrome
enable nacl socket api on chrome
Following things have been tried:
launching chrome using command line arguments
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-nacl-socket-api="http://localhost"
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-nacl-socket-api=IP_ADDRESS_OF_MY_SYSTEM
Can anyone tell what am I missing here ?
The correct argument is:
--allow-nacl-socket-api=localhost
The argument must be just the origin, and it must be the origin where that is trying to access sockets. Your IP address doesn't work because the page you are loading isn't specified with an IP address. The arguments must match exactly, or all socket calls will fail.
I managed to get this working on pepper_49 with Google Chrome 54.0.2840.59 (64-bit).
First step is to make sure that you have nothing NACL related features enabled in chrome://flags. I think I had #allow-nacl-socket-api turned on, and it will not work, even if you pass the correct command line argument. restore them back to default!
Second, make sure you do not have any other instances of Chrome running. For some reason, it won't work if another instance of chrome is running prior to launching chrome with the proper command line argument.
And then, the final step (credit goes to #binji for this step), launch chrome from the command line with this argument:
google-chrome --allow-nacl-socket-api=localhost
then go to http://localhost:5103/api/socket. This time, you should have this:
tcp
Resolving ...
Resolved: 127.0.0.1:80
Connecting ...
Connected
I am trying to debug my Play application with Eclipse. First I launch it using Run As: Application.launch
That seems to work.
Then I try to connect the debugger using Debug As: Connect JPDA to Application.launch
and I get the error message:
"Failed to connect to remote VM. Connection refused.
Connection refused: connect"
Any idea how to make this work?
As stated in another answer, the error you are getting is exactly the same one that you get when you attempt to connect the debugger for a second time when it is actually already connected.
That being said, if it doesn't seem to explain your case, look for this line when you initially start the application via Run As --> Application.launch:
Listening for transport dt_socket at address: 8000
It tells you on which port it is listening for possible JPDA connections, and if this line is missing then something is wrong. You can modify the Application.launch configuration manually (look at the address part of -Xrunjdwp parameter passed to Java virtual machine) and change the port if necessary. If you make changes you also need to update the Connect JPDA to Application.launch run configuration.
Anyways, that is my suggestion - check that the application is indeed listening for possible debugger connections, and try changing the port that is being used for the purpose.
Check that your application mode is set to dev in your conf/application.conf:
application.mode=dev
Start your application and you should see the following:
Listening for transport dt_socket at address: 8000
Right click on the "Connect JPDA.." launcher and Debug As "Connect JPDA..."
I have recieved this error in the past when i have forgotten that the debugger was already connected. Perhaps it is being launched in another way? Also is it possible that debugging is disabled in the app.conf? Just a few things I would check on.
I always run from the command line and debug from Eclipse, might be worth a tray as well. Also try running in test mode if you aren't.
Shutdown everything and run it again. What happens is that when you execute the debug it does not show you anything and you might think nothing happens. You get this error because you might tried several times and you don't know it is already running.
Firstly you have to start play from console not run as. Then start debugger run as.
Here's what I've done:
I wrote a minimal web server (using Qt, but I don't think it's relevant here).
I'm running it on a legal Windows 7 32-bit.
The problem:
If I make a request with Firefox, IE, Chrome or Safari it takes takes about one second before my server sees that there is a new connection to be accepted.
Clues:
Using other clients (wget, own test client that just opens a socket) than Firefox, IE, Chrome, Safari seeing the new connection is matter of milliseconds.
I installed Apache and tried the clients mentioned above. Serving the request takes ~50ms as expected.
The problem isn't reproducible when running Windows XP (or compiling and running the same code under Linux)
The problem seems to present itself only when connecting to localhost. A friend connected over the Internet and serving the connection was a matter of milliseconds.
Running the server in different ports has no effect on the 1 second latency
Here's what I've tried without luck:
Stopped the Windows Defender service
Stopped the Windows Firewall service
Any ideas? Is this some clever 'security feature' in Windows 7? Why isn't Apache affected? Why are only the browsers affected?
If you're saying "localhost" instead of "127.0.0.1", you're forcing a name lookup before the actual connection attempt, adding delay.
In addition, some browsers, like Firefox 3.5+, don't use the operating system's DNS lookup mechanism, which is why it can have different performance than, say, wget.
You may be running into some automatic proxy discovery problem. In Firefox, you can disable this in Options | Advanced | Network | Settings; select either "No proxy" or give it explicit values. There's also the Internet Properties control panel, which is IE's network settings, but other browsers on Windows may obey settings here, too. Again, disable auto-proxy discovery. This can speed connections outside localhost, too.
For some reason Windows 7 takes 1 second to resolve address localhost regardless of it being in hosts file.
Adding localhost1 to hosts file and using that works around the problem.
When connecting to localhost on a IPv4/IPv6 dual stack host:
A DNS lookup is performed for localhost.
The DNS server (whether IPv6 enabled or not - this doesn't matter) returns both the AAAA record ::1, and the A record 127.0.0.1.
The client first attempts to connect to ::1.
We assume your server program is not IPv6-capable, which is a common case - due to historical reasons, many servers bind their socket to 0.0.0.0 by default rather than [::].
Here an ECONNREFUSED error would be raised for the client. This happens immediately on most platforms; on Windows however, a single call to connect() would try 3 times in 500ms intervals before giving up, hence taking a bit more than one second (See http://stackoverflow.com/q/19440364 for more details).
The client then creates a connection to 127.0.0.1 instead.
This would explain all your clues above:
If you make a request with Firefox, IE, Chrome, Safari or any other IPv6-capable clients, it takes takes about one second trying for ::1 before connecting to 127.0.0.1.
Your own test client just opens a INET socket, so it won't try ::1 at all.
Using a dual-stack server such as Apache, the clients will connect to ::1 happily.
The problem isn't reproducible on Windows XP, of which IPv6 support is not enabled by default.
The problem seems to present itself only when connecting to localhost, as your friend connected with an IPv4-only network.
Running the server in different ports has no effect on the 1 second latency.