marc fleury wrote:
> |marc fleury wrote:
> |> We saw with rickard that Proxy creation is a bit slow and he mentioned a
> |> flag at the object level to allow pooling... will have to
> |research that...
> |> but for the pools I believe it is non important
> |
> |See:
> |http://java.sun.com/j2se/1.3
|That could work, yes. If you do "on demand" it's back to
|wait-on-init-land, but replenishing in background could be ok.
Even better (checked in yesterday) create on free, don't reuse, let the
passivation thread replenish it.
And then sometime far away in the distance outside my cockpit window,
marc fleury wrote:
> |For objects that do a lot of stuff in set*Context, yes. Common
> |operations are lookup of home objects, and to create data structures. In
> |those cases pooling is essential.
>
> it is the ***reuse*** that really fucks us up. We can "prefab" some
> instances and keep "pools
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> fleury
> Sent: Tuesday, July 03, 2001 10:46 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] new Threads.java (cache bug tests) is
> incomplete.
>
>
>
&g
|marc fleury wrote:
|> We saw with rickard that Proxy creation is a bit slow and he mentioned a
|> flag at the object level to allow pooling... will have to
|research that...
|> but for the pools I believe it is non important
|
|See:
|http://java.sun.com/j2se/1.3/docs/api/java/lang/ref/ReferenceQu
|For objects that do a lot of stuff in set*Context, yes. Common
|operations are lookup of home objects, and to create data structures. In
|those cases pooling is essential.
it is the ***reuse*** that really fucks us up. We can "prefab" some
instances and keep "pools" at a minimum level but no reu
|> this is locked on getCacheLock(), and the passivation in case of stateful
|> stuff is slow (write to disk). getCacheLock locks the whole application.
|>
|> bad, right?
|>
|
|Duh! You're right, sorry. But, wait.Aren't you doing a
|getCachLock() in
|PassivationJob as well? Same problem, j
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> fleury
> Sent: Tuesday, July 03, 2001 9:44 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] new Threads.java (cache bug tests) is
> incomplete.
>
>
> |I
|I wasn't saying that you shouldn't protect the cache or the
|context, but for
|cache.release(ctx), again, why schedule the passivation? Why not just
|passivate it.
|
|public void release(ctx)
|{
| synchronized(getCacheLock())
| {
| Object id = getKey(ctx);
| if (canPassivate(ctx))
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Bordet, Simone
> Sent: Tuesday, July 03, 2001 4:06 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [JBoss-dev] new Threads.java (cache bug tests) is
> incomplete
Hey Bill,
> Sorry to chime in so late(we had a launch party for our
> service built upon
> JBoss!)
Great !
> I wasn't saying that you shouldn't protect the cache or the
> context, but for
> cache.release(ctx), again, why schedule the passivation? Why not just
> passivate it.
>
> public
marc fleury wrote:
> We saw with rickard that Proxy creation is a bit slow and he mentioned a
> flag at the object level to allow pooling... will have to research that...
> but for the pools I believe it is non important
See:
http://java.sun.com/j2se/1.3/docs/api/java/lang/ref/ReferenceQueue.ht
Bill Burke wrote:
> Yeah, I guess it's cool now that you removed InstancePooling. God, pooling
> just fucked everything up and caused a lot of complexity. I wonder if
> pooling actually had any effect on performance anyways?
For objects that do a lot of stuff in set*Context, yes. Common
operati
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Bordet, Simone
> Sent: Monday, July 02, 2001 1:01 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [JBoss-dev] new Threads.java (cache bug tests) is
> incomplete
|taken care of (actually by bill, that was a real fix (as opposed
|to removing
|the LW message ;-)) I am sticking to that logic
what I mean by that is that removing the LW message wasn't a fix. It was
cosmetic and *REALLY* pegged the cpu at 100%, this was the real bug simone
had, the busy-wait o
|Marc, since you get rid of the pool, do you use WaitSemaphore to
|wait/notify
|or you wait/notify on the context ?
2 levels a ctx w/n and a ctx.getTxLock w/n for the tx related issues.
|That was a pain when I worked on it, but I believed the pool was somehow
|necessary for performance, didn't
Hi,
> that needs to be synchronized and simone does it in 2 steps... again I
> thought that was actually quite all right if not downright
> elegant with the
> entity symetry... (he did do somethings right)
[snip]
Ah, well, thanks !
Marc, since you get rid of the pool, do you use WaitSemaphore
Hey Bill,
> Still, for Stateful beans, you're adding complexity for the
> time between
> when the Stateful bean gets scheduled for passivation, and when the
> Passivator Thread actually runs. Which is only a few
> milliseconds, right?
> If the Stateful bean is scheduled for passivation, this
PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] new Threads.java (cache bug tests) is
> incomplete.
>
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> > fleury
> > Sent: Monday
|Yeah, I guess it's cool now that you removed InstancePooling. God, pooling
|just fucked everything up and caused a lot of complexity. I wonder if
|pooling actually had any effect on performance anyways?
we will see... it is one of those things where a fancy CMP engine would
SPEED us up SO MUCH
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> fleury
> Sent: Monday, July 02, 2001 11:56 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] new Threads.java (cache bug tests) is
> incomplete.
>
>
>
|> I don't understand the second point, what do you mean the calls will be
|> serialized? please explain,
|>
|>
|
|My point was that if you're accessing the same entity with the same primary
|key, the threads will be all queued up waiting on eachother. Only one
it better! that is the spec!
that
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> fleury
> Sent: Sunday, July 01, 2001 11:39 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] new Threads.java (cache bug tests) is
> incomplete.
>
>
> O
Yo yourself,
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|Bordet, Simone
|
|Yo,
|
|> I'm on top of it, got the fix with the next generation of
|> synchronization...
|> but it is 12:30 am and I need to get up at 5 to go to the INS
|> and get my
|> permanent residency card... yep got to be in line at 6
Yo,
> I'm on top of it, got the fix with the next generation of
> synchronization...
> but it is 12:30 am and I need to get up at 5 to go to the INS
> and get my
> permanent residency card... yep got to be in line at 6am
> otherwise "me no
> get in, and me no get card at INS (US immigration FY
L PROTECTED]
|Subject: RE: [JBoss-dev] new Threads.java (cache bug tests) is
|incomplete.
|
|
|Ok finishing the test of the cache, found interesting stuff...
|
|onto your mail
|1- turn of html
|2- see below
|
|Don't get annoyed with me, but your new threads test is incomplete:
|
|that's ok
Ok finishing the test of the cache, found interesting stuff...
onto your mail
1- turn of html
2- see below
Don't get annoyed with me, but your new threads test is incomplete:
that's ok, I don't shoot the messenger, I do shoot the implementor
- You need to also randomize on the bean's primary
PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
BurkeSent: Monday, June 25, 2001 10:05 PMTo:
Jboss-Development@Lists. Sourceforge. NetSubject: [JBoss-dev] new
Threads.java (cache bug tests) is incomplete.
Marc,
Don't get annoyed
with me, but your new threads te
Marc,
Don't get annoyed
with me, but your new threads test is incomplete:
- You need to
also randomize on the bean's primary key. I say this because some of the
cache bugs I encountered were as a result of one thread throwing a context back
into the InstancePool(via a rollback or remov
29 matches
Mail list logo
