THREADS - SOCKETS

Discussion in 'Java' started by zamba, Apr 9, 2008.

  1. zamba

    zamba Guest

    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();
    }
    }
    }
     
    zamba, Apr 9, 2008
    #1
    1. Advertising

  2. zamba

    EJP Guest

    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.
     
    EJP, Apr 9, 2008
    #2
    1. Advertising

  3. On Wed, 09 Apr 2008 05:20:36 -0700, zamba wrote:

    > 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.


    --
    martin@ | Martin Gregorie
    gregorie. |
    org | Zappa fan & glider pilot
     
    Martin Gregorie, Apr 9, 2008
    #3
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. wEEdpEckEr
    Replies:
    1
    Views:
    459
    _XaToA_
    Jan 3, 2004
  2. RA
    Replies:
    2
    Views:
    360
    rajatag
    Jan 27, 2006
  3. Jupiter5F

    Threads and Sockets

    Jupiter5F, Nov 14, 2003, in forum: C++
    Replies:
    4
    Views:
    2,328
    Jupiter5F
    Nov 14, 2003
  4. Julia Goolia

    tkinter, sockets and threads together

    Julia Goolia, Sep 11, 2003, in forum: Python
    Replies:
    4
    Views:
    552
    Steve Holden
    Sep 12, 2003
  5. Gonçalo Rodrigues

    Help needed in problem with Threads and sockets.

    Gonçalo Rodrigues, Dec 29, 2003, in forum: Python
    Replies:
    0
    Views:
    289
    Gonçalo Rodrigues
    Dec 29, 2003
Loading...

Share This Page