February 2010 - jboss-dev-forums - Jboss List Archives

[Security Development] New message: "Re: Auth Cache is not flushed after logout"

by Jean-David Maillefer

JBoss development, A new message was posted in the thread "Auth Cache is not flushed after logout": http://community.jboss.org/message/527678#527678 Author : Jean-David Maillefer Profile : http://community.jboss.org/people/jidehem Message: -------------------------------------------------------------- Are you sure you tried it in the same order I wrote ? I'm using the same piece of code and it works perfectly. Maybe you session is invalidated twice ? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527678#527678

14 years, 2 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: CallbackItem.changeCallback() very expensive due to context tracking"

by Ales Justin

JBoss development, A new message was posted in the thread "CallbackItem.changeCallback() very expensive due to context tracking": http://community.jboss.org/message/527667#527667 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > This might not be super important, does anybody have any numbers for how frequently callbacks are being used in AS? I would say a lot, as it's quite handy feature. e.g. Deployers are picked up this way Other usage includes AnnotationPlugins, some Management objects, some JMS destinations, ... Apart from Deployers I doubt there are many instances that are picked up this way, but the feature makes sure they are transparently picked, not needing explicit install calls. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527667#527667

14 years, 2 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: CallbackItem.changeCallback() very expensive due to context tracking"

by Ales Justin

JBoss development, A new message was posted in the thread "CallbackItem.changeCallback() very expensive due to context tracking": http://community.jboss.org/message/527663#527663 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > For B I don't really understand exactly why this is being done? It looks like we check for ContextTracker in each metadata level at INSTANCE level and above, up to JVM. Wouldn't that be handled by the call to metaData.getMetaData() in C anyway? Yeah, I think it you're right. Since, if the context/scopeInfo's scope key doesn't include certain scope level, looking with B doesn't really help -- same result as with C. e.g. B's MetaData is just a collection of Cs > For A, maybe scopeInfo could keep a reference to the MetaData to avoid having to access the repository every time we call scopeInfo.getMetaData()? > > > How many times do we invoke this? For ContextTracker retrieval, this should only be called once, as we should get the CT on the first call. (CT is setup in AS -- see kernel.xml, but not by default for MC tests) -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527663#527663

14 years, 2 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Profiling the dependency project"

by Kabir Khan

JBoss development, A new message was posted in the thread "Profiling the dependency project": http://community.jboss.org/message/527633#527633 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- I tried a few different things, none of which really made a difference, so I have stuck with more or less what we had, but making sure we access the (un)installCallbacks in a thread safe way: =================================================================== --- dependency/src/main/java/org/jboss/dependency/plugins/AbstractController.java (revision 101181) +++ dependency/src/main/java/org/jboss/dependency/plugins/AbstractController.java (working copy) @@ -23,6 +23,7 @@ import java.util.Collection; import java.util.Collections; +import java.util.HashMap; import java.util.HashSet; import java.util.Iterator; import java.util.LinkedHashSet; @@ -107,8 +108,8 @@ private final Set<AbstractController> childControllers = new CopyOnWriteArraySet<AbstractController>(); /** The callback items */ - private final Map<Object, Set<CallbackItem<?>>> installCallbacks = new ConcurrentHashMap<Object, Set<CallbackItem<?>>>(); - private final Map<Object, Set<CallbackItem<?>>> uninstallCallbacks = new ConcurrentHashMap<Object, Set<CallbackItem<?>>>(); + private final Map<Object, Set<CallbackItem<?>>> installCallbacks = new HashMap<Object, Set<CallbackItem<?>>>(); + private final Map<Object, Set<CallbackItem<?>>> uninstallCallbacks = new HashMap<Object, Set<CallbackItem<?>>>(); /** Whether an on demand context has been enabled */ private boolean onDemandEnabled = true; @@ -1831,14 +1832,20 @@ * @param isInstallPhase install or uninstall phase * @return all matching registered callbacks or empty set if no such item */ - protected Set<CallbackItem<?>> getCallbacks(Object name, boolean isInstallPhase) + protected Set<CallbackItem<?>> getCallbacks(Set<CallbackItem<?>> result, Object name, boolean isInstallPhase) { lockRead(); try { Map<Object, Set<CallbackItem<?>>> map = (isInstallPhase ? installCallbacks : uninstallCallbacks); Set<CallbackItem<?>> callbacks = map.get(name); - return callbacks != null ? callbacks : Collections.<CallbackItem<?>>emptySet(); + if (callbacks != null) + { + if (result == null) + result = new HashSet<CallbackItem<?>>(); + result.addAll(callbacks); + } + return result; } finally { @@ -1910,20 +1917,16 @@ if (dependencyInfo != null && dependencyInfo.isAutowireCandidate()) { // match callbacks by name - existingCallbacks = new HashSet<CallbackItem<?>>(); - existingCallbacks.addAll(getCallbacks(context.getName(), isInstallPhase)); + existingCallbacks = getCallbacks(existingCallbacks, context.getName(), isInstallPhase); // match by classes Collection<Class<?>> classes = getExposedClasses(context); if (classes != null && classes.isEmpty() == false) { for (Class<?> clazz : classes) { - existingCallbacks.addAll(getCallbacks(clazz, isInstallPhase)); + existingCallbacks = getCallbacks(existingCallbacks, clazz, isInstallPhase); } } - - if (existingCallbacks.isEmpty()) - existingCallbacks = null; } if (installs != null || uninstalls != null || existingCallbacks != null) -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527633#527633

