[JBoss Microcontainer Development] New message: "Re: Profiling the dependency project"
by Ales Justin
JBoss development,
A new message was posted in the thread "Profiling the dependency project":
http://community.jboss.org/message/525112#525112
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
> is to further modify resolveContexts to not break out of the loop once it resolves some contexts for a state, e.g.
>
> *boolean* resolutions = *true*;
> *while* (resolutions || onDemandEnabled)
> {
> *if* (onDemandEnabled)
> wasOnDemandEnabled = *true*;
>
> onDemandEnabled = *false*;
> resolutions = *false*;
> *for* (ControllerState fromState : stateModel)
> {
> ControllerState toState = stateModel.getNextState(fromState);
>
> *if* (stateModel.isValidState(toState))
> {
> *if* (resolveContexts(fromState, toState, trace))
> {
> resolutions = *true*;
> // break; // Don't exit here
> }
> }
> }
> }
>
Can you do a proof check (proof by-design) that this doesn't break the resolve logic.
At first sight it looks harmless, but we must make sure it's really OK.
e.g. 2nd resolve would resolve same contexts in both scenarios
>
> All tests pass apart from the ones mentioned in http://community.jboss.org/message/524862#524862 which I know how to fix if Ales agrees:
> > mailto:kabir.khan@jboss.com wrote:
> >
> > I mean this:
> >
> > *public* *void* testPlainLifecycleDependencyWrongOrder() *throws* Throwable
> > {
> > plainLifecycleDependencyWrongOrder();
> >
> > ControllerContext context2 = assertInstall(1, "Name2", ControllerState.+CONFIGURED+);
> > ControllerContext context1 = assertInstall(0, "Name1");
> > +assertEquals+(ControllerState.+INSTALLED+, context2.getState());
> >
> > SimpleBeanWithLifecycle bean1 = (SimpleBeanWithLifecycle) context1.getTarget();
> > +assertNotNull+(bean1);
> >
> > SimpleBeanWithLifecycle bean2 = (SimpleBeanWithLifecycle) context2.getTarget();
> > +assertNotNull+(bean2);
> >
> > +assertEquals+(1, bean1.createOrder);
> > +assertEquals+(2, bean2.createOrder);
> > +assertEquals+(3, bean1.startOrder);
> > +assertEquals+(4, bean2.startOrder);
> > }
> >
> > The new resolver works with
> > +assertEquals+(1, bean1.createOrder);
> > +assertEquals+(2, bean1.startOrder);
> > +assertEquals+(3, bean2.createOrder);
> > +assertEquals+(4, bean2.startOrder);
> >
> > The actual hardcoded orders of beans 1 and 2 is an implemetation detail as I see it. The real check is making sure that the initial install of context 2 does not go beyond CONFIGURED and:
> > bean1.startOrder > bean1.createOrder
> > bean2.startOrder > bean2.createOrder
> > bean2.createOrder > bean1.createOrder
> > bean2.startOrder > bean1.startOrder
> >
> >
This does look like an impl detail, so you're fine to change it.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/525112#525112
16 years, 1 month
[Security Development] New message: "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/525111#525111
Author : Harry Yan
Profile : http://community.jboss.org/people/seekerYan
Message:
--------------------------------------------------------------
Hi, can anyone kindly help me?
Currently we tried to migrate our project from JBOSS 4.2 to 5.1, however the Authentication Cache is failed to be flushed after the logout method
is called which worked fine on JBOSS 4.2.Our project leverages the JAAS to do the Authentication and authorization.
Here is the code and config file.
1. LoginModule
We wrote a CustomLoginModule and CustomPrincipal by implementing LoginModule and Principal interfaces accordingly.
Enable the custom LoginModule in login-config.xml file
2. Create a Servlet which logins and calls an ejb bean method.
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
if (request.getParameter("logout") != null) { try {
// Logout WebAuthentication webAuthentication = new WebAuthentication(); webAuthentication.logout(); } catch (Exception e) { e.printStackTrace(out); } } else if (request.getParameter("login") != null) { request.getSession(true); InitialContext context = null; try {
// login method of our custom LoginModule is called. WebAuthentication webAuthentication = new WebAuthentication(); if (webAuthentication.login(username, password)) { System.out.println("web authentication"); } context = new InitialContext(); context.getEnvironment(); A a = (A) context.lookup("ejb/A");
// call ejb method a.helloWorld(); a.withoutRoels(); doGet(request, response); } catch (Exception e) { e.printStackTrace(out); } }
}
3. Create a jboss-web.xml file with the content below
<?xml version="1.0" encoding="UTF-8"?><jboss-web>
<!-- Indicate that the cached auth should be flushed when session expires--><security-domain flushOnSessionInvalidation="true">java:/jaas/FipcaAPUsers</security-domain>
</jboss-web>
4. Add annotation @SecurityDomain("java:/jaas/AppUsers") to ejb bean.
5. The web content is not secured itself, we have a login.jsp which has two buttons: login and logout, when one of the button is clicked, the servlet above is invoked.
On JBOSS 4.2, after we click on the logout, the Auth data is removed from the cache, as we can see that from the jmx-console. But now, on JBOSS 5.1, the auth data is always there. Am I doing anything wrong? Can anyone help me out, this problem has bothered me for quite a long time. I tried many ways but no success.
Thanks in advance!!!
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/525111#525111
16 years, 1 month
[JBoss Cache Development] Document updated/added: "Extracting jbosscache async listener stats"
by Daniel Cullender
JBoss development,
The document "Extracting jbosscache async listener stats", was updated Feb 9, 2010
by Daniel Cullender.
To view the document, visit:
http://community.jboss.org/docs/DOC-14766#cf
Document:
--------------------------------------------------------------
We are currently using jbosscache core 3.2.1.GA and currently push literally millions of records into it. We have asynchronous listeners processing the data as it is put into the cache.
The problem is that the listeners cannot process the data quickly enough and this causes a backlog in the async queue size (which is set to a number in the millions). Increasing the Async pool size over 250 does not help either based on the various (but necessary) locks we have in place.
In order to successfully manage the backlog, we needed to monitor the cache's Async Listener's Queue size to see when it grows to large. Unfortunately, we could not find a way to access these type of stats from the cache, so we downloaded the source code and exposed these stats ourselves.
*Code Modifications*
1. We created a new immutable VO called org.jboss.cache.notifications.NotifierRuntime which holds the various statistics relating to the async listener queue and pool
2. in the org.jboss.cache.notifications.NotifierImpl class, keep a reference to the ThreadPoolExecutor which the BoundedExecutor assigns to the asyncProcessor since this contains all the information you need to extract the queue size (along with other useful stats)
3. expose a method on the org.jboss.cache.notifications.Notifier interface and the org.jboss.cache.Cache interface to expose a method which returns this immutable object (org.jboss.cache.notifications.NotifierRuntime) which is populated with delicious data (Our object contains minimal info, but could easily be extended to expose a whole lot more data).
These statistics have helped us manage the backlog and keep our application afloat.
I have attached the source code and built jar for anyone who has a similar requirement.
--------------------------------------------------------------
16 years, 1 month
[JBoss Microcontainer Development] New message: "DependsOnMe is broken?"
by Adrian Brock
JBoss development,
A new message was posted in the thread "DependsOnMe is broken?":
http://community.jboss.org/message/525060#525060
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
Something in jboss-kernel 2.2.0.Alpha4 breaks the dependsOnMe processing - not tidying it up.
See the jboss-cl testsuite. This test passes using 2.2.0.Alpha3
junit.framework.AssertionFailedError: expected:<0> but was:<1>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.classloading.dependency.test.DependencyUnitTestCase.testDependencyRemoval(DependencyUnitTestCase.java:300)
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/525060#525060
16 years, 1 month