> Some of the commercial products are quite
> smart in recording user behaviour and, at least
> for http simulations, allow near plug&play simulation
> setup - while for my tools, I always have to spend some
> work on the session simulator - but just to get
> the multithreading and the statistical timing o.k.,
> I think that's even better than the commercial
> tools.
Yeah, I agree.
> I could send you a simulation for one of
> the example apps if I find some time
> (but this is unlikely currently :-( )
This is fine. If you could send it out whenever you have a chacne in the
future, this would be cool.
> I already did these kinds of tests against cayenne,
> and I can report you the first bug I found that
> way (did'nt want to put that in the bugtracker,
> because I was afraid that no one will understand
> that...)
>
> when the connection-pool runs on it's limit,
> "PoolManager.getConnection()" throws exceptions
> about a queue overflow.
Isn't it a desired behavior?
> Apart from the fact that I don't understand
> the (non)sense of RequestQueue/RequestDequeue
> (isn't that exactly what the VM has build-in
> as the synchronization monitor? synchronize,
> wait, notify & friends...) there must not be
> a limit on this queue, not even an undocumented
> one :-) )
Well, when I am open to an argument about the value of it, and my point is
that if a queue overflow exceptions happen, this is an indication that
more connections are needed in the pool. And it makes sense to learn about
this rather sooner than later. The worst thing I have to deal with in one
of my current applications is debugging objects waiting forever to get
hold of a connection.
Now, the parameters of course should be configurable (including turning
this feature on/off), and current use of preset constants is there only
for the time being.
Another thing it provides (compared to Java wait()/notify()), is
processing requests in the order they came in. Again, the value of this is
arguable. I thought this would give a predictable result compared to the
java thread scheduling mechanism.
Do you still think the whole explicit queue mechanism is an overkill?
Andrus
This archive was generated by hypermail 2.0.0 : Fri Apr 25 2003 - 15:49:11 EDT