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

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

by jason.greene＠jboss.com

"jason.greene(a)jboss.com" wrote : "bstansberry(a)jboss.com" wrote : | | Can you use a putIfAbsent instead of a get to try to preserve the original lock? Idea being that if threads are waiting on the original lock you try to keep using it rather than having them queue up on a new lock. | | | | Yes this is better, although still sucks when you have contended access on a Lock. I think it might make more sense to keep locks around and evict them later, either when the key is removed/evicted, or some other special lock eviction algorithm that uses timestamps. IMO A lazy LRU lock eviction alg that is executed on lock aquire would work very well for this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219202#4219202 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219202

17 years

1
0
0 / 0

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

by bstansberry＠jboss.com

PerElementLockContainer.locks is using the default CHM c'tor which means 16 segments. That's low since this will be a very write-heavy map. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219201#4219201 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219201

17 years

1
0
0 / 0

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

by jason.greene＠jboss.com

"bstansberry(a)jboss.com" wrote : | Can you use a putIfAbsent instead of a get to try to preserve the original lock? Idea being that if threads are waiting on the original lock you try to keep using it rather than having them queue up on a new lock. | Yes this is better, although still sucks when you have contended access on a Lock. I think it might make more sense to keep locks around and evict them later, either when the key is removed/evicted, or some other special lock eviction algorithm that uses timestamps. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219200#4219200 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219200

17 years

1
0
0 / 0

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

by jason.greene＠jboss.com

"jason.greene(a)jboss.com" wrote : "manik.surtani(a)jboss.com" wrote : 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. | | Why is this step needed? If everything is using putIfAbsent you shouldn't have a problem. Ah I see this is to handle the case of a blocked/queued thread acquiring a lock. Hmm this kind of defeats the performance benefit of aqs lock queueing View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219198#4219198 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219198

17 years

1
0
0 / 0

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

by jason.greene＠jboss.com

"manik.surtani(a)jboss.com" wrote : 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. Why is this step needed? If everything is using putIfAbsent you shouldn't have a problem. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219192#4219192 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219192

17 years

1
0
0 / 0

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

by bstansberry＠jboss.com

I tried a locally built snapshot of trunk with dukehoops' test and the problem goes away. Can you use a putIfAbsent instead of a get to try to preserve the original lock? Idea being that if threads are waiting on the original lock you try to keep using it rather than having them queue up on a new lock. | ### Eclipse Workspace Patch 1.0 | #P jbosscache-core | Index: src/main/java/org/jboss/cache/util/concurrent/locks/PerElementLockContainer.java | =================================================================== | --- src/main/java/org/jboss/cache/util/concurrent/locks/PerElementLockContainer.java (revision 7915) | +++ src/main/java/org/jboss/cache/util/concurrent/locks/PerElementLockContainer.java (working copy) | @@ -56,7 +56,8 @@ | Lock l = getLock(object); | l.lock(); | // now check that the lock is still valid... | - if (l != locks.get(object)) | + Lock official = locks.putIfAbsent(object, l); | + if (official != null && l != official) | { | // we acquired the wrong lock! | l.unlock(); | (The above would be applied to the overloaded acquireLock(E, long. TimeUnit) as well.) There is still a possibility that after the lock owner removes the lock from the map in releaseLock() another thread could sneak in and create a new lock. But that's not incorrect, just not fair. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219185#4219185 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219185

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Confused about versioning

by mauromol

"thomas.diesler(a)jboss.com" wrote : Yes, everything you commit to trunk will go into the next jbpm-3.2.x release. There will be no further jbpm-3.3.x release anymore. | No further 3.3.x releases?!?!?! We recently migrated our jBPM integration from 3.2.x to 3.3.x and now you say that you'll go to update just 3.2.x branch? Why? What should we do now? Mauro. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219178#4219178 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219178

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: org.jboss.messaging.default-call-timeout

by clebert.suconic＠jboss.com

It was a temporary hack as I stated here. I was investigating the reason for a few timeouts on hudson. http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151985 and I have removed it already. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219143#4219143 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219143

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Semantic on Session.stop and MessageHandler

