On Fri, Oct 27, 2006 at 10:50:17PM -0400, Mark DeLaFranier wrote: > I should have mentioned -- time :-) > > I'll post a follow up next week. I have to look in an issue with a > multithreaded test that is being run. > > What are you thoughts on how to go about client side setting of > configuration properties? > > For example, a few ideas I have: > > 1. A client may wish to disable the keep alive feature > 2. A client may wish to enable some protocol tracing that I have implemented > 3. How would a client alter the number of pooled connections? > 4. How would a client alter the instance timeout for pooled connection? > 5. How many times would a client retry before giving up? > > Currently, I am configuring some of the above based on a system > properties that beings with "org.apache.openejb": > > 1. org.apache.openejb.protocol.keepalive=[true] / false > 2. org.apache.openejb.protocol.trace=true / [false] > 3. org.apache.openejb.client.socket.pool.max.size= ? > 4. org.apache.openejb.client.socket.pool.timeout=60 (seconds) > 5. org.apache.openejb.client.socket.retrycount=5
What you've outlined is pretty good. I'd go with 'openejb' over 'org.apache.openejb' just to keep consistent with our other properties. > Setting a custom property in the InitialContext creation is an idea, but > the catch here is that the connection pool is tied to the client process > not the initial context object. That's good for now. Things are a bit different in the 3 branch. There the ServerMetaData object contains a URI which would be a great place for us to put more connection configuration oriented stuff. Take a quick peek at: http://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/server/openejb-client/src/main/java/org/apache/openejb/client/ConnectionManager.java http://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/server/openejb-client/src/main/java/org/apache/openejb/client/HttpConnectionFactory.java If you wanted to back port the URI change from 3 to 2 that'd be cool with me. Then you could stuff the connection config in the URI as query params. -David > > Suggestions welcome. > > Mark > > Dain Sundstrom wrote: > >This is very cool. When you are measuring a savings what are you > >saving? time, cpu, bites on the wire... > > > >-dain > > > >On Oct 26, 2006, at 8:47 PM, Mark DeLaFranier wrote: > > > >>Hey guys, > >> > >>I am sorta informally looking at the performance of OpenEJB. Now I > >>am certainly not trying to open a can of worms here. :-) An idea > >>that I am currently playing with is to modify the client so that it > >>can re-use an existing open socket connection to the server rather > >>then doing open-write-read-close and at the same time, the server > >>will loop and keep reading requests from the same socket. > >> > >>My first thought was to enhance the OEJP to support "headers" like > >>HTTP does and then use the "keepalive" idea. I bumped up the OEJP > >>version to 2.1 so that the client/server would know to check for the > >>existance of headers in the request/response. The marshalled headers > >>would be in the format of: > >> > >>Existing structure: [OEJP/2.0][request-id][request-data] > >>New structure: > >>[OEJP/2.1][#-of-headers][headers][request-id][request-data] where > >>headers is [len][name-data][len][value-data] > >> > >>This saved, combined with socket pooling, approx. 34% > >> > >>My second thought was to avoid the NVP headers and use a byte array > >>of bit flags, the new format is: > >> > >>[OEJP/2.1][byte-of-flags][request-id][request-data] > >> > >>This is 27% faster then my first thought. > >> > >>I like to carry this forward a little more, but I would like to > >>peoples thoughts on this first. > >> > >>Thanks > >>Mark > >> > >> > > > > > > >
