-
1. Re: WireFormat and flushes
timfox Feb 12, 2007 6:17 PM (in response to clebert.suconic)We call flush after every request or response is written.
Otherwise we can't be sure the packet will actually be written to the socket. -
2. Re: WireFormat and flushes
timfox Feb 12, 2007 6:25 PM (in response to clebert.suconic)(Nagle's algorithm is on by default, so even that won't necessarily mean it will always be in it's own network packet)
-
3. Re: WireFormat and flushes
clebert.suconic Feb 12, 2007 6:28 PM (in response to clebert.suconic)"timfox" wrote:
We call flush after every request or response is written.
Otherwise we can't be sure the packet will actually be written to the socket.
This should be Remoting's job.
We shouldn't need this on write methods. -
4. Re: WireFormat and flushes
clebert.suconic Feb 12, 2007 6:30 PM (in response to clebert.suconic)I will play with some profiling next week.
I will investigate if there is anything we could improve. -
5. Re: WireFormat and flushes
timfox Feb 12, 2007 6:38 PM (in response to clebert.suconic)"clebert.suconic@jboss.com" wrote:
This should be Remoting's job.
We shouldn't need this on write methods.
Not sure if I agree.
AFAIK, if you use the serializable marshaller with remoting then it will do the flush after writing the request/response.
Since we use our own marshaller it's up to us to do the flushing.
I think this is correct. It should be up the marshaller to determine when to flush and when to not. You may want a marshaller to buffer up many invocations into a single request and it would be annoying if remoting performed flushes outside your control which would screw things up. -
6. Re: WireFormat and flushes
clebert.suconic Feb 12, 2007 6:47 PM (in response to clebert.suconic)"Tim Fox" wrote:
I think this is correct. It should be up the marshaller to determine when to flush and when to not. You may want a marshaller to buffer up many invocations into a single request and it would be annoying if remoting performed flushes outside your control which would screw things up.
Yes... That's what I meant...the marshaller calling flush. We are doing on writes now. -
7. Re: WireFormat and flushes
timfox Feb 12, 2007 6:50 PM (in response to clebert.suconic)We are calling flush() after every packet is written, why is it relevant whether this is in the actual marshaller class or in the packet class itself?
The important thing is that a) We are in control (yes we are) b) We only call flush once after each write (yes we do).
Or maybe I don't understand the point you're trying to make? -
8. Re: WireFormat and flushes
clebert.suconic Feb 12, 2007 6:56 PM (in response to clebert.suconic)On ClientDeliveries... for instance...
Say if we are delivering 1000 messages to clients.. we could optimize things to write each one of these messages and call flush only at the end of a loop somewhere.
I'm not sure at this point on how to do this optimization as this is just an idea.. but when I saw this flush on writes that caught my attention. -
9. Re: WireFormat and flushes
clebert.suconic Feb 12, 2007 6:57 PM (in response to clebert.suconic)As I said before...
When I/we do some profiling we will investigate possibilities of optimizations.
I don't think there is a problem now. -
10. Re: WireFormat and flushes
timfox Feb 12, 2007 6:59 PM (in response to clebert.suconic)We only ever send one message at a time. (If you forget the http transport for a moment)
-
11. Re: WireFormat and flushes
clebert.suconic Feb 12, 2007 7:02 PM (in response to clebert.suconic)ok... I"m just brain storming about a possible optimization.
But I was thinking of the HTTP indeed. -
12. Re: WireFormat and flushes
timfox Feb 12, 2007 7:08 PM (in response to clebert.suconic)Personally I wouldn't worry too much about optimising the HTTP transport for now.
People who use the HTTP transport will know it is not designed to be the fastest.
We should concentrate on optimising for the default transport, which is going to be the bisocket.