Buffered Stream wrap doesnt work via socket, why is that?

I'm trying to use the below stream wrap (see code) when transporting a serialized object from a client to a server and vice versa. However it halts the application. If I dont wrap the socket streams using the Buffered Streams there is no problem at all. Why is that? The wrapping works fine when writing/reading from files on the disk.
ObjectOutputStream out = new ObjectOutputStream(
   new BufferedOutputStream(socket.getOutputStream()));
ObjectInputStream in = new ObjectInputStream(
   new BufferedInputStream(socket.getInputStream()));

Open in new window

SuppaiAsked:
Who is Participating?
 
CEHJCommented:
Well you just have to get things in the right order. I agree this is a pain since there's so much repetitive coding involved.

I was once going to write something where the protocol ordering could be controlled declaratively, say by xml files, but i'm afraid i haven't got round to it ... ;-)
0
 
CEHJCommented:
It shouldn't 'halt' it. It might slow it down due to the extra buffering
0
 
objectsCommented:
try changing the order

ObjectInputStream in = new ObjectInputStream(
   new BufferedInputStream(socket.getInputStream()));
ObjectOutputStream out = new ObjectOutputStream(
   new BufferedOutputStream(socket.getOutputStream()));

0
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

 
CEHJCommented:
Can you also be more specific about this halting behaviour? e.g. what does this print?
ObjectOutputStream out = new ObjectOutputStream(
   new BufferedOutputStream(socket.getOutputStream()));
System.out.println("Got output");

Open in new window

0
 
SuppaiAuthor Commented:
Well no it doesnt get through the creation of the streams. The connection is establish and then when it comes to the stream creation the gui halts and neither client or server gets on from there (see code). As mentioned before it works smoothly without the buffered streams.

that is when running the code attached it only gets to write the connected status on both sides, then it halts.

BTW: is there a way to keep the formatting when pasting in code in the code window, when copy-pasting from eclipse, it just disrupts it totally because of the word wrapping.
//client side
public void run() {		
	try{
	SSLSocketFactory factory = (SSLSocketFactory) SSLSocketFactory.getDefault();
			SSLSocket socket = (SSLSocket) factory.createSocket(host, port);
			System.out.println("Client: connection established");
			ObjectOutputStream out = new ObjectOutputStream(new BufferedOutputStream(socket.getOutputStream()));
			ObjectInputStream in = new ObjectInputStream(new BufferedInputStream(socket.getInputStream()));		
			System.out.println("Client: IO Streams created");
			ServerRequest request = new ServerRequest(urlList,wordList,frequency);
			out.writeObject(request);
			out.flush();
			System.out.println("Client: request sent to server");
			
			ServerReport report = (ServerReport)in.readObject();
			System.out.println("Client: report received from server");
			if (report!=null) {
				System.out.println("Client: Received object: " + report);
			}			
			out.close();
			in.close();
		}catch(Exception e){	
			System.out.println(e.getMessage());
		}
	}	
 
//Server side
public void start(){
		SSLServerSocket serverSocket=null;
		try{
			SSLServerSocketFactory socketFactory = (SSLServerSocketFactory)SSLServerSocketFactory.getDefault();
			serverSocket = (SSLServerSocket)socketFactory.createServerSocket(SERVER_PORT);
			SSLSocket socket = (SSLSocket)serverSocket.accept();
			System.out.println("Server: Connection Established");
			ObjectOutputStream out = new ObjectOutputStream(new BufferedOutputStream(socket.getOutputStream()));
			ObjectInputStream in = new ObjectInputStream(new BufferedInputStream(socket.getInputStream()));
			System.out.println("Server: IO Streams Created");
			ServerRequest req = (ServerRequest)in.readObject();
			System.out.println("Server: request received from client: " + req);
			if (req!=null) {				
				System.out.println("Server: received object: " + req);
				out.writeObject(new ServerReport("Server: request received from client: "  + req));
				out.flush();
				System.out.println("Server: object written to client");
			}		
			out.close();
			in.close();
		}catch(Exception e){	
			System.out.println("Server: " + e.getMessage());
		}		
	}

Open in new window

0
 
objectsCommented:
what oder do you open them on the server?
0
 
objectsCommented:
it maybe the server thats the wrong way around it should open the output stream first, and the client open the input stream first

0
 
CEHJCommented:
>>System.out.println("Client: IO Streams created");

If the above doesn't get printed, network problems could be involved
0
 
SuppaiAuthor Commented:
Im running on localhos and it works without the buffered stream wrapping.  
In fact I made it work by waiting to initialize the streams until right before they were used like attached (see code). Why is this different from when not using buffered streams? Shouldnt it work in exactly the same way?
//Client side
SSLSocketFactory factory = (SSLSocketFactory) SSLSocketFactory.getDefault();
			SSLSocket socket = (SSLSocket) factory.createSocket(host, port);
			System.out.println("Client: connection established");
			ObjectOutputStream out = new ObjectOutputStream(new BufferedOutputStream(socket.getOutputStream()));				
			System.out.println("Client: IO Streams created");
			ServerRequest request = new ServerRequest(urlList,wordList,frequency);
			out.writeObject(request);
			out.flush();
			System.out.println("Client: request sent to server");			
			ObjectInputStream in = new ObjectInputStream(new BufferedInputStream(socket.getInputStream()));	
			ServerReport report = (ServerReport)in.readObject();
			System.out.println("Client: report received from server");
			if (report!=null) {
				System.out.println("Client: Received object: " + report);
			}			
			out.close();
			in.close();
}
 
//Server side
public void start(){
		SSLServerSocket serverSocket=null;
		try{
			SSLServerSocketFactory socketFactory = (SSLServerSocketFactory)SSLServerSocketFactory.getDefault();
			serverSocket = (SSLServerSocket)socketFactory.createServerSocket(SERVER_PORT);
			SSLSocket socket = (SSLSocket)serverSocket.accept();
			System.out.println("Server: Connection Established");			
			ObjectInputStream in = new ObjectInputStream(new BufferedInputStream(socket.getInputStream()));
			System.out.println("Server: IO Streams Created");
			ServerRequest req = (ServerRequest)in.readObject();
			System.out.println("Server: request received from client: " + req);
			ObjectOutputStream out = new ObjectOutputStream(new BufferedOutputStream(socket.getOutputStream()));
			if (req!=null) {				
				System.out.println("Server: received object: " + req);				
				out.writeObject(new ServerReport("Server: request received from client: "  + req));
				out.flush();
				System.out.println("Server: object written to client");
			}		
			out.close();
			in.close();
		}catch(Exception e){	
			System.out.println("Server: " + e.getMessage());
		}		
	}

Open in new window

0
 
CEHJCommented:
If that's now working, it's probably because you've got the client and server reading and writing in the correct order, which you possibly didn't have before. read() is a blocking call so it will halt the app thread until there are data to read
0
 
CEHJCommented:
As for your formatting in the code snippet window, it looks OK to me apart from the odd line here or there
0
 
SuppaiAuthor Commented:
So if I want to be able to send a response twice to the client from the server how can I do this then if it has to be in the write order (server.out, client.in, client.out, server.in etc. etc.)? e.g. a few status messages in a row? Should separate input and output threads be created in the client for haandlign this or how would one do this normally?
0
 
objectsCommented:
It is nothing to do with how many messages you send, its just the initial creation of the streams that needs to be created in the approproate order to avoid a deadlock as I mentioned in my earlier comments.

0
 
objectsCommented:
just to clarify the problem has absolutely nothing to do with your protocol.
Let me know if you have any questions

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.