> Hi Ken,
>
> thanks a lot for your support.
>
> We are using V1UR1 currently. We are getting close to
> acceptance and
> production, due once we sorted out some showstoppers.
> So V2 is not an
> option for us.
OK. Unfortunately all of the performance work is in V2.
It would be possible to port some, but not all of these features
to a patch on V1, but I don't know what the support and sustaining
plans are there. The big item is likely to be the codebase problem
I mentioned, and that would be fairly simple to patch, but that would
require action by the sustaining team and a support contract.
> >Profiling shows that the time is
> spent
> >> in ORB.init()... WTF is it doing?
> >>
> >
> > This one is interesting. I know what ORB.init does
> both in the ORB
> > and in the app server, but 20 seconds is a long
> time. Could you share
> > your profiling info with us?
> >
> I will take a Netbeans profiling snapshot and follow
> up with that.
OK, thanks.
> >
> We currently use ORBUseNIOSelectToWait=false, and
> this alone reduced it
> by 50%. We havent tested with newer versions of
> Glassfish as this is
> currently not an option.
Making NIO select both perform well with small numbers of connections
and scale well with large numbers is tricky. Again, some major improvements
are available in V2, and these are definitely too much to port back to V1.
> >
> >
> >> - Latency: This time, Jonas is 5 times as quick.
> Our
> >> average request latency for requests without
> payload
> >> (e.g. a simple ping()) is well above 10ms,
> sometimes
> >> as bad as 30ms. Without any network interference.
> >>
> >>
> >
> > We'll need to look at this again. We are mainly
> focusing on
> > throughput oriented tests (like SpecJ) at this
> point.
> >
> Unfortunately latency ia critical for our
> application, and I assume for
> most rich clients that use fine grained operations.
> We have a lot of
> small operations going against our service layer
> (mostly data requests),
> and batching them is not really an option (we do a
> lot of lazy fetching
> of data).
OK. I'll take a look at this when time permits.
> >
> Having settings in the ORB should be sufficient, at
> least if their
> behaviour is documented.
OK. We can follow up with docs on the timeout settings for V2.
> I already found out about
> some other parameters
> (mainly WAIT_FOR_RESPONSE_TIMEOUT) and tried to set
> them low, but this
> had sideeffects. For example, if the operation we
> call has a huge
> payload (lets say an image of 3000K), the request
> times out before it
> arrives fully on the server. At least we do not see
> the method entry on
> the server side when we get the Exception on the
> client side for this
> special case.
>
> Nevertheless, WAIT_FOR_RESPONSE_TIMEOUT may be the
> wrong setting, I will
> try the paramters you described in your earlier
> message.
OK, but remember that the CONNECT version of TcpTimeouts is only
available in V2 (in a couple of weeks).
> >> If I cannot specify a timeout on socket level, I
> >> thought I maybe could just have watchdog thread
> and
> >> interrupt() some other threads (i.e. the locked
> >> thread). Try this - its a major show in the log
> >> console and a broken ORB. Shouldn't any blocking
> >> thread be prepared to receive an interrupt()?
> >>
> >
> > In general, yes, but many thread could choose to
> ignore
> > interrupt, for example a while(!condition) wait
> loop would
> > have no choice but to spin and continue waiting if
> interrupted.
> > We could probably make the CorbaResponseWaitingRoom
> > code respond to an interrupt() call, but I'm not
> sure if that's a
> > good idea or not.
> >
> This is more or less a question of request
> monitoring. You were
> mentioning this earlier:
>
> > Please let me know how this works for you (it will
> probably be another 2 weeks
> > before you can get a build with this ORB in it).
> Also, I'd like to know
> if there are any needs for fine grained control over
> timeouts. Right now the
> granularity is the entire ORB, so you cannot set a
> timeout that applies
> to only a single request, or a single EJB reference.
> Definitely, yes. Our operations are with varying
> granularity. For
> example we might have a very small request just
> pushing a single value
> to the service layer. On the other hand we have very
> huge request, when
> we transmit a BLOB to the server. So therefore
> specifying the timout on
> a per-request basis would be a good thing to do (at
> least for our use
> case).
>
> Another thing is to monitor the state of the
> operation and to make it
> cancellable. I could, for example, put the remote
> operation call on one
> thread and have another one monitoring the request,
> giving the user some
> feedback about the current state of the application.
> Thats also when
> interrupting becomes relevant, as the user may
> choose to cancel the
> current operation (again, for example when uploading
> a BLOB), or we may
> want to show some progress information when
> transmitting a large amount
> of data.
>
> If you want we can discuss this in detail (I think
> that would be a bit
> out of scope for this thread).
I think that would be a good idea. And we should really discuss
this in a separate thread.
Ken.
[Message sent by forum member 'kcavanaugh' (kcavanaugh)]
http://forums.java.net/jive/thread.jspa?messageID=215690