February 2010 - jboss-user - Jboss List Archives

[JBoss Cache] Document updated/added: "JBoss Cache Official Documentation"

by Manik Surtani

16 years, 2 months

1
0
0 / 0

[Beginner's Corner] New message: "Re: How do I enable pass-by-reference for EJB3 in JBoss AS container?"

by Jerry Simone

User development, A new message was posted in the thread "How do I enable pass-by-reference for EJB3 in JBoss AS container?": http://community.jboss.org/message/527625#527625 Author : Jerry Simone Profile : http://community.jboss.org/people/jlsimone Message: -------------------------------------------------------------- ... Only slightly more information, not all that helpful. I have not been completely sure about whether or not this really was a case of pass-by-reference vs. pass-by-value within the container. When I run my JBoss tests, I notice some strange behavior in the application as well as the NotSerializableException mentioned above. Well, by coincedence, someone was running our WebSphere-based version of the same application the other day and the WebSphere app was showing the same strange behavior and the same NotSerializableException for the same class. The solution in this case was to go to Admin console to the ORB Service configuration for the app and to turn on pass-by-reference (it had gotten turned off somehow). After restarting the app server, the WebSphere app started working normally again. Now I am thinking that this really is a problem with pass-by-value/reference in JBoss. I have read that JBoss is supposed to, by default, use pass-by-reference for method calls between EJBs within the container. I looked at the org.jboss.invocation.InvokerInterceptor (I cannot remember what led me there) and I saw that it looks like it is trying to do the right thing with a local call. I am wondering what I might have done (or not done) to cause JBoss to not use pass-by-reference in this case. I am still looking for the solution. Please let me know if someone needs more information from me or examples of my code or configuration. Thanks all. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527625#527625

16 years, 2 months

1
0
0 / 0

[jBPM] New message: "How to simulating and monitoring JBPM processes ?"

by bb bb

User development, A new message was posted in the thread "How to simulating and monitoring JBPM processes ?": http://community.jboss.org/message/527623#527623 Author : bb bb Profile : http://community.jboss.org/people/babazs Message: -------------------------------------------------------------- Hello! I am searching open-source tools or extensions to simulating and monitoring (BAM,Key Performance Indicators) the JBPM (3 or 4) processes (mainly jpdl and bpel), I want to realize the 6 sigma steps with jbpm. Somene known a good tool (mainly open-source) for this requirements! Thank you so much for any answer! -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527623#527623

16 years, 2 months

1
0
0 / 0

[JBoss Microcontainer] New message: "Re: Classloaders & Domains: Some questions & a suggestion"

by Gilles Compienne

User development, A new message was posted in the thread "Classloaders & Domains: Some questions & a suggestion": http://community.jboss.org/message/527622#527622 Author : Gilles Compienne Profile : http://community.jboss.org/people/gcompienne Message: -------------------------------------------------------------- Sorry for the delay in responding. As expected your code works but I finally found the difference with my tests: If I move transl and Services into their own domain, i.e. by adding a domain attribute as the example below: <Services>/jboss-classoading.xml: <classloading xmlns="urn:jboss:classloading:1.0" domain="InfinispanCacheDomain"> <requirements> <package name="com.alesj.spi"/> </requirements> </classloading> <transl>/jboss-classloading.xml: <classloading xmlns="urn:jboss:classloading:1.0" domain="InfinispanCacheDomain"> <capabilities> <package name="com.alesj.spi"/> </capabilities> </classloading> Then it does not work anymore and Services suddenly starts seeing the Dummy class, even though I didn't declare any dependencies onto it... To me this is wrong, especially as I agree with you that, if I start declaring explicitely the <requirements> then I should not see anything else... Or I am missing something else? Thanks again for your help. Gilles. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527622#527622

16 years, 2 months

1
0
0 / 0

[EJB 3.0] New message: "Re: howto setup jpa using oracle 10g unicode nvarchar2"

by Wolfgang Knauf

User development, A new message was posted in the thread "howto setup jpa using oracle 10g unicode nvarchar2": http://community.jboss.org/message/527619#527619 Author : Wolfgang Knauf Profile : http://community.jboss.org/people/WolfgangKnauf Message: -------------------------------------------------------------- Hi, there is a file "JBOSS_HOME\server\default\standardjbosscmp-jdbc.xml", which contains column type mappings. If you change one of the "Oracle" type mappings to "nvarchar2" and activate the new type mapping in your "..-ds.xml" file, this should work. Snippet from "hsqldb-ds.xml":  <metadata> <type-mapping>Hypersonic SQL</type-mapping> </metadata> Hope this works (I never did something like this) ;-) Wolfgang -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527619#527619

16 years, 2 months

1
0
0 / 0

[jBPM] New message: "Re: Exception handling in JBPM4 ?"

by Yogita Bartake

User development, A new message was posted in the thread "Exception handling in JBPM4 ?": http://community.jboss.org/message/527615#527615 Author : Yogita Bartake Profile : http://community.jboss.org/people/YogitaBartake Message: -------------------------------------------------------------- Thanks Ronald -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527615#527615

16 years, 2 months

1
0
0 / 0

[JCA] New message: "Re: How to create a XA aware connection factory"

by Kreek Fred

User development, A new message was posted in the thread "How to create a XA aware connection factory": http://community.jboss.org/message/527605#527605 Author : Kreek Fred Profile : http://community.jboss.org/people/fredk Message: -------------------------------------------------------------- After spitting through the jboss sourcecode I solved the problem myself: the property 'URLProperty' refers to a named property in the config-property XADataSourceProperties So one should use the following lines in the connection factory: <config-property name="URLProperty" type="java.lang.String">$PROPNAME</config-property> <config-property name="XADataSourceProperties" type="java.lang.String">$PROPNAME=$CONNECTIONSTRING</config-property> where the both $PROPNAME's should be the same and the $CONNECTIONSTRING should be the connection string e.g. <config-property name="URLProperty" type="java.lang.String">URL</config-property> <config-property name="XADataSourceProperties" type="java.lang.String">URL=jdbc:thin:@localhost:1521:XE</config-property> -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527605#527605

16 years, 2 months

1
0
0 / 0

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

by Kabir Khan

User 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

16 years, 2 months

1
0
0 / 0

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

by Kabir Khan

User 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

16 years, 2 months

1
0
0 / 0

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

by Kabir Khan

User 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

16 years, 2 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