QueuedThreadPool: WebSocketClient#122503328{STOPPING,8<=8<=200,i=5,q=7} Couldn't stop Thread[WebSocketClient#122503328-1556,5,main]
QueuedThreadPool: WebSocketClient#122503328{STOPPING,8<=8<=200,i=4,q=7} Couldn't stop Thread[WebSocketClient#122503328-1557,5,main]
QueuedThreadPool: WebSocketClient#122503328{STOPPING,8<=8<=200,i=4,q=7} Couldn't stop Thread[WebSocketClient#122503328-1560,5,main]
QueuedThreadPool: WebSocketClient#122503328{STOPPING,8<=8<=200,i=4,q=7} Couldn't stop Thread[WebSocketClient#122503328-1561,5,main]
QueuedThreadPool: WebSocketClient#122503328{STOPPING,8<=8<=200,i=4,q=7} Couldn't stop Thread[WebSocketClient#122503328-1563,5,main]
The above warning log is seen repeatedly and system performance is impacted when we try to stop the client using WebSocketClient stop() method. The stop timeout is set to 0.
This is occurring when server application on 3rd party machine is down and connection is refused since no server is listening on destination port. Connect Exception is seen in onError callback.
This warning is seen even if disconnect and close are done from a different thread than the client thread.
That's because you are using a Thread from the ThreadPool to attempt to stop that same thread pool.
Don't call .stop() from a Jetty thread.
Schedule the stop on a new thread of your own making.
Related
I have installed one J2EE application in Websphere ND 8.5.5.9 on a IBM AIX 7.2 server.
While installing application, I have skipped the Queue setup by giving the dummy values to it. Then, Listener port issue came up, as the queue was trying to connect to dummy setup. This way the connection pool was full and system started giving exceptions. So, I re-installed the application and kept the Listener port in STOP mode. First few hours application ran as expected. Now, it is giving below exceptions:
[5/23/18 17:29:53:609 CEST] 000000a9 FreePool E J2CA0045E: Connection not available while invoking method createOrWaitForConnection for resource jdbc/"".
[5/23/18 17:31:12:899 CEST] 00000055 FreePool E J2CA0045E: Connection not available while invoking method createOrWaitForConnection for resource jdbc/"".
[5/23/18 17:31:12:900 CEST] 00000055 AlarmThreadMo W UTLS0009W: Alarm Thread "Non-deferrable Alarm : 0" (00000055) previously reported to be delayed has now completed. It was active for approximately 180004 milliseconds.
[5/23/18 17:32:11:191 CEST] 00000029 AlarmThreadMo W UTLS0008W: The return of alarm thread "Non-deferrable Alarm : 2" (00000057) to the alarm thread pool has been delayed for 18271 milliseconds. This may be preventing normal alarm function within the application server. The alarm listener stack trace is as follows:
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:201)
at com.ibm.ejs.j2c.FreePool.queueRequest(FreePool.java:438)
at com.ibm.ejs.j2c.FreePool.createOrWaitForConnection(FreePool.java:1344)
at com.ibm.ejs.j2c.PoolManager.reserve(PoolManager.java:3898)
at com.ibm.ejs.j2c.PoolManager.reserve(PoolManager.java:3118)
at com.ibm.ejs.j2c.ConnectionManager.allocateMCWrapper(ConnectionManager.java:1548)
at com.ibm.ejs.j2c.ConnectionManager.allocateConnection(ConnectionManager.java:1031)
at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:646)
at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:924)
at com.ibm.ws.extensionhelper.db.impl.DatabaseHelperImpl$DSWrapper.getConnection(DatabaseHelperImpl.java:1595)
at com.ibm.ws.extensionhelper.db.impl.DatabaseHelperImpl.getConnection(DatabaseHelperImpl.java:750)
at com.ibm.ws.leasemanager.impl.LeaseManagerDBHelper.getConnection(LeaseManagerDBHelper.java:213)
at com.ibm.ws.leasemanager.impl.LeaseStoreImpl.renew(LeaseStoreImpl.java:452)
at com.ibm.ws.leasemanager.impl.LeaseImpl.renew(LeaseImpl.java:141)
at com.ibm.ws.scheduler.LeaseAlarm.alarm(LeaseAlarm.java:173)
at com.ibm.ejs.util.am._Alarm.runImpl(_Alarm.java:151)
at com.ibm.ejs.util.am._Alarm.run(_Alarm.java:136)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1892).
Please suggest what can be done to free the connection pool without making any code changes. Is it possible to handle it on OS level or Websphere level?
The last of the warnings with the 18 second wait is for a connection attempt that is made by the WAS scheduler. You should look in your configuration to see if the scheduler is configured to use the same data source, jdbc/"" (which is an unusual name - is this data source configured properly?) as the prior errors. There are a couple of possibilities for the cause behind theses errors/warnings. You could have a connection pool that is insufficiently sized to handle the load that your application requires, or you could have code that is holding onto connections for too long, starving out the other users of the data source.
As golang http package document saying, http.Server will not close until all handler finished after Shutdown() called. If handler take too long time, context will expires, and Shutdown() returns a error. What should I do for forcing handler to return immediately when server.Shutdown() has been called? Will Context().Done() of http.Request be closed after server.ShutDown() has been called?
No. If you read the docs, it explains exactly what Shutdown does, saying explicitly that it does not interrupt active connections (emphasis added):
Shutdown gracefully shuts down the server without interrupting any active connections. Shutdown works by first closing all open listeners, then closing all idle connections, and then waiting indefinitely for connections to return to idle and then shut down. If the provided context expires before the shutdown is complete, Shutdown returns the context's error, otherwise it returns any error returned from closing the Server's underlying Listener(s).
I made a UDP server class and my program creates a process (running in the background). It is a command line utility, and so running 'udpserver.exe start' would bind the socket and begin a blocking recvfrom() call inside a for(;;) loop.
What is the best way to safely and 'gracefully' stop the server?
I was thinking about 'udpserver.exe stop' would send a udp msg such as 'stop' and the ongoing process from 'udpserver.exe start' would recognize this msg, break from the loop, and clean up (closesocket/wsacleanup).
Also, is just killing the process not a good idea?
Why are you running the UDP server as an external process instead of as a worker thread inside of your main program? That would make it a lot easier to manage the server. Simple close the socket, which will abort a blocked recvfrom(), thus allowing the thread to terminate itself.
But if you must run the UDP server in an external process, personally I would just kill that process, quick and simple. But if you really want to be graceful about it, you could make the server program handle CTRL-BREAK via SetConsoleCtrlHandler() so it knows when it needs to close its socket, stopping recvfrom(). Then you can have the main program spawn the server program via CreateProcess() with the CREATE_NEW_PROCESS_GROUP flag to get a group ID that can then be used to send CTRL-BREAK to the server process via GenerateConsoleCtrlEvent() when needed.
I have the following error showing up in AMQERR01.LOG
AMQ9999: Channel 'MGATESrvChannel' to host 'Mgate (127.0.0.1)' ended
abnormally.
EXPLANATION:
The channel program running under process ID 1060(4364) for channel
'MGATESrvChannel' ended abnormally. The host name is 'Mgate (127.0.0.1)'; in
some cases the host name cannot be determined and so is shown as '????'.
This error is preceded with following message:
AMQ9508: Program cannot connect to the queue manager.
EXPLANATION:
The connection attempt to queue manager 'MGATE.QM' failed with reason code
2059.
ACTION:
Ensure that the queue manager is available and operational.
According to what I have been told this can be caused by an application that is using queue manager, however, it seems to me that this has more to do with the way that manager was set up or similar. Can anyone please shed some light on this?
Thanks in advance!
The 2059 says that a connection request was received and refused because the QMgr was not available. We used to see this a lot when the listener was run as a separate process or when inetd was used to start channels. This is because the listener was there to accept the connection but the QMgr processes were not.
Now that the listener is run as a child process of the QMgr, it is quite rare to see this on the WMQ error logs though clients commonly see it. This is because when the listener is run as a child process of the QMgr, there is nothing listening to receive the connection request and it bounces off of the host's IP stack before ever getting to MQ code.
The AMQ9999 message says that a channel program, one of the QMgr's child processes, died or was killed and this caused the channel to terminate. There are many reasons for a channel process to die including being killed by the OS if resources are short, or being killed by a human operator. Other than that the most common way they can die due to running in trusted or fastpath mode and the attached program corrupts them.
It would help to narrow down the field to know the details of the QMgr in question - version and fix pack, how the listeners are started, channel settings, etc.
Start your listener up, you may check the Control property for that channel, so it start up automatically when the Queue Manager restart.
I was just wondering if it is possible to interrupt call to windows socket "connect" function?
The problem is that my code requires that to be done in a different thread (so GUI thread keeps running). But when the programm is closed there my still be threads calling "connect" that are wating for a WSAETIMEDOUT exception.
Any ideas?
Update/Hint: i cant call close() since i only have a valid handle when connect() returns. the latter one is not the case when using blocking sockets and having a tcp-connect to a firewalled location (for example) :/
If the socket is in blocking mode, the only way to abort connect() call is to close the socket from a different thread context than the one that is calling connect(). connect() will return an error, and the thread can then exit itself normally.
If the socket is in non-blocking or overlapped mode, connect() will return immediately with a WSAEWOULDBLOCK error, and you then have to call select(), WSAAsyncSelect(FD_CONNECT), or WSAEventSelect(FD_CONNECT) to detect when the connection has been established before continuing with your socket work. Since the calling thread is not blocked on connect(), it is free to periodically check for any termination/abort signals from the rest of your code, and if detected then close the socket (if needed) and exit itself normally.
If you write your socket code in non-blocking or overlapped mode, then you do not really need to use a thread. You can do your socket work within the main thread without blocking your UI, then you can just close the socket when needed. It takes a little more work to code that way, but it does work. Or you can continue using a thread. It will keep your socket code separate from your UI code and thus a bit more managable.