This question already has an answer here:
Using special auto start servlet to initialize on startup and share application data
(1 answer)
Closed 7 years ago.
I am using jetty server to receive calls from http clients.
I am using BufferedWriter object to write a log file for debugging.
The server is always running in order to receive calls.
How can i tell the program to only close the stream (log_file.close) when the server stops?
I am not supposed to stop the server, but before the program terminates (when i touch the terminate button for example) how can i close the stream file in that point?
If your code is running inside a web application (aka war) you can (and it's actually a best practice) to implement ServletContextListener and register it in your web.xml.
In contextInitialized you can make the necessary init operations.
In contextDestroyed you can close the stream.
If you are running Jetty embedded, then you have a couple of options.
You haven't indicated which version of Jetty, so I can't give you exact code for it, but your options are:
Register a "LifeCycle" object in the server, and implement a stop method in that lifecycle object that closes your log file. (Using something like addLifeCycle or addBean, depending on your Jetty version)
Add a shutdown thread in the JVM (Runtime.addShutdownHook)
Related
I am using Jetty 8 in blocking I/O mode. The servlet doPost reads the request content from the request InputStream (which is actually an instance of Jetty HttpInput).
What if a client sends a very large request and does it very slowly ? Obviously, it will take a lot of time to read the request. So, I would like to cancel the reading after a few seconds and send an error response to the client. How can I do that without much changes i.e. using Jetty with blocking I/O and without continuation ?
Jetty 9+ answer
Use HttpServletResponse.sendError(-1) to terminate the connection.
Original Jetty 8 answer
Write a ServletFilter that does the detection of the slow request.
When you determine it is slow, ...
Obtain a reference to the current connection via a call to AbstractHttpConnection.getCurrentConnection()
Get a reference to the EndPoint via AbstractHttpConnection.getEndPoint()
Call EndPoint.close()
Also, look into the QoSFilter, it does a lot of this kind of stuff already.
My application is allowed to have multiple instances running and I would like to log events from all running instances. I am currently using java util logging's socket handler to centralize the logging process. When the first instance starts, it also a starts a new socket server thread. The problem is when this instance is closed, the server thread is also closed and log method (from another instance) throws exception. I am not thinking to run it as a separate process (using Runtime exec) because I would not be able to shut it down gracefully from my application.
So is there a way where another instance on seeing the server down, create a new server thread? This similar approach is being done in H2 database AUTO_SERVER mode where it automatically switches to client and server mode.
So any suggestions on how to do this?
I ended up using Logback's prudent mode.
I think that you might need a singleton with a factory method to initialize the socket server if it is not already running:
Searching memcached java in google, the first result is Using Memcached with Java.
The guy (who calls himself Just some Random Asshole in the Internet!) proposes a Singleton based on net.spy.memcached. It basically creates 20 threads and connections by creating 20 instances of MemcachedClient. For every request it chooses one at random.
However those threads and connections are never closed and they pile up every time I hot swap the application during development (with warnings from Tomcat 7).
SEVERE: The web application [/MyAppName] appears to have started a thread named
[...] but has failed to stop it. This is very likely to create a memory leak.
By looking at MemcachedClient JavaDoc, I see a method called shutdown with the only description being "Shut down immediately." Shut down what? The client? The server? I suppose is the client, since it's in MemcachedClient and I suppose that this method would close the connection and terminate the thread. EDIT: yes, it shuts down the client.
Question 1 How to force the execution of cleanup code in Tomcat 7, before the application is hot swapped?
Question 2 Is this approach of using memcached (with cleanup code), correct or is better I start over in a different way?
I think creating 20 memcache clients is silly - that's like creating 20 separate copies of your DB connection pool. The idea with that client is that it multiplexes a variety of requests with asynch IO.
http://code.google.com/p/spymemcached/wiki/Optimizations
As far as shutting it down, simply call:
yourClient.shutdown() to shutdown immediately, or
yourClient.shutdown(3, TimeUnit.SECONDS) for example, to allow some time for a more graceful shutdown.
That could be called from your Servlet's .destroy method, or a context listener for your whole WAR.
I don't know anything about memcached, but you could probably write a custom context listener and put some kind of shutdown hook in the context listener so that when the context shutdown you could loop through the items in your singleton and shut them down.
It turned out that it was a bug of Java AWS SDK and was not related to memcached. Version 1.2.2 of Java AWS SDK has this bug fixed.
I like to write a little server application being controlled by a little console app (start, pause, stop, etc). For the server spring should be used (part of it already exist). So what I do to start the server is something like this:
start a server thread and exit main method
and then, in the thread:
load application context from xml
start some worker threads connecting to beans doing stuff
Now I want the server to be stopped by another command. How can I connect to the already running context and shut it down?
Thanks for your help,
Alexander
The classical way to manage running Java code is through JMX.
Spring lets you export beans as MBeans.
And for accessing JMX via the command line, look at the answers to this recent question:
Calling JMX MBean method from a shell script
You could create a pid file, when the server starts, it should log the pid to a file, server.pid. When you do a stop, you can read the process and kill it. Or even simpler, have a ever running thread in your main class which keeps looking for a file in some folder. As soon as the file becomes available or gets modified, it will stop the server.
I've written a very simple server that accepts socket connections on a specific port
and communicates with clients over that socket.
Now I have a client lib which works perfectly fine in J2SE apps.
However, if I try to use that lib in a Servlet (the Servlet being the client) to communicate with the server it doesn't work.
Unfortunately there is no Exception or something that could help me.
Instead when using the lib simply nothing happens.
That is the call to the method within which the socket is opened just blocks indefinitely
while no connection is made to the server.
I reckon this could be a general problem.
Maybe things like that are not allowed from within a Servlet?
But even if not I would at least expect that some Exception to be thrown.
The Servlet Container is Tomcat by the way.
Has anyone got an idea as to why this doesn't work?
Ok here is there actual problem:
It seems to be a difference in behaviour between Windows and Linux.
I developed the server + lib under Linux while Tomcat runs on a Windows machine.
Among other things the server I told you about executes a command
via ProcessBuilder.
What actually blocked indefinitely was the Process#waitFor.
That is under Windows. Under Linux it works just fine and returns as soon as the process is finished.
Under Windows however Process#waitFor only returns when I read the Process's InputStream for some reason.
Sorry!