THREADS - SOCKETS

Z

zamba

Hi everybody. I have this problem:
i have a Thread class wich writtes in sockets to make a connection
with another class is waiting requests.The server classes transforms
xml to pdf files , the problem is that the process is too slow because
there are threads wich start another threads...so the operative system
put jobs in queues and all the process gets very slow . Maybe exists
another way to limit number of threads or that they wait between them
to optimice the use of processors...these are my classes....thank
you !!! im running on solaris 10 enviroment.

server classes :


package formatterservice;

import java.io.IOException;
import java.net.*;


/**
*
* @author adam
*/
public class Server {

/** Creates a new instance of Main */
public Server() {
}

/**
* @param args the command line arguments
*/
public static void main(String[] args) {
final int serverPort = 20202;

if (args.length >= 1) {
// try to set serverPort from an argument
}
long connNum = 0;
try {
ServerSocket ssock = new ServerSocket(serverPort);
System.out.println("server opened port: " + serverPort);

while (true) {
Socket sock = ssock.accept();
++connNum;

System.out.println("client " + connNum + " has
connected.");

OneConnection client = new OneConnection(sock,
connNum);

new Thread(client).start();


}
} catch (Exception ex) {
ex.printStackTrace();
}
}

}



/*
* OneConnection.java
*
* Created on April 4, 2008, 12:37 PM
*
* To change this template, choose Tools | Template Manager
* and open the template in the editor.
*/

package formatterservice;

import java.io.*;
import java.net.*;
import jp.co.antenna.XfoJavaCtl.*;

/**
*
* @author adam
*/
public class OneConnection implements Runnable {
Socket sock;
BufferedReader in = null;
BufferedWriter out = null;
final long connNum;
XfoObj axfo;

/** Creates a new instance of OneConnection */
public OneConnection(Socket sock, long connNum) throws Exception {
axfo = new XfoObj();
axfo.setExitLevel(4);
axfo.setStylesheetURI("91.xsl");
axfo.setOutputFilePath("result-" + connNum + ".pdf");
axfo.setExternalXSLT("Xalan -o %3 %1 %2");
this.sock = sock;
this.connNum = connNum;
in = new BufferedReader(new
InputStreamReader(sock.getInputStream()));
out = new BufferedWriter(new
OutputStreamWriter(sock.getOutputStream()));
}

public void run() {
try {
// Process with Formatter
String filename = in.readLine();
System.out.println(connNum + ": " + filename);
axfo.setDocumentURI(filename);
axfo.execute();

// out.write("result-" + connNum + ".pdf");
// out.write("\n\r");
// Close the socket
sock.close();
System.out.println(connNum + " finished.");
} catch (Exception e) {
e.printStackTrace();
}
}
}
 
E

EJP

Conversion to PDF is a CPU-intensive process. Use a ThreadPoolExecutor
to control the number of accepted threads that can actually execute at
once. I can't see where the secondary threads are created - is that
inside XfoObj.execute()?

BTW don't close the socket, close the BufferedWriter.
 
M

Martin Gregorie

Hi everybody. I have this problem:
i have a Thread class wich writtes in sockets to make a connection with
another class is waiting requests.The server classes transforms xml to
pdf files , the problem is that the process is too slow because there
are threads wich start another threads...
A quick glance shows that you start a processing thread for each incoming
connection and don't kill the thread/close the socket until the result has
been sent back to the user. This will flood the system with a thread for
each simultaneous user and probably look slow to all of them as a result.
Worse, its an inflexible solution and one that can't be tuned.

I'm not sure how I'd do the job, but almost certainly not the way
you have. In the absence of information about the size of the user
population, file sizes, processing time and how long a user will wait
between submitting a file and getting the response I'd probably
split it up (see below) because such a solution can be tuned fairly easily:

Job input:
Each connecting user starts a thread that accepts the file,
queues it for processing and returns an acknowledgement.
The client closes the connection and displays the acknowledgement.
The thread dies when its connection is closed.

Processing:
A small pool of threads are created at server startup.
Each is idle unless there's work to be done.
While there's a file in the queue one of the threads processes
it, removes the input from the inbound queue and adds the
result to the outbound queue.

Results output:
A small pool of threads are created at server startup.
Each is idle unless there's output to be returned.
As results appear in the outbound queue one of the threads
mails the result file back to the user and removes the
results from the queue.

Management:
Each queue probably needs a dispatcher thread to spot new
items and hand them to the appropriate thread if one is
available.

The input section should probably handle queries about
queue sizes, and job progress and deal with shutdown
requests etc. as well as just accepting input.

Tuning:
- Input threads will never live long so their population will match
the (probably small) population of simultaneous job submitters. This
should not cause problems.

- The processing thread count is independent of the user population and
can be adjusted to give an acceptable trade-off between turn-round times
and cpu usage.

- The output thread population only needs to be big enough to keep up
with the processing threads. Javamail is pretty efficient, so its
unlikely that you'd need more output threads than processing threads.

A scheme like this can put the queues on disk for resilience or keep them
in memory for speed.

The three logical tasks can be part of one large server or be split into a
set of three co-operating servers: your choice. Either way the thread
populations should be configurable.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top