Robert said:
The current array read write process is very simple. The first loop
generates character strings which are appended to an array. At the
end of the loop, I call the read method whichs starts at the top of
the array, reads a line and flags it read and passes that value back
to the loop which may generate more data which gets sent to the write
method. The write method starts at the top of the array and writes
over any record flagged as read or gets appended to the bottom. The
order is not important since all records must be processed.
Sounds like a distributed queue.
I am looking for a class with simple methods that write to a remote
file or database so I can replace the single user array I'm using now.
I do not want to use jdbc. The data source can be another class, an
embedded database such as Berkely or even an executable as long as it
is easy to configure and doesn't require the investment of time that a
sql server would.
Here's the simplest solution I could think of:
It's a brain dead Servlet that takes its commands from the URL.
It has 3 commands:
add
next
reset
Add takes the argument and adds it to its internal queue.
Next returns the next item from the queue. If the queue is empty, it returns
the String "*EOL*".
Reset zeroes the queue.
The list is kept in memory within the Servlet container, and you lose all
your data when you reset the server.
The calls are synchronized, so there shouldn't be any race conditions.
---------
package pkg;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.LinkedList;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class Server extends HttpServlet
{
LinkedList queue = new LinkedList();
public void init()
{
System.out.println("Servlet init.");
}
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
response.setContentType("text/html");
String next = request.getParameter("next");
String add = request.getParameter("add");
String reset = request.getParameter("reset");
if (next != null) {
Object top = "*EOL*";
synchronized(this) {
if (queue.size() > 0) {
top = queue.removeFirst();
}
}
response.getWriter().println(top);
}
if (add != null) {
synchronized(this) {
queue.add(add);
}
response.getWriter().println("OK");
}
if (reset != null) {
synchronized(this) {
queue = new LinkedList();
}
response.getWriter().println("OK");
}
}
}
And here's a simple test client.
package pkg;
import java.net.*;
import java.io.*;
public class TestClient
{
public static String host = "localhost";
public static int port = 8080;
public static String baseURL = "/server/items";
public static void main(String args[])
throws Exception
{
for (int i = 0; i < 50; i++) {
addItem("" + i);
}
// Get more than we put in to demonstrate *EOL*
for (int i = 0; i < 53; i++) {
System.out.println(getItem());
}
}
public static void addItem(String item)
throws Exception
{
String encodedItem = URLEncoder.encode(item, "UTF-8");
URL url = new URL("http", host, port,
baseURL + "?add=" + encodedItem);
Object o = url.getContent();
}
public static String getItem()
throws Exception
{
URL url = new URL("http", host, port,
baseURL + "?next");
BufferedReader br = new BufferedReader(new
InputStreamReader(url.openStream()));
String s = br.readLine();
return s;
}
}
Now, as you can imagine, this was hacked out very quickly.
What are the downsides of this technique? Well, for one, it probably tears
the socket up and down for each call to the server, but playing with the
URLConnection, fiddling with Keep-Alive and reusing a single connection
directly may well eliminate that.
It's a bit excessive for sending a string back and forth in terms of
overhead. That's the price you pay for an application specific protocol
layered on top of a general purpose protocol.
However, it is brain dead to set up. Get a binary install of Tomcat, and
plop it anyplace convenient on most any machine on the planet. You can email
me and I'll send you a zip of the entire build tree (4 files -- build.xml,
web.xml, Server.java, TestClient.java). Install Ant to build it.
And if your compute time is your bottleneck, this technique is essentially
"free".
It's also as customizable as you want it to be. You get to run down the
slippery slope of creating your own application protocol.
You can add persistence if you like, whatever. Read up on the Servlet spec
to fill in the blanks.
All said, I think JDBC and a RDBMS is a better solution, but if all you need
is what you specified, then this will do just that.
Like I said, if you want the build tree for the webapp, then you need just
add Tomcat and Ant and you're on your way to server bliss.
Good Luck!
Regards,
Will Hartung
(
[email protected])
