I can't seem to access Sinatra's local server. I have a win10 machine and I have my servers running in an Ubuntu on Windows. Sinatra has been installed without docs because installation would hang otherwise. This is the server log:
dario#DESKTOP-LSFERHU:~/dev/ruby/sinatra$ ruby first_app.rb
[2017-07-05 15:47:38] INFO WEBrick 1.3.1
[2017-07-05 15:47:38] INFO ruby 2.3.1 (2016-04-26) [x86_64-linux-gnu]
== Sinatra (v2.0.0) has taken the stage on 4567 for development with backup from WEBrick
[2017-07-05 15:47:38] INFO WEBrick::HTTPServer#start: pid=19509 port=4567
This is the app's content:
require 'sinatra'
set :bind, '0.0.0.0'
get ('/apple') do
"Here's an apple"
end
localhost:4567 hangs waiting.
I added the "set :bind" directive as a last hope, but it changes nothing. I can access no problem other local servers (for example a node server on port 5000). I turned off AVG in case, but again made no difference. Different browsers, no difference. Unsure where to go. Ideas?
It seems that the AVG antivirus, before I managed to shut it off, had somehow interfered with the server process. It somehow froze it. Any attempt I would make at starting a new server would only apparently work, while in reality conflict with this frozen process. I was unable to kill the process with any usual method (kill -KILL or so). I rebooted, added the ruby binary to the list of exceptions for AVG, and now the server works just fine. The Ubuntu on Windows had nothing to do with it.
Related
I've been using Mongo for a while now, and I never had any kind of errors. But today, I tried running the mongo command in my terminal and I got the following error:
Error connecting to 127.0.0.1:27017 :: caused by :: No connection could be made because the target machine actively refused it. :
I have my PATH variable for Mongo properly configured in my environment variables as follows:
C:\Program Files\MongoDB\Server\4.4\bin
so I doubt that is the issue. I remember going through my task manager yesterday and I accidentally terminated a program running in the background related to Mongo, but I can't seem to remember exactly what it was called, and I really think that that's the root of my problem, because before having terminated that Mongo program in my task manager I had never ran across this connection problem before.
By terminating a program in the background, I'm going to assume you didn't just end process, otherwise a simple computer restart would fix your issue. And in some cases, that same program would've relaunched when you launched MongoDB. But if you disabled a service and need to find which service needs to be running to be able to connect to your MongDB then I would suggest going through your Windows Services list and seeing which ones you disabled and looking one relating to TCP or SNMP.
This is because MongoDB Wire Protocol is a simple socket-based, request-response style protocol. You communicate with the database server through a regular TCP/IP socket and since you can't remember which one you "terminated" and any number of services related to networking can cause a dependency to be absent, I can't be more specific in helping you determine which one you need to turn back on and you'll have to do it through trial and error but I can at least offer you some guidance, hopefully.
Specifically you can either
Run system configuration using
msconfig
In a run box, navigating to the Services tab, order the list by Date Disabled to find the service that was disabled which correlates with when you when snooping through task manager, or
Run Task manager and navigate to the Services Tab, then Open Services, and order them by Status or by Name, and look for any service that includes TCP/IP, COM+, Port direction, etc. to see which one is disabled and change the configuration from anything but Disabled and then stat it manually and run MongDB again.
It's about as specific as I can get without knowing anything more than you terminated some program running in the background but I hope it helps.
The background process (daemon) for MongoDB is called 'mongod'. It's an executable in your bin directory inside your mongodb installation. You can just execute it in the terminal.
Run:
C:\Program Files\MongoDB\Server\4.4\bin\mongod.exe
Deploying Clojure/Java apps is hard, so I had this idea yesterday I want to understand better. If I spin up a machine that has Clojure and boot-clj installed and run boot wait repl -s -H 0.0.0.0 on the machine (let's ignore auth for now), I should be able to connect to it from my dev box and trigger the retrieval of dependencies over the wire (which will then be cached on the machine), then wire over all the source code and eval until I hit a snag, right?
Let's pretend this is a good idea. Is it possible to do this, and what are the hurdles involved? Right now I'm waiting 5 minutes for CircleCI to package up an uberjar, then fail because some Heroku token expired but all I want to do is see my code running on a staging environment so I can wire some more code and re-eval it.
The first thing t hat comes to mind is nREPL auth, which I see is not mentioned in any of the nREPL libraries. So let's say that's a higher-level networking concern and I'll do ACL via VPC.
Has anyone done this? Why is it a bad idea? Can you show your recipe for bootstrapping a Clojure app on a remote machine without the use of git or SSH (aside from initial REPL start)?
I should be able to connect to it from my dev box and trigger the retrieval of dependencies over the wire (which will then be cached on the machine), then wire over all the source code and eval until I hit a snag, right?
Is it possible to do this, and what are the hurdles involved?
Yes, but you need to specify -b (address server listens on) instead of -H (host to connect client to):
$ boot wait repl -s -b 0.0.0.0 -p 3000
nREPL server started on port 3000 on host 0.0.0.0 - nrepl://0.0.0.0:3000
Then connect to it however you like, for example with lein repl:
$ lein repl :connect 127.0.0.1:3000
Now you can add a dependency in the REPL and it'll be downloaded on the server/host. In the client REPL:
boot.user=> (set-env! :dependencies #(into % '[[clj-time "0.14.0"]]))
And if you're watching the server console you'll see it downloading dependencies:
Retrieving clj-time-0.14.0.pom from https://repo.clojars.org/ (3k)
Retrieving joda-time-2.9.7.pom from https://repo1.maven.org/maven2/ (32k)
Retrieving clj-time-0.14.0.jar from https://repo.clojars.org/ (22k)
Retrieving joda-time-2.9.7.jar from https://repo1.maven.org/maven2/ (618k)
And then back on the client side:
boot.user=> (require '[clj-time.core :refer [now]])
nil
boot.user=> (now)
#object[org.joda.time.DateTime 0x1f68b743 "2018-03-15T12:16:29.342Z"]
Has anyone done this?
Yes, I've seen people host nREPLs from remote servers and connect to them to tinker with a running system.
Why is it a bad idea?
Generally speaking, we want reproducible builds and stable artifacts to give some degree of certainty about what code is being released. Doing this type of development on-the-fly on-the-server works against those goals, making it harder to determine what code is running where. I'd try to structure the system (and its testing) such that this degree of remote dynamism isn't required for normal development.
It sounds like your primary problem is a cumbersome link (CI/CD) in your dev/test/run feedback loop. I'd explore other options for optimizing that feedback loop before going to dynamic dependency-hot-loading nREPL, if you can avoid it. Of course, it's there if you need it!
Can you show your recipe for bootstrapping a Clojure app on a remote machine
Personally, I only ever deploy JARs to remote machines, and usually in a container. By that time I've already exercised/tested the system locally and have some confidence it'll behave as expected. If most of your system is untestable without deploying, that may be a sign you should break it into smaller, more testable pieces.
Suddenly Websphere server is automatically started.
I stop many times but started again automatically.
Even I removed project from the web sphere and removed websphere from the project and Again add for the same.. But still I it is starting.
I also run the below command,
Server stop server_name
below Message is showing
Stopping server server_name
So it is not stoping. How to stop forcefully? or Kill existing process?
Your question doesn't state what OS you're running on, but Liberty doesn't currently ship with any means to automatically start the server (like a Windows service), so when you say "started again automatically", it is more likely that the server is never shutdown. Liberty runs as a process that can be killed and the process id can be determined by looking at the messages.log file in the server logs directory. The preamble of the file will contain a line like this:
process = 11488#YourHostName
Depending on the OS you're running on, you can use the kill command (Linux or MacOS), or the Windows Task manager to end the process. When you restart the server, you may want to specify the --clean option like this:
server start defaultServer --clean
in Solaris 10, when server restart, the backup daemon (tina_daemon) does not work properly when calling for another executable to shutdown the application services.
however, when manually restart the backup daemon, the calling for the executable works fine.
I found the following lines in the log-file:
8|9|tina_daemon|780|1|3|1373964994|1373964994|10739|tina_daemon_1|<host name deleted>|~|root|~|backup_poc_tina|backup-poc|Event handler daemon started|0|~|~|~|~|~|~|
8|9|tina_daemon|880|256|3|1373964994|1373964994|10739|tina_daemon_1|<host name deleted>|~|root|~|backup_poc_tina|backup-poc|Service opened, host "<host name deleted>", Time Navigator Enterprise Edition Version 4.2.8.8 P4680|0|~|~|~|~|~|~|
8|14|TNUnixSocketImpl::initNetServiceTcp|11|1|1|1373965001|1373965001|10963|tina_daemon_1|<host name deleted>|~|root|~|backup_poc_tina|backup-poc|Unable to bind 5 socket, retos=125 "Address already in use"|0|~|~|~|~|~|~|
8|14|vos_init_net_service_tcp|1|1|4|1373965001|1373965001|10963|tina_daemon_1|<host name deleted>|~|root|~|backup_poc_tina|backup-poc|Unable to initialize network service of TCP type, retex=TN_ERR_CONFLICT_RESS (conflict in access to the same resource)|0|~|~|~|~|~|~|
is it a potential that not enough share memory? since the tina_daemon use 2 ports which already define in the /etc/services
I feel very weird since when manually using root to restart the tina_daemon, everything works fine. When server restart with the startup script (which i changed to similar to manul restart), it does not work well for calling another executable to shutdown the application. It shutdown the application half way, and cause the application hang (and ultimate need to restart the application)
I'm using Linux, and I've installed GlassFish 3.1 outside of Eclipse. It starts fine with asadmin start-domain.
In Eclipse Helios I've installed the latest version of the GlassFish tools, server adapter etc. I've added a "Server" instance for my external GlassFish, but when I try to start it, the Eclipse Console says "Waiting for domain1 to start ......" – more and more dots are printed while I wait for several minutes. Eventually there's a dialog saying "Server GlassFish 3.1 at localhost failed to start."
At no point is http://localhost:8080 responding.
There is no other errors messages that I can find. The server log (glassfish/domains/domain1/server.log) prints the long startup command, and then:
Feb 28, 2011 10:48:45 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: Successfully launched in 3 msec.
The GlassFish installation is entirely stock, with no applications loaded. It works fine when started from the command line outside of Eclipse.
I've tried to reinstall GlassFish to different locations, I've reinstalled Eclipse with no plugins except the GlassFish stuff.
The strange thing is that the "Internal GlassFish 3.1" server, which is distributed with the Eclipse plugin and lives inside eclipse/plugins, works just fine and starts up very snappily. But I'd really like to have an external GlassFish that I can easily run independently of Eclipse when I want to.
Help much appreciated!
You can have detailed logs about what is going on :
go to "Window -> Preferences -> Glassfish Preferences".
There you can check the "Start Glassfish Enterprise Server in Verbose Mode".
I had problems starting Glassfish 3.1 from inside eclipse too.
I tried to delete the "osgi-cache/" subdirectory located in the domain directory and then i could successfully launch glassfish.
Hope it helps.
CLI130 Glassfish Error and Port 4848 in Use Error
Glassfish is written in Java and if the system's TCP/IP configuration isn't setup a certain way, Glassfish will choke when it makes a getLocaHost() call. A quick fix is:
Get the system's hostname and related IP
hostname
ifconfig -a
Add a line to /etc/hosts after the localhost line:
hostname ip-address-of-hostname
A Little More Background.....
If the local hostname (value returned from the "hostname" command) does not resolve to an IP address (e.g. "nslookup my-hostname") Glassfish will fail. The following Java app will expose this:
import java.net.*;
class Testnet {
public static void main() throws Exception {
InetAddress host = InetAddress.getLocalHost();
System.out.println ("host=" + host.getHostName());
System.out.println ("addr=" + host.getHostAddress());
}
}
The root cause could be any one of a number of issues:
The Local hostname (value returned from "hostname" command) does not resolve to an IP or valid IP
Misconfigured /etc/nsswitch.conf or /etc/hosts
There have been suggestions on the web that IPV6 only addressing messes up Java in Linux. To make sure this won't befall you, it can be set on most flavors of Linux with the following command (however the above Testnet app ran for us with bindv6only set to both 1 and 0):
sysctl -w net.ipv6.bindv6only=0
In terms of HA, having an entry for the local IP and hostname in /etc/hosts is a solid thing to do and to make sure "files" is the first entry in the list for "hosts" in /etc/nsswitch.conf. The downside to this is that each host needs to be setup with this line and it could cause problems with nodes that get their IP from DHCP or are randomly assigned when configured.
I've met the same problem as I was learning java web programming, but in netbeans - windows env. I've spent much time guessing what that error could mean because the log file wasn't clearly saying that.
Finally I found out that glassfish v3 was trying to run on 8080 port, which was already occupied by reportingservicesservice.exe which is sql server service.
go to (tools -> servers) add a new glassfish server instance which runs on a different, free port - that solved the problem.
The suggestion to delete "osgi-cache" worked for me on ONE machine (at work).
However on my home machine, neither that suggestion nor the suggestion to add my machine's hostname to the "hosts" file helped. Glassfish would start but Eclipse wouldn't recognize that...
The only thing that worked for me was:
go to the glassfish3/bin directory
execute "asadmin create-domain newdomain"
in this step, I was prompted for an admin username and password; I chose "admin" and "admin123" respectively
create a Glassfish server in Eclipse pointing to the new domain
Now I know that this may mean that the default domain (domain1) has some strange configuration, but that just doesn't seem right. Anyway, this did work for me, and now I can start Glassfish from within Eclipse - any Glassfish domain that I want.
HTH.
I'm using ubuntu 13.04 and had the same issue. I tried almost everything, but when i disabled IPv6 it worked. For ubuntu it's easy, just add following 3 lines to kernel parameters:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
and run sudo sysctl -p. Good luck ;)
p.s. Don't forget to disable proxy server, set Active provider to Direct at General->Network connections.
Hum. Good news is that the internal server is working.
For the external one, first thing to test is if the server can be started outside Eclipse.
Check also the domain directory known by Eclipse (hint: server properties tab), and if the location is the one you want to use.
Maybe the domain has been started with a different Glassfish Server? In this case, make sure the osgi-cache/ directory in this domain is deleted first.
If the server works outside Eclipse, triple check the registration data of this server (runtime +domain) in Eclipse itself. In fact, try a new eclipse workspace...
Is this server secured with https?
I had the samere problem with Indigo + Glassfish 3.1 plug-in accessing an already working local standalone glassfish instance (with username 'admin' and my own password set).
Fortunately doing the following did the trick for me:
stop glassfish
delete osgi-cache content ( ${GLASSFISH_3.1HOME}/glassfish/domains/domain1/osgi-cache )
set my username ('admin' in my case) and reset passowrd (no password at all)
starting glassfish from within Indigo now works!