July 2008 - jboss-dev-forums - Jboss List Archives

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOPConstructorJoinpoint and methodHasSubInstanceMetaData

by kabir.khan＠jboss.com

I have commited the changes so far to https://jira.jboss.org/jira/browse/JBMICROCONT-317 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166400#4166400 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166400

17 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Question about Transaction timeouts and Journal

by clebert.suconic＠jboss.com

anonymous wrote : The problem with a timeout during the Commit is, I have no guarantees if the Commit will make to the file or not. I mean... I could still have the Commit Record on the file, even thought the write timed out. Say.. it timed out at 3 seconds... but it could complete after 5 seconds. As I already said.. this is unlikely to happen.. but if it does it would duplicate messages if we didn't have the code to treat that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166399#4166399 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166399

17 years, 8 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: [JBAS-5095] Race condition between connection.close() an

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | The fix is to replace isManagedConnectionFree() with wasManagedConnectionFreed(). | i.e. the managed connection might now be free, but it wasn't us that freed it | => do it only once | Of course, that's only a logical description of what it should do. In practice the code is more complicated. But the key part is to have some synchronized block that maintains/checks the free state. e.g. something like | synchronized boolean isFreed(...) | { | boolean wasFree = isManagedConnectionFree(); | // change state, e.g. #handles or track-by-tx | if (wasFree) | return false; // This shouldn't really happen now all the state is changed atomically | else | return isManagedConnectionFree(); // We just freed it | } | | if (isFreed(...)) | returnManagedConnection(); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166398#4166398 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166398

17 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Question about Transaction timeouts and Journal

by clebert.suconic＠jboss.com

The problem with a timeout during the Commit is, I have no guarantees if the Commit will make to the file or not. As libaio don't have an abort method (Actually it does.. but its implementation is empty.. it's just a stub for future versions), on that situation you might have a Rollback arriving after the Commit. If you reload the Journal at that point you might get duplicates. So.. what I'm doing is treating that as an unlikely exception. So.. what I'm doing is.. if a Rollback arrives after a Commit, I will ignore that load, and restart the load but ignoring this exceptional situation. A timeout during commit will be an unlikely event but I would prefer to have the exception code for that View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166397#4166397 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166397

17 years, 8 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOPConstructorJoinpoint and methodHasSubInstanceMetaData

by kabir.khan＠jboss.com