14 years, 2 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: CallbackItem.changeCallback() very expensive due to context tracking"

by Kabir Khan

JBoss development, A new message was posted in the thread "CallbackItem.changeCallback() very expensive due to context tracking": http://community.jboss.org/message/527603#527603 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- This might not be super important, does anybody have any numbers for how frequently callbacks are being used in AS? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527603#527603

14 years, 2 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: CallbackItem.changeCallback() very expensive due to context tracking"

by Kabir Khan

JBoss development, A new message was posted in the thread "CallbackItem.changeCallback() very expensive due to context tracking": http://community.jboss.org/message/527600#527600 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- > mailto:kabir.khan@jboss.com wrote: > > > For B I don't really understand exactly why this is being done? It looks like we check for ContextTracker in each metadata level at INSTANCE level and above, up to JVM. Wouldn't that be handled by the call to metaData.getMetaData() in C anyway?I Changing this to the following works, but maybe we aren't using context tracking in the kernel tests? public ContextTracker getContextTracker() { if (tracker == null || tracker == NOOP) { synchronized (this) { // since we got through, we must be the same caller if (tracker == NOOP) return null; // we waited, got through, but it's now changed if (tracker != null && tracker != NOOP) return tracker; tracker = NOOP; // mark that we're initializing ContextTracker ct = null; MetaData metaData = scopeInfo.getMetaData(); if (metaData != null) { ct = metaData.getMetaData(ContextTracker.class); // if (ct == null) // { // List<ScopeLevel> levels = CommonLevelsUtil.getSubLevels(DEFAULT_MINIMAL); // int instanceIndex = levels.indexOf(CommonLevels.INSTANCE); // for (int i = instanceIndex; i >= 0 && ct == null; i--) // { // MetaData md = metaData.getScopeMetaData(levels.get(i)); // if (md != null) // ct = md.getMetaData(ContextTracker.class); // } // } } tracker = ct; // should we care if it's still null? } } return tracker; } In turn about 60% of the time taken by calling ScopeKey.getScopeLevel(). If the above fix is not ok, I'll need to look at optimizing that. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527600#527600

14 years, 2 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "CallbackItem.changeCallback() very expensive due to context tracking"

by Kabir Khan

