March 2009 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: JSR-299 servlet injection

by alesj

This looks too much of a hassle for a single Servlet injection. Not to mention that it's not nearly done yet or more fleshed out (at least I don't see it). Looking at TomcatInjectionContainer just brings shivers to my bones :-), it's one huge pile of different / mixed concepts, some of them even done completely wrong - e.g. class instance being shared between diff method params / threads. If we can nail down what this actually does or should do (who knows this?) I can re-write it to use some of MC's logic regarding injection. e.g. * let JBossWeb invoke InstanceManager * handoff instance creation to MC * apply constraints as part of MC lifecycle * examine for injections (as we already do for MC) * "revert" this on destruction View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219129#4219129 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219129

17 years

1
0
0 / 0

[Design of JBossCache] - Re: Lock striping broken for Second Level Cache use case

by manik.surtani＠jboss.com

Ok, I have checked in something that may work, have a look at the JIRA for details. This does not impact existing code in any way since it is controlled by a config switch which defaults to using lock striping. If anyone is interested in building trunk and giving this a try beyond my unit tests, feedback would be appreciated. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219028#4219028 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219028

17 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Separate AOP deployers out of AS

by stale.pedersen＠jboss.org

ive added the deployers found in org.jboss.aop.asintegration.jboss5 in the as repo to aop. the module is called jboss-aop-deployers. ive added it to trunk and the 2.1 branch, let me know if there are other places i should add them. i guess the deployers should be removed from the as repo, but if im not mistaken this requires that we have pushed up a non-snapshot version of the jboss-aop-deployers module? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218993#4218993 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218993

17 years

1
0
0 / 0

[Design of JBossCache] - Re: Lock striping broken for Second Level Cache use case

by manik.surtani＠jboss.com

Actually, getLock().4 should read: 4. after acquisition, test that lock acquired is same as lock created in 1, otherwise unluck, discard lock and try again. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218973#4218973 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218973

17 years

1
0
0 / 0

[Design of JBossCache] - Re: Lock striping broken for Second Level Cache use case

by manik.surtani＠jboss.com

Ok, this can be done, but it won't be altogether straightforward: | getLock(Fqn) { | 1. create new lock. | 2. putIfAbsent on the concurrent map that holds locks, swapping to the actual lock in the map if needed | 3. acquire lock | 4. after acquisition, check again that the lock is the current lock in the concurrent map, if not, release lock and retry this method. | } | | releaseLock(Fqn) { | 1. get lock from map | 2. if not null, and if owner, attempt to release lock | 3. remove lock from collection | } | While this will work, this will cause waiters to spin on getLock().4 until it has got the same lock it expects. In releaseLock().3, this will cause threads that release locks to clean up, but will cause additional spinning on getLock().4. Basically, in getLock(), a lock is only valid if you created it in getLock().1. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218967#4218967 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218967

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - What's KernelControllerContext.install fromState argument?

by wolfc

What does the fromState argument on KernelControllerContext.install actually mean? Deep down it's ignored. I would have expected doing kcc.install(DESCRIBED, INSTALLED) twice would result in an IllegalStateException. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218966#4218966 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218966

17 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: Remoting 3 and HTTP client

by timfox

JBoss Messaging 2.0 also uses Netty, including the HTTP servlet transport, which allows JMS traffic to be tunnelled over port 80 in any servlet container. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218962#4218962 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218962

17 years

1
0
0 / 0

[Design of JBossCache] - Re: Lock striping broken for Second Level Cache use case

by manik.surtani＠jboss.com

Ok, the solution I proposed above is broken. The map would grow infinitely and be a memory leak since there is no way to remove the lock from the concurrent map, unless there is some further synchronization, which will make things even less performant. More to think about. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218959#4218959 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218959

17 years

1
0
0 / 0

[Design of JBossCache] - Re: Lock striping broken for Second Level Cache use case

by manik.surtani＠jboss.com

I have created a JIRA to track this: https://jira.jboss.org/jira/browse/JBCACHE-1494 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218958#4218958 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218958

17 years

1
0
0 / 0

[Design of JBossCache] - Re: Lock striping broken for Second Level Cache use case

by manik.surtani＠jboss.com

One approach that may work is to use a ConcurrentMap as a lock container rather than an array of fixed size. Instead of mapping locks to a modularised hashcode of a given Fqn as we do now, we could use the Fqn itself as a key to a lock, and use concurrent methods on the map to locate the lock, creating new ones if absent, etc. It will perform worse (both in terms of memory and lock locating, since unnecessary locks may be created and thrown away) but it would prevent the deadlock issue mentioned above. Also, it would be simple enough to implement as an alternate LockContainer impl and plug in. Let me give this a bit more thought. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218955#4218955 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218955

17 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2009