by timfox

It should have same semantics as JMS connection.stop. This is explained in the JMS javadoc: anonymous wrote : | Temporarily stops a connection's delivery of incoming messages. Delivery can be restarted using the connection's start method. When the connection is stopped, delivery to all the connection's message consumers is inhibited: synchronous receives block, and messages are not delivered to message listeners. This call blocks until receives and/or message listeners in progress have completed. Stopping a connection has no effect on its ability to send messages. A call to stop on a connection that has already been stopped is ignored. A call to stop must not return until delivery of messages has paused. This means that a client can rely on the fact that none of its message listeners will be called and that all threads of control waiting for receive calls to return will not return with a message until the connection is restarted. The receive timers for a stopped connection continue to advance, so receives may time out while the connection is stopped. If message listeners are running when stop is invoked, the stop call must wait until all of them have returned before it may return. While these message listeners are completing, they must have the full services of the connection available to them. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219142#4219142 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219142

17 years

1
0
0 / 0

[Design of POJO Server] - JAXB Deployer

by anil.saldhana＠jboss.com

I have an independent JAXB model for configuration from a separate project called as JBossXACML (which does not have any dependencies on JBossXB). As part of https://jira.jboss.org/jira/browse/JBAS-6607, I tried using the SchemaResolvingDeployer but it was unable to locate the schema. Additionally, registering with JBossXB is a noop because my metadata does not have the @JBossxml annotation. Given this, I looked at the JAXBDeployer http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/tags/2.0.... in deployers which is an abstract class. The issue with this is that if the JAXB metadata has a root of JAXBElement from the following schema: http://anonsvn.jboss.org/repos/jbossas/projects/security/security-xacml/t... then the JAXBDeployer create method falls apart because it tries to instantiate JAXBElement. Issue with JAXBDeployer: "context" and "properties" need to made protected. My JAXBElementParsingDeployer looks as follows: | package org.jboss.security.deployers; | | import java.io.InputStream; | import java.util.Map; | | import javax.xml.bind.JAXBContext; | import javax.xml.bind.Unmarshaller; | | import org.jboss.deployers.vfs.spi.deployer.JAXBDeployer; | import org.jboss.deployers.vfs.spi.structure.VFSDeploymentUnit; | import org.jboss.virtual.VirtualFile; | import org.xml.sax.InputSource; | | /** | * A parsing deployer that is capable of parsing | * a JAXB model with the root element being | * JAXBElement<T> | */ | @SuppressWarnings("unchecked") | public class JAXBElementParsingDeployer<T,V> extends JAXBDeployer | { | /** The JAXBContext */ | protected JAXBContext context; | | /** The properties */ | protected Map<String, Object> properties; | | protected Class<V> enclosed; | | /** | * CTR | * @param output JAXBElement.class | * @param enclosed Type enclosed by JAXBElement | */ | public JAXBElementParsingDeployer(Class<T> output, Class<V> enclosed) | { | super(output); | this.enclosed = enclosed; | } | | /** | * Create lifecycle | * | * @throws Exception for any problem | */ | @Override | public void create() throws Exception | { | if (properties != null) | context = JAXBContext.newInstance(new Class[] {enclosed}, properties); | else | context = JAXBContext.newInstance(enclosed); | } | | /** | * Destroy lifecycle | */ | public void destroy() | { | context = null; | } | | @Override | protected Object parse(VFSDeploymentUnit unit, VirtualFile file, Object root) throws Exception | { | Unmarshaller unmarshaller = context.createUnmarshaller(); | InputStream is = openStreamAndValidate(file); | try | { | InputSource source = new InputSource(is); | source.setSystemId(file.toURI().toString()); | Object o = unmarshaller.unmarshal(source); | return getOutput().cast(o); | } | finally | { | try | { | is.close(); | } | catch (Exception ignored) | { | } | } | } | } | So if "context" and "properties" are made protected members of the JAXBDeployer then I can just override the create method to avoid the duplicated parse. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219131#4219131 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219131

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