WebSphere server and Jetty client with java.lang.illegalstateexception state==header

Question

I have 2 packages - 1 Server to maintain in traditional Web Server (Tomcat 6, Websphere 7) and 1 with on-the-fly web server Jetty, which works as a client. The server and Agent work perfectly locally on Windows 7 machine and JRE 6: (1) The server is loaded to Tomcat. (2) The Agent initializes Jetty 8 web server with custom port.

When I put it in production - Linux environment - I loaded the WAR to WebSphere, which seems to work fine. I executed the Agent jar in production using 'jave -jar' and it seems to work. After they comunicate - if fails on 'java.lang.illegalstateexception: state==header' exception, failing with the Agent.

Now, I referenced the WebSphere production application to my local machine, and all the communication works fine (Agent locally with Windows 7, server remotely on Linux).

So, it seems there's an issue with the Agent (or with its internal Jetty), code goes like this:

         private void respondOK(Request baseRequest, HttpServletResponse response)
        throws IOException {
    response.setContentType("text/html;charset=utf-8");
    response.setStatus(HttpServletResponse.SC_OK);
    baseRequest.setHandled(true);
    response.getWriter().println("OK");
}

private boolean handleAgentMonitoringTasks( 
                                    Request baseRequest,
                                    HttpServletRequest request,
                                    HttpServletResponse response) {
    boolean didRespond = false;

    // extract the agent data   
    try {
        String reqContent = readRequestContent(baseRequest);

        // handle the input
        theAgentWorker.updateTasksList(reqContent);

    } catch (IOException e) {
        // send a response indicating the error
        respondError(baseRequest, response, "Error getting request content - " + e.getMessage(), e);
        didRespond = true;
    }


    return didRespond;
 }


 private boolean handleServerInfo(  Request baseRequest,
                                    HttpServletRequest request,
                                    HttpServletResponse response) {

    boolean didRespond = false;

    // extract the request content
    try {
        String reqContent = readRequestContent(baseRequest);

        if (reqContent.length() > 0) {
            try {
                theAgentWorker.handleServerInfoData(reqContent);
            }
            catch (Exception e) {
                respondError(baseRequest, response, "Error setting server information - " + e.getMessage(), e);
                didRespond = true;
            }
        }
        else {
            respondError(baseRequest, response, "Server address not found in the request", null);
            didRespond = true;              
        }

    } catch (IOException e) {
        // send a response indicating the error
        respondError(baseRequest, response, "Error getting request content - " + e.getMessage(), e);
        didRespond = true;
    }

    return didRespond;
 }


private String readRequestContent(Request baseRequest) throws IOException {
    BufferedReader br = baseRequest.getReader();
    StringBuilder sBuilder = new StringBuilder();
    char[] buff = new char[4092];

    int charsRead = br.read(buff, 0, buff.length);
    while (charsRead == buff.length) {
        sBuilder.append(buff);
        charsRead = br.read(buff, 0, buff.length);
    }
    sBuilder.append(buff,0, charsRead);
    return sBuilder.toString();
}

All the above code goes into this class: public class AgentHttpHandler extends AbstractHandler

AbstractHandler is Jetty's handler class.

When I researched it, I found out that there are issues with getReader() and getInputStream() from Jetty, but I couldn't find a reasonable explanation why it is unstanble - in Windows 7 the Agent works fine, and on Linux it has issues (I tried several Linux servers).

Do you know about certain Linux network issues with Jetty WebServer? I have more info, but I think that this info should be enough

Answer 1

OK, for whom it may concern:

I decided to go over ALL WebSphere configurations - and I defined a virtual host with TCP chaining and a new port. Then, I recompiled all the packages with a new ant build.

Afterwards (and this is the most important part) - I defined the urls mentioned in the configuration file with [CDATA] and do not use localhost. Instead I used the hostnames of the server and client.

Viola, everything seems working.