February 2010 - jboss-user - Jboss List Archives

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

by Kabir Khan

User development, A new message was posted in the thread "Profiling the dependency project": http://community.jboss.org/message/525130#525130 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- > 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 As discussed offline with Ales, I am not doing this fix for alpha6: *if* (stateModel.isValidState(toState)) { *if* (resolveContexts(fromState, toState, trace)) { resolutions = *true*; // break; // Don't exit here } } -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525130#525130

16 years, 5 months

1
0
0 / 0

[JBoss Messaging] New message: ""removeAllMessages" method of the queue mbean is not accessible programmatically via MBean"

by Alexander Lengson

User development, A new message was posted in the thread ""removeAllMessages" method of the queue mbean is not accessible programmatically via MBean": http://community.jboss.org/message/525128#525128 Author : Alexander Lengson Profile : http://community.jboss.org/people/sanches Message: -------------------------------------------------------------- Hello All, There is "removeAllMessages" method in the JMX console for the mbeans from "http://localhost:8080/jmx-console/HtmlAdaptor?action=displayMBeans&filter..." group I was trying to invoke it programmatically, but by some reason appropriate mbean does not provide such operation in runtime. Giving that reference MBeanInfo info is the correct reference to the queue bean, method MBeanOperationInfo[] ops = info.getOperations(); returns me an array which does not contain operation with name "removeAllMessages". It does contain part of the operation from those listed in JMX console, but not all. Is that intentional behavior and there is other way to invoke that method? Or is it bug actually? JBoss 5.1.0.GA Thank you, Alex. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525128#525128

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: DependsOnMe is broken?"

by Ales Justin

User development, A new message was posted in the thread "DependsOnMe is broken?": http://community.jboss.org/message/525125#525125 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > If 2.0.0.Alpha5 worked, I wouldn't have needed to work out in which release the problem was introduced. ;-) OK, found the bug. It's gonna be fixed in Alpha6. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525125#525125

16 years, 5 months

1
0
0 / 0

[JNDI and Naming] New message: "Re: Remote vs. Local client lookup of same JNDI object"

by jaikiran pai

User development, A new message was posted in the thread "Remote vs. Local client lookup of same JNDI object": http://community.jboss.org/message/525124#525124 Author : jaikiran pai Profile : http://community.jboss.org/people/jaikiran Message: -------------------------------------------------------------- Perhaps the connection factory isn't meant to be used outside the JVM where it's hosted. I remember seeing some discussion about this some years back, but cant located that thread now. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525124#525124

16 years, 5 months

1
0
0 / 0

[JNDI and Naming] New message: "Re: Remote vs. Local client lookup of same JNDI object"

by Ben Cotton

User development, A new message was posted in the thread "Remote vs. Local client lookup of same JNDI object": http://community.jboss.org/message/525121#525121 Author : Ben Cotton Profile : http://community.jboss.org/people/ben.cotton@rutgers.edu Message: -------------------------------------------------------------- We are experiencing a problem when a remote desktop Java client attempts to lookup an object by name that is hosted in a JBoss AS 5.1 server's JNDI global namespace. The JBoss admin console displays the following for the name 'IVTCF' in the JNDI global namespace (and it shows a correct and expected value). Global JNDI Namespace +- IVTCF (*class*: com.ibm.mq.connector.outbound.ConnectionFactoryImpl) If we code the following +from a JBoss-deployed servlet+, everything works perfectly ... the JBoss hosted JNDI references correctly uses the IBM JCA resource adapter to bridge to WSMQ implementations of Queue and QueueConnectionFactory. > InitialContext ic = new InitialContext(); > > javax.jms.ConnectionFactory cf = (javax.jms.ConnectionFactory) ic.lookup("IVTCF"); > log.info("'IVTCF' javax.jms.ConnectionFactory found: [" + cf + "]"); > > Queue q = (Queue) ic.lookup("IVTQueue"); > log.info("'IVTQueue' javax.jms.Queue found: [" + q +"]"); > > > However, If I code the following +from a standalone Java client app on a remote dektop machine+, the ConnectionFactory lookup always results with 'factory' == NULL. . Properties props = *new* Properties(); props.setProperty(Context.INITIAL_CONTEXT_FACTORY,"org.jnp.interfaces.NamingContextFactory"); props.setProperty(Context.PROVIDER_URL,"jnp://10.4.164.105:11099"); props.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces"); Context ctx = *new* InitialContext(props); javax.jms.ConnectionFactory factory = (javax.jms.ConnectionFactory)ctx.lookup("IVTCF"); // 'factory' always value = NULL at his time, why? System.out.println("'IVTCF' ConnectionFactory established! IVTCF=["+factory+"]"); Any ideas as to why the remote client lookup always returns a fatcory == NULL value, when the locally deployed servlet's lookup is always able to successfully return a correct value (for the +exact same+ JNDI object name)? We have tried other JBoss forums suggested remedies ( http://community.jboss.org/thread/129674 ) but have not had success. We would like a confirmation that, given the first block of code works correctly, we should reasonably expect the second block of code to also work correctly. It is our belief that the fact that the second block of code does not work may be an indication of a JBoss bug. Agree? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525121#525121

16 years, 5 months

1
0
0 / 0

[JNDI and Naming] New message: "Remote vs. Local client lookup of same JNDI object"

by Ben Cotton

User development, A new message was posted in the thread "Remote vs. Local client lookup of same JNDI object": http://community.jboss.org/message/525119#525119 Author : Ben Cotton Profile : http://community.jboss.org/people/ben.cotton@rutgers.edu Message: -------------------------------------------------------------- We are experiencing a problem when a remote desktop Java client attempts to lookup an object by name that is hosted in a JBoss AS 5.1 server's JNDI global namespace. The JBoss admin console displays the following for the name 'IVTCF' in the JNDI global namespace (and it shows a correct and expected value). Global JNDI Namespace +- IVTCF (*class*: com.ibm.mq.connector.outbound.ConnectionFactoryImpl) -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525119#525119

16 years, 5 months

1
0
0 / 0

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

by Ales Justin

User 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, 5 months

1
0
0 / 0

[JBoss Cache Development] Document updated/added: "Extracting jbosscache async listener stats"

by Daniel Cullender

User 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, 5 months

1
0
0 / 0

[JBoss Web Services] New message: "Re: Where to download jbossws-native-2.0.3.GA.zip?"

by Martin Sarabura

User development, A new message was posted in the thread "Where to download jbossws-native-2.0.3.GA.zip?": http://community.jboss.org/message/525099#525099 Author : Martin Sarabura Profile : http://community.jboss.org/people/steeqs4 Message: -------------------------------------------------------------- I agree it would make my life much easier if I could run the latest versions of everything, but my customers have their own ideas about when to upgrade. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525099#525099

16 years, 5 months

1
0
0 / 0

[JBoss Web Services] New message: "Re: Where to get source for WS 2.0.3?"

by Alessio Soldano

User development, A new message was posted in the thread "Where to get source for WS 2.0.3?": http://community.jboss.org/message/525096#525096 Author : Alessio Soldano Profile : http://community.jboss.org/people/alessio.soldano@jboss.com Message: -------------------------------------------------------------- http://www.jboss.org/jbossws/sourcecode.html -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525096#525096

16 years, 5 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-user February 2010