Hi Can someone plese help me to solve the following issue.
I have started my websphere server and it is using the following ports
TCP_1 is listening on host * (IPv6) port 9061.
TCP_2 is listening on host * (IPv6) port 9081.
TCP Channel TCP_4 is listening on host * (IPv6) port 9444.
When I stoped and started my server again I'm getting message saying that
TCP Channel TCP_3 initialization failed. The socket bind failed for host * and port 9043. The port may already be in use.
Can anyone advise me why it is not stopping automatically
Aprreciate your help on this. Thanks in advance
The specific problem is well known and is usually caused by the fact that there are still TCP connections from the previous WAS process (i.e. before restarting it) using the port.
Eventually the port will be released and the new WAS process will be able to bind it.
One way to overcome this annoyance is to set the soReuseAddr property to 1 in the TCP transport channel.
9043 is the Admin Console secure port. Do you have a dmgr running on this server in addition to a stand alone app server?
Related
according to this doc
Does this mean we could port forward 8000 and 8443?
If I deploy a spring integration project with TCP port binding to 8000 or 8443, will I able to telnet to openshift?
I have tried, but not sure what happened. When I use putty RAW mode connect to 8443, and send some text, nothing happened on the server console, my program should print out what it received. so I suppose I failed, right?
P.S. that project was tested using localhost tomcat, it works locally.
this related question seems to successfully forwarding many port.
I am currently having an issue with my ejabberd server I've set up recently: Any client is unable to connect to the server. Whether it is Psi or a sample code from the net, all produce an error when it comes to connecting, even though both is located on my computer, so no network issues can be the reason.
I have so far tried to bind the listener to a different port, and also checked the values in the ejabberd.yml. However, I was not able to find a sulution for my problem.
The service log of the server was not conspicious either:
2015-12-28 18:16:29.923 [info] <0.7.0> Application oauth2 started on node ejabberd#localhost
2015-12-28 18:16:29.938 [info] <0.449.0>#ejabberd_listener:listen_tcp:189 Reusing listening port for {5222,{0,0,0,0},tcp}
2015-12-28 18:16:29.938 [info] <0.450.0>#ejabberd_listener:listen_tcp:189 Reusing listening port for {5269,{0,0,0,0},tcp}
2015-12-28 18:16:29.938 [info] <0.451.0>#ejabberd_listener:listen_tcp:189 Reusing listening port for {5280,{0,0,0,0},tcp}
2015-12-28 18:16:29.938 [info] <0.37.0>#ejabberd_app:start:75 ejabberd 15.11 is started in the node ejabberd#localhost
2015-12-28 18:16:29.938 [info] <0.7.0> Application ejabberd started on node ejabberd#localhost
Did I do something wrong when entering the parameters? Or is this a problem of configuration? My first idea was that my anti-virus avast might be blocking some of the traffic, but i couldn't find anything on the web about that.
Attached you can find screenshots of psi and the server-ui.
The host name is pc-michi
With this link you can view my .yml file:
http://workupload.com/file/rQoLIf4Y
Could you please tell me what goes wrong here?
Thanks in advance :)
It looks like basic networking configuration issue. Psi client is not able to connect to the server. There may be multiple reasons:
Firewall blocking port.
Name of the machine you use to connect to cannot be resolve to proper IP address.
You should try connecting on that host on port 5222 from command-line, for example with telnet to check that you can open a TCP socket properly.
I establish a TCP connection between my server and client which runs on the same host. We gather and read from the server or say source in our case continuously.
We read data on say 3 different ports.
Once the source stops publishing data or gets restarted , the server/source is not able to publish data again on the same port saying port is already bind. The reason given is that client still has established connection on those ports.
I wanted to know what could be the probable reasons of this ? Can there be issue since client is already listening on these ports and trying to reconnect again and again because we try this reconnection mechanism. I am more looking for reason on source side as the same code in client sides when source and client are on different host and not the same host works perfectly fine for us.
Edit:-
I found this while going through various article .
On the question of using SO_LINGER to send a RST on close to avoid the TIME_WAIT state: I've been having some problems with router access servers (names withheld to protect the guilty) that have problems dealing with back-to-back connections on a modem dedicated to a specific channel. What they do is let go of the connection, accept another call, attempt to connect to a well-known socket on a host, and the host refuses the connection because there is a connection in TIME_WAIT state involving the well-known socket. (Stevens' book TCP Illustrated, Vol 1 discusses this problem in more detail.) In order to avoid the connection-refused problem, I've had to install an option to do reset-on-close in the server when the server initiates the disconnection.
Link to source:- http://developerweb.net/viewtopic.php?id=2941
I guess i am facing the same problem: 'attempt to connect to a well-known socket on a host, and the host refuses the connection'. Probable fix mention is 'option to do reset-on-close in the server when the server initiates the disconnection'. Now how do I do that ?
Set the SO_REUSEADDR option on the server socket before you bind it and call listen().
EDIT The suggestion to fiddle around with SO_LINGER option is worthless and dangerous to your data in flight. Just use SO_RESUSEADDR.
You need to close the socket bound to that port before you restart/shutdown the server!
http://www.gnu.org/software/libc/manual/html_node/Closing-a-Socket.html
Also, there's a timeout time, which I think is 4 minutes, so if you created a TCP socket and close it, you may still have to wait 4 minutes until it closes.
You can use netstat to see all the bound ports on your system. If you shut down your server, or close your server after forking on connect, you may have zombie processes which are bound to certain ports that do not close and remain active, and thus, you can't rebind to the same port. Show some code.
All connection attempts on RhodeCode on CentOS 6.3 are refused except from localhost.
Note that iptables is not running, and I am only trying to visit the web interface.
I have googled the exact error message below and looked around SO. I have yet to find a solution.
abort: error: No connection could be made because the target machine actively refused it
If the firewall is down, and I am not trying to modify any repository, what else is preventing me from connecting? EDIT: See #5 below. Not sure how to address it yet.
Things tried and other info
Using localhost, 127.0.0.1 and hostname in production.ini
service iptables stop
Connected over HTTP successfully. In other words, connections are accepted outside RhodeCode.
Made sure no authentication methods were enabled or configured in production.ini
Although the server accepts connections on localhost, netstat -l does not show that port 5000 is listening. Port 5000 is set in production.ini and ps uax | grep paster confirms the server is running. No other software tries to grab port 5000.
Ok, apparently I have been misunderstanding the host configuration. I was running on the assumption that host should be set to 127.0.0.1 or localhost in production.ini for RhodeCode to know what host to look for for another service. This was a faulty presumption on my part, since I am used to pointing web applications to local systems to look for databases.
It turns out that host binds the application to a specific address for access, meaning that it RhodeCode was supposed to only respond to local requests, regardless of what other system policies say. The setup docs did not make this clear because it did not specify that external connections would be refused. All it said was:
This command [paster serve] runs the RhodeCode server. The web app should be available at the 127.0.0.1:5000. This ip and port is configurable via the production.ini file created in previous step
The problem was fixed by binding RhodeCode to 0.0.0.0, which opened it to outside connections. Kudos to Łukasz Balcerzak for pointing this out in the RC support google group.
Socket Server with SSLStream some times refuses new connections from clients.
I used the telent hostname port, and it says Connecting To host...
Could not open connection to the host, on port 6002: Connect failed
I used netstat -a , and I see TCP status as
TCP 0.0.0.0:6002 host:0 LISTENING
I also see the service as listening in tcpview too.
The error I see on client side is connection refused with error code 10061.
The same socket server was accepting new connections and just runs fine without any issues.But after some time the above issue happens.its random.
When I restart the sockets it just works fine and accepts conenctions, which I don;t want to do it frequently.becasue this disconnects clients, who are already connected.
Could somebody help me to trouble shoot this?
Thanks.
Where are you running netstat? On the server?
Try connecting to the socket from localhost (from the server itself) using the destination IP address 127.0.0.1
Do the same test with the network IP of the server.
My guess is that the firewall is preventing external access or a router in between is preventing the connection.
It works for a while and then stops. Few options I can think of:
Some firewall on the way does some kind of throttling
You open and close too many connections too quickly. In this case you exhaust the ephemeral ports on the client (usually) and/or on the server. If you do netstat -a you will see a lot of sockets in TIME_WAIT state, try this both on client and server. Solution here is to reuse connections (best). Or increase the number of ephemeral ports (registry setting). But this will take you only so far.
You have a bug in your server and it stops accepting new connections after a while.