I am still running the aop-mc-int tests, which seem fine so far. On AS startup, your fix gets rid of the previously described problem, but I am seeing one occurrance of another problem. Stack trace: | AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(Signature) line: 150 | AbstractMetaDataContext.getComponentMetaDataRetrieval(Signature) line: 276 | MetaDataRetrievalToMetaDataBridge.getComponentMetaData(Signature) line: 160 | AOPConstructorJoinpoint.methodHasSubInstanceMetaData(MetaData, MethodInfo) line: 177 | AOPConstructorJoinpoint.rootHasMethodWithSubInstanceMetaData(MetaData) line: 155 | AOPConstructorJoinpoint.rootHasSubInstanceMetaData(MetaData) line: 135 | AOPConstructorJoinpoint.dispatch() line: 98 | AbstractBeanInfo.newInstance(String[], Object[]) line: 269 | AbstractBeanInfo.newInstance() line: 263 | JBossXBNoSchemaBuilder.createAdapterFactory(Class<BeanAdapterBuilder>, BeanInfo, MethodInfo) line: 1786 | JBossXBNoSchemaBuilder.generateType(ClassInfo, boolean) line: 775 | JBossXBNoSchemaBuilder.generateBean(ClassInfo, boolean) line: 702 | JBossXBNoSchemaBuilder.generateBean(ClassInfo) line: 690 | JBossXBNoSchemaBuilder.generateTypeBinding(TypeInfo) line: 469 | JBossXBNoSchemaBuilder.resolveTypeBinding(TypeInfo) line: 428 | JBossXBNoSchemaBuilder.createElementBinding(TypeInfo, String, boolean) line: 307 | JBossXBNoSchemaBuilder.createRootElementBinding(TypeInfo) line: 287 | JBossXBNoSchemaBuilder.createRootElements() line: 267 | JBossXBNoSchemaBuilder.build() line: 191 | JBossXBBuilder.build(Class<?>) line: 118 | TomcatDeployer.start() line: 393 | NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] | NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 | DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 | Method.invoke(Object, Object...) line: 585 | ReflectionUtils.invoke(Method, Object, Object[]) line: 56 | ReflectMethodInfoImpl.invoke(Object, Object[]) line: 110 | BasicMethodJoinPoint.dispatch() line: 66 | KernelControllerContextAction$JoinpointDispatchWrapper.execute() line: 241 | KernelControllerContextAction$JoinpointDispatchWrapper(ExecutionWrapper).execute(AccessControlContext) line: 47 | KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContext, ExecutionWrapper) line: 109 | KernelControllerContextAction.dispatchJoinPoint(KernelControllerContext, Joinpoint) line: 70 | StartStopLifecycleAction(LifecycleAction).installActionInternal(KernelControllerContext) line: 221 | StartStopLifecycleAction(InstallsAwareAction).installAction(KernelControllerContext) line: 54 | StartStopLifecycleAction(InstallsAwareAction).installAction(ControllerContext) line: 42 | StartStopLifecycleAction(SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62 | StartStopLifecycleAction(AccessControllerContextAction<S,T>).install(ControllerContext) line: 71 | KernelControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51 | AbstractKernelControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348 | AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1461 | AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 853 | AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 981 | AbstractKernelController(AbstractController).resolveContexts(boolean) line: 903 | AbstractKernelController(AbstractController).install(ControllerContext, boolean) line: 693 | AbstractKernelController(AbstractController).install(ControllerContext) line: 470 | BeanMetaDataDeployer.deploy(DeploymentUnit, BeanMetaData) line: 88 | BeanMetaDataDeployer.deploy(DeploymentUnit, Object) line: 46 | BeanMetaDataDeployer(AbstractSimpleRealDeployer<T>).internalDeploy(DeploymentUnit) line: 62 | BeanMetaDataDeployer(AbstractRealDeployer).deploy(DeploymentUnit) line: 50 | DeployerWrapper.deploy(DeploymentUnit) line: 174 | DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 970 | DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 991 | DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 911 | DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348 | AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1461 | AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 853 | AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 981 | AbstractKernelController(AbstractController).resolveContexts(boolean) line: 903 | AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 741 | AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 483 | DeployersImpl.process(List<DeploymentContext>, List<DeploymentContext>) line: 594 | MainDeployerImpl.process() line: 541 | ProfileServiceBootstrap.loadProfile(String) line: 250 | ProfileServiceBootstrap.start(Server) line: 135 | ServerImpl(AbstractServerImpl).start() line: 409 | Main.boot(String[]) line: 209 | Main$1.run() line: 544 | Thread.run() line: 613 [local variables unavailable] | The class/constructor being used in AOPConstructorJoinPoint is: public org.jboss.xb.spi.DefaultBeanAdapterBuilder() The underlying class being installed is org.jboss.web.tomcat.service.deployers.TomcatDeployer, and it barfs in AnnotatedElementMetaDataLoader when it cannot find the following method from DefaultBeanAdapterBuilder. If you want be to look into this in more detail, please let me know View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166396#4166396 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166396

17 years, 8 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: [JBAS-5095] Race condition between connection.close() an

by adrian＠jboss.org

There's no need for a reentrant lock, a plain synchronize would do. This code cannot recurse and fair queuing is irrelevant. The returnManagedConnection() needs to be outside the lock, otherwise you'll get all sorts of deadlocks with other locks, e.g. the permits in the pool. The ConnectionManager should not be locking anything when it invokes the pool (there's all sorts of bizarre paths/callbacks between the pool and CM). if the fix was as simple as this patch, then I'd have done it rather than introducing the workaround. :-) The fix is to replace isManagedConnectionFree() with wasManagedConnectionFreed(). i.e. the managed connection might now be free, but it wasn't us that freed it => do it only once Most of the fix, is not the patch, it is some stress testing to make sure there's no hole in the logic, e..g connection leaks, double release, etc. Not just when racing with transaction timeouts, but also with "random" connection failures leading to destroing of connections, both from application calls and pool calls. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166394#4166394 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166394

17 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBoss with spaces in the directory name

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : No, we don't want to decode the path unless it is really necessary. | getChild() is already slow enough in parsing the path, see PathTokenizer | on a different thread. | In principle the paths passed to getChild() should already be decoded. i.e. in the vfs url handlers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166391#4166391 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166391

17 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBoss with spaces in the directory name

by adrian＠jboss.org

No, we don't want to decode the path unless it is really necessary. getChild() is already slow enough in parsing the path, see PathTokenizer on a different thread. Anyway, I don't know exactly what is going on with the error above. Try booting jboss-head with the latest jboss-common-core and you'll see the error message, but dom4j is eating the stacktrace. If I had to guess, it would be something like the second part of this code, but this shows another bug (this code loops until it eventually consumes all heap memory!) I basically did: cd ~ mkdir -p temp/spaces\ test touch temp/spaces\ test/file.txt | import java.io.File; | import java.net.URI; | import java.net.URL; | | import org.jboss.virtual.VFS; | import org.jboss.virtual.VirtualFile; | | public class Test | { | public static void main(String[] args) throws Exception | { | File temp = new File("/home/ejort/temp/"); | URI uri = temp.toURI(); | VirtualFile vf = VFS.getRoot(uri); | System.out.println("vf=" + vf.getChild("spaces test/file.txt")); | | URL url = vf.toURL(); | URL file = new URL(url, "spaces%20test/file.txt"); | System.out.println("url=" + file); | System.out.println("stream=" + file.openStream()); | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166390#4166390 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166390

17 years, 8 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOPConstructorJoinpoint and methodHasSubInstanceMetaData

by adrian＠jboss.org

Ok, but that has nothing to do with ConfigureAction (that's just where we found the problem). The same problem could occur anywhere where it creates collections. e.g. passing it as a parameter to create() The problem is that when it is creating say an EJB3CacheRegistry and as part of one of the callbacks (in this case setting a Map property) it has to construct invoke AbstractTypeMetaData.createInstance(). NOTE: I don't see any other places where a ConstructorJoinPoint is invoked. So this goes through the AOPConstructorJoinpoint which expects there to be a MetaDataStack entry for the Map. But this Map is not under the direct control of the MC, it has no context or MDR MetaData. So the fix is probably two parts. Can you try this, to see whether it works? There might be some issues I'm not aware of with passing null on the MetaDataStack to AOPConstructorJoinPoint? 1) AbstractTypeMetaData needs to mask the EJB3CacheRegistry's MetaData context when it uses the constructor joinpoint to create the Map. | MetaDataStack.mask(); | try | { | Object result = constructor.dispatch(); | } | finally | { | MetaDataStack.unmask(); | } | 2) AOPConstructorJoinpoint needs to have code that says if the MetaDataStack is empty then just invoke parent.dispatch() rather than doing the proxy factory stuff. | public Object dispatch() throws Throwable | { | Class<?> clazz = constructorInfo.getDeclaringClass().getType(); | MetaData metaData = MetaDataStack.peek(); | if (metaData == null) | return super.dispatch(); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166387#4166387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166387

17 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: CopyOnWriteArraySet - JBCL-20

by alesj

"adrian(a)jboss.org" wrote : Incidently the reason the blacklist is so large is because we are still using the | old annotation scanning (which has the problem I reported a couple of months ago). This should all go away once we switch to my annotation scanning. ;-) It should be soon, since I saw Emanuel finished the Metadata changes required to have more optimized lookup actions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166384#4166384 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166384

17 years, 8 months

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 July 2008