When I start the server 'sails lift', it shown
debug: --------------------------------------------------------
debug: :: Mon May 05 2014 10:59:17 GMT+0700 (ICT)
debug:
debug: Environment : development
debug: Port : 1337
debug: --------------------------------------------------------
info: handshake authorized AUcEOqQtYzXw0jBMiSbp
info: handshake authorized t9Y7k4zozlyXd1nwiSbq
info: transport end (socket end)
info: transport end (undefined)
I wonder what are those last two lines?
info: transport end (socket end)
info: transport end (undefined)
TL;DR: If you don't want to see those messages, close any open pages / tabs that were connected to your Sails app before you re-lift it.
Those messages are coming from socket.io. It appears that you're lifting Sails with two open tabs / windows that were formerly connected via websockets to a running Sails instance, and reconnected once the server started again. However, something unexpected happened after the sockets reconnected, and they closed their connection. This can happen for any number of reasons; for example, an old socket connection may try to reconnect and resume a session which no longer exists, if you're using the memory store for sessions in Sails (which is the default for development mode). It's nothing to be concerned about; just make sure you refresh your pages after restarting Sails and all should be well. It's pretty rare that you'll need to maintain state for a web page between server reboots, but if you do, you can do it with a combination of the onConnect and onDisconnect methods in config/sockets.js and some front-end logic.
Related
When I try to hit my site, I am getting the following error:
Error Tue May 10 16:54:40 IST 2016 1462879480679
/atg/endeca/assembler/droplet/InvokeAssembler A problem occurred
assembling the content for content item /content/Web/Home Pages. The
response received was {previewModuleUrl=http://localhost:8006/ifcr,
#type=ContentSlot, atg:currentSiteProductionURL=www.local.com:7103,
canonicalLink=com.endeca.infront.cartridge.model.NavigationAction#49dded95,
ruleLimit=1, #error=com.endeca.infront.content.ContentException:
com.endeca.navigation.ENEConnectionException: Error establishing
connection to retrieve Navigation Engine request
'http://localhost:15000/graph?node=0&profiles=NoPriceRange|site&offset=0&nbins=0&merchdebug=1&irversion=640'.
Tried all: '2' addresses, but could not connect over HTTP to server:
'localhost', port: '15000' Check MDEX Logs and specified query
parameters. , contentCollection=/content/Web/Home Pages}. Servicing
the error open parameter.
When I try to access EAC Admin Console to restart MDEX Engine, it is not getting loaded. Why that might be?
Ensure your endeca servers are running. Try to access localhost:8500/cas?wsdl
Is the Dgraph port provided as 15000 in all configurations?
I'm getting "Socket Error #10060, Connection timed out" when trying to access a https link.
Here is how you can reproduce it with INDY 10.6.2.0 and OpenSSL 1.0.2d DLLs (also happens with older Indy 10 version and dlls):
create a project and add a TButton, TIdHTTP and TMemo objects to the form
add to button onclick this code:
IdHTTP1.Request.UserAgent:='Indy';
IdHTTP1.HandleRedirects:=true;
Memo1.text:=IdHTTP1.Get('https://www.itv.com');`
now compile and run it, it will download correctly the file.
BUT if you are using a service like www.smartydns.com which redirects DNS request to their server, INDY sample above will not work and fail with "Socket Error #10060, Connection timed out" message.
Have tried it with WGET too (https://eternallybored.org/misc/wget/) and in version 1.13 its initializing the SSL handshake and freezes, but works without problems with version 1.15.
So the question is, what IdHTTP settings do I have to use to make it work, or is it a bug in Indy10 ?
client:
socket(), connect() and then
for (1 to 1024) {
write(1024 bytes)
}
exit(0);
server:
socket(), bind(), listen()
while (1) {
accept()
while((n = read()) {
if (n == -1) abort(); /* never happended */
total_read += n
}
close()
}
now, client runs on Mac under NAT and server runs on my VPS (abroad)
generally, it works fine (client send all data and exit & server recv all data)
however, when client is running but suddenly the network is broken for couple minutes(and regain), the client won't exit after a long long time... I kill it with control + C and run it again, the server seems not read the data any more (client is still running)
here is what netstat shows:
client:
tcp4 0 130312 192.168.1.254.58573 A.B.C.D.8888 ESTABLISHED
server:
tcp 0 0 A.B.C.D:8888 a.b.c.d:54566 ESTABLISHED 10970/a.out
tcp 102136 0 A.B.C.D:8888 a.b.c.d:60916 ESTABLISHED -
A.B.C.D is my VPS address
a.b.c.d is my public client address
my quesiton is:
1, why ?
2, server will works fine after restarting, how to write code to get rid of it without restarting ?
In TCP, there's no way to tell that a connection has failed unless you try to send something on the connection. TCP doesn't perform active monitoring of the connection (actually, there are optional "keepalive" packets, but these are not normally sent until the connection has been idle for a couple of hours). When you send something, you'll eventually get an error if there's a timeout waiting for the other machine to return an acknowledgement. But if you're just reading data without sending, you can't tell that the connection has failed -- it just looks like the sender doesn't have anything to send.
You can resolve this by designing your application so that the client is required to send something every N seconds. Then set a timer in the server that detects that you haven't received anything for more than N seconds (you should add a little extra time to allow for transient delays).
When the network is broken what happens is that you clients keep sending data and at some point the socket send buffer gets full (I understand from what you show that you are sending 1024 Bytes, 1024 times, 1MB in total). The default for send buffer could be 16KB (surely less than 1MB). Then when the client tries to write, it gets blocked forever.
BTW, now I'm answering your question I don't know whether eventually after a number of TCP timeouts, TCP gives up and closes the socket making the socket interface return with error. I think that's not happening ... :) - So, connect fails if there is a problem in the network but write and read do not fail.
In the server side, the server gets blocked in read because it never receives the EOF.
Solution:
In the client side use non-blocking sockets, if the network is broken, at some point write will return with error EWOULDBLOCK. Then you will realize the send buffer is full for some reason. At that point, you could clouse the connection and try to connect again. If the network is broken, you will receive an error.
In the server side also use non-blocking sockets and select() function with a timeout. After a few timeouts you may decide there is a problem with the new connection and close it.
I'm a little bit confused with the following case.
I've got a Postgres server running on host A, and a java based client running on host B. The client uses org.postgresql.Driver JDBC driver (version 9.1-901.jdbc3).
sometimes while executing long running stored procedure I get exception "java.net.SocketException: Socket closed". I'm using org.apache.commons.dbcp.BasicDataSource for retrieving
connections.
DBCP pool is configured with default options.
I got tcp dump in order to figure out on which side (client or server) socket is being closed;
Here is what I've got:
1. Client B sends a test query message when tries to borrow connection from dbcp pool ("Select 1")
2. Server A sends successful response back (Type: Command completion, Ready for query)
3. Client B sends ACK message in response on server A response (see the item 2).
4. Client B sends query message to the server A.
5. Server A sends ACK message in response on client Query message (see the item 4).
6. Client B sends terminating message (Type : Termination) after some time passed (from 3 to 10 or sometimes even more minutes).
7 Client B sends FIN ACK message to the server.
8. Server A sends back ACK on termination message.
9. Server A sends ACK on (FIN, ACK) message (item 7).
10. Server A sends back a response on the client query (from item 4) Type: Row description Columns: 40.
11. Client B sends RST message (reset).
12. Server A continues sending response on the query Type: Data row Length: 438 Columns 40 and so on.
13 Client B sends RST message (reset) again.
14. Server A continues sending response on the query Type: Data row Length: 438 Columns 40 and so on.
15. Client B sends RST message (reset).
After that communication seems to be finished.
After the item 6, in my client logs I got Exception like the following:
Caused by: java.net.SocketException: Socket closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:145)
at org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:114)
at org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73)
at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:274)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1661)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
Could you please help me to figure out the reason of such a failure. (This bug happens once per 10 successful cases.)
We had a similar problem, and it was caused by a firewall or connection tracking router between the server and the client.
I am guessing you took the tcpdump on the server side. The query runs for a considerable time with no traffic on the connection. The firewall has a timer on the open connection; it expires and the firewall closes the connection towards the server, and also back towards the client. On the capture at the server side, it looks like the client is closing the connection.
You could verify this by capturing on the client side simultaneously as you capture on the server side - on the client side it will look like the server has closed the connection, while on the server side it looks like the server is closing the connection. In reality the firewall is closing it in both directions.
To prevent this, you can set tcp_keepalives_idle, tcp_keepalives_interval and/or tcp_keepalives_count (if your OS supports TCP Keepalives). Alternatively, you will have to change the settings on the firewall.
I just installed Jabber plugin for my Jenkins last week.
I have a XMPP server running for quite a long time, and there is no connection problem
From Jenkins log, I got some error "Jabber notifier plugin: There was an error sending notification to.
But this error does not happen all the time, it just pop up sometimes and disappeared after a while. And I cannot see anything wrong from Jenkins' log. and there is nothing generated after I created a system log for
hudson.plugins.jabber
as "FINEST" log level.
Nov 27, 2013 11:49:15 AM hudson.plugins.jabber.im.transport.JabberIMConnection
createConnection
INFO: Trying to connect to XMPP on <our_server>:5222/<our_server> with SASL
Nov 27, 2013 11:49:15 AM hudson.plugins.jabber.im.transport.JabberIMConnection
setupSubscriptionMode
INFO: Accepting all subscription requests
Nov 27, 2013 11:49:15 AM hudson.plugins.jabber.im.transport.JabberIMConnection connect
INFO: Connected to XMPP on <our_server>/<our_server> using TLS
Anyone knows if this is some stability issue with this plugin? Is there any way for me to do debug to see what exactly happened when this error pop up?
Thanks!