JBoss development, A new message was posted in the thread "CallbackItem.changeCallback() very expensive due to context tracking": http://community.jboss.org/message/527596#527596 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- I'm running a benchmark with 10 callbacks installed and 990 beans matching those callbacks, so I end up with 9,900 calls to SingleCallbackItem.changeCallback(). Relevant part of stacktrace along with number of calls and %cpu time taken Thread [main] (Suspended) (19,800 calls, 46.9% cpu) AbstractKernelControllerContext(AbstractControllerContext).getContextTracker() line: 389 (9,900 calls, 47.3% cpu) AbstractKernelControllerContext(AbstractControllerContext).getTarget(ControllerContext) line: 474 (9,900 calls, 47.6% cpu) ClassSingleCallbackItem(OwnerCallbackItem<T,C>).getTarget(ControllerContext, boolean) line: 68 ClassSingleCallbackItem(SingleCallbackItem<T>).changeCallback(ControllerContext, boolean) line: 62 ClassSingleCallbackItem(AbstractCallbackItem<T>).changeCallback(Controller, ControllerContext, boolean) line: 80 ClassSingleCallbackItem(OwnerCallbackItem<T,C>).changeCallback(Controller, ControllerContext, boolean) line: 116 What is really heavy inside ACC.getContextTracker() are: A - 138,600 callls, 34% cpu B - 19,800 calls 10.3% cpu public ContextTracker getContextTracker() { if (tracker == null || tracker == NOOP) { synchronized (this) { // since we got through, we must be the same caller if (tracker == NOOP) return null; // we waited, got through, but it's now changed if (tracker != null && tracker != NOOP) return tracker; tracker = NOOP; // mark that we're initializing ContextTracker ct = null; MetaData metaData = scopeInfo.getMetaData(); //B if (metaData != null) { ct = metaData.getMetaData(ContextTracker.class); //C if (ct == null) { List<ScopeLevel> levels = CommonLevelsUtil.getSubLevels(DEFAULT_MINIMAL); int instanceIndex = levels.indexOf(CommonLevels.INSTANCE); for (int i = instanceIndex; i >= 0 && ct == null; i--) { MetaData md = metaData.getScopeMetaData(levels.get(i)); //A if (md != null) ct = md.getMetaData(ContextTracker.class); } } } tracker = ct; // should we care if it's still null? } } return tracker; } For A, maybe scopeInfo could keep a reference to the MetaData to avoid having to access the repository every time we call scopeInfo.getMetaData()? For B I don't really understand exactly why this is being done? It looks like we check for ContextTracker in each metadata level at INSTANCE level and above, up to JVM. Wouldn't that be handled by the call to metaData.getMetaData() in C anyway? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527596#527596

14 years, 2 months

1
0
0 / 0

[Security Development] New message: "Re: Auth Cache is not flushed after logout"

by Harry Yan

JBoss development, A new message was posted in the thread "Auth Cache is not flushed after logout": http://community.jboss.org/message/527552#527552 Author : Harry Yan Profile : http://community.jboss.org/people/seekerYan Message: -------------------------------------------------------------- Hi, thanks for your reply, i tried that before, but it throws exception "session already in invalid state", as after the webAuthentication.logout() is called, the session is invalid and request.getSession().invalidate() will fail. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527552#527552

14 years, 2 months

1
0
0 / 0

[JCA Development] New message: "Re: JBJCA-272 - Standalone validator tool"

by Jesper Pedersen

JBoss development, A new message was posted in the thread "JBJCA-272 - Standalone validator tool": http://community.jboss.org/message/527518#527518 Author : Jesper Pedersen Profile : http://community.jboss.org/people/jesper.pedersen Message: -------------------------------------------------------------- The initial commit of the standalone validator looks good We can hopefully get some feedback from the community about the usage for future releases, as the current java -jar jboss-jca-validator.jar <file> isn't optimal in the long run. But we have to consider the dependencies that the tool needs. And, we need to keep the standalone validator as a static analyzer as we can't assume that the environment the resource adapter targets is available. Hence we should take the aproach that is currently implemented. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527518#527518

14 years, 2 months

1
0
0 / 0

Ticbco queue jndi lookup

by Narendra Chouhan

In my application I have to connect to two Tibco queue, but while queue lookup it is taking username and password from the jndi.properties. But these credentials are different for both the tibco queue. Queue connection factories are configured in the tibco-jms-ds.xml file. If any one has any Idea how to do this or How to override jndi.properties properties at runtime please let me know. The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/

14 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2010