Blocking Stream required

> Is there anyway of using socket blocking so I don't have
> to poll?  i.e. the readObject will not return
> until an object is found

That's exactly how readObject() works??
Can you post your code?

The code goes something like this....

URLConnection con = servlet.openConnection();

//Prepare for both input and output
con.setDoInput( true );
con.setDoOutput( true );
       
//Turn off caching
con.setUseCaches( false );

ObjectInputStream in = new ObjectInputStream( con.getInputStream() );

....

try
{
Object obj = in.readObject();
}
catch( EOFException e )
{
//Nowt on the stream.
}


Jim - I can't find a way to retrieve the socket for this stream so I can set the timeout.

Objects - I thought the stream should block if there is nothing to retrieve but it throws an EOFException.

I'm using jdk1.3.1.  Off topic - I want to move to 1.4 so I don't have to send something from the servlet to open the return stream.

you cannot access Socket behind URLConnection (at least for java 1.0 - java 1.3)

What's your servlet doing, it sounds like it is closing the stream without sending an object. This would cause your EOF.
If the stream is still open then it wouldn't be throwing an EOF.

We're attempting to replace a few rmi calls with http requests to a servlet.

I know that there are a few implementations out there for rmi tunneling over http, but we would like to implement it so that it holds the streams open and the servlet holds information about the client.  

The current version opens a connection for each request or bunch of requests and it is far too slow, especially since we have to send a key across everytime to retrieve a session object.

Hopefully it is posible to have the client send objects to an open stream whenever it wishes, the servlet will do the business logic and send back an object with the response(s).  The streams should be held open indefinitly.

Please add any comments on this.

Thanks.

HTTP is a request/response protocol.
HTTP does not support holding a connection open for full duplex comms.
There are various hacks around to attempt to achieve this, but they are not guaranteed to be reliable, and probably won't work thru most proxies.

> HTTP does not support holding a connection open for full duplex comms.

in fact HTTP 1.1 supports persistent connections.

yes I should stop generalising :) but how many servers/proxies support 1.1?

quck search on google does not return any usefull information :), but I suppose that all major players support HTTP 1.1  - am I wrong ?

not sure.

After a few tries.  We have decided to postpone this bit of the project because I'm spending far too much time n it.  We are staying with the queue of requests, sending the queue (via http to a servlet) only when a request cannot wait.  The servlet replys with an array of update objects and then closes the streams.

The EJB remote interfaces are cached in the servlet class but it is still quite heavy compaired to just rmi - but it works.

Thanks for your help.  I've asked for the points to be split between the three of you.

Points have been split, per your Community Support question.

Points for objects -> https://www.experts-exchange.com/jsp/qShow.jsp?qid=20295372
Points for heyhey_ -> https://www.experts-exchange.com/jsp/qShow.jsp?qid=20295375

:) Moondancer - EE Moderator