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

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by galder.zamarreno＠jboss.com

I've looked at the thread dumps provided and they all show the similar signs: "This thread dump contains monitors without a locking thread information. This means, the monitor is hold by a system thread or some external resource. You should check the monitors without locking threads for more information. If you see many monitors having no locking thread, this usually means, the garbage collector is running. In this case you should consider analyzing the Garbage Collector output. " Effectively, this means that GC has it. Are these machines multi core? What are the startup options you're using? Did you enable GC logging? Prabhat, I thought we went through similar situation when you're testing 1 node scenarios, didn't we? I think I suggested that you use tools like TDA to discover scenarios like this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170076#4170076 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170076

17 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by galder.zamarreno＠jboss.com

After fiddling a bit with cut, the following produces an output that can be parsed with TDA: cut -d']' -f2- perf11.log | cut -d' ' -f2- > perf11-cut.log View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170068#4170068 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170068

17 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by galder.zamarreno＠jboss.com

Prabhat, I've been away for a little bit. I'll check the thread dumps you first uploaded. One thing about then though. Can you remove [JBoss] from the start of each line of the dump? Otherwise, the dumps have to be grep/cut before they can be parsed by tools like TDA. Glad to hear that the new cache provider is yielding better results :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170064#4170064 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170064

17 years, 7 months

1
0
0 / 0

[Design of JBossCache] - Re: cache statistics via JMX

by galder.zamarreno＠jboss.com

Not sure whether this is already included in CacheMngmtInterceptor, but what about read/write percentages? What about physical size of cache/regions? (I had someone asking this a short while back) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170056#4170056 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170056

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Meta data resolving on same named methods in a class hierarc

by wolfc

I've made an incompatible change to ejb3 meta data bridge to allow access to the declaring class of a method. This will be made available in ejb3-metadata 0.13.0. See also http://www.jboss.com/index.html?module=bb&op=viewtopic&t=140650 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170050#4170050 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170050

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MDR doesn't work on annotated privates

by wolfc

See also https://jira.jboss.org/jira/browse/JBMDR-28 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170047#4170047 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170047

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MDR doesn't work on annotated privates

by wolfc

AnnotatedMetaDataLoader will give back the wrong component meta data retrieval if the method signature was obtained via a constructor which does not take Method. So the work-around is to use make sure that constructor is used. That leaves ejb3 meta data bridge, which for the moment I'm going to refactor onto Method. What is the exact function of MethodSignature as opposed to Method? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170045#4170045 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170045

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Patch to MappedReferenceMetadataResolverDeployer fixes E

by ALRubinger

"ALRubinger" wrote : So how can I determine which spec version is being used so I can take the appropriate action? Possibly the dumbest question ever put forth on this forum. JBossEnterpriseBeanMetaData.isEjb2x() is what I'll use to fix this, but I'll continue to note that I would have expected this to be handled my jboss-metadata and proper decorators on EJB2.x beans to use the right JNDI resolution logic. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170035#4170035 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170035

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Patch to MappedReferenceMetadataResolverDeployer fixes EJB3,

by ALRubinger

Issue is: http://jira.jboss.org/jira/browse/EJBTHREE-1455 EJB References and EJB Local References need to map to the interface-specific proxy to be equipped with proper information for SessionContext.getInvokedBusinessInterface. However, EJB2 has no "interface-specific" Proxies. So how can I determine which spec version is being used so I can take the appropriate action? Patch is: Index: server/src/main/org/jboss/deployment/MappedReferenceMetaDataResolverDeployer.java | =================================================================== | --- server/src/main/org/jboss/deployment/MappedReferenceMetaDataResolverDeployer.java (revision 76968) | +++ server/src/main/org/jboss/deployment/MappedReferenceMetaDataResolverDeployer.java (working copy) | @@ -883,7 +884,8 @@ | { | cdmd.addDependency(target); | // Need to look at the local jndi name | - String localJndiName = target.getBeanMetaData().determineLocalJndiName(); | + String localInterface = ref.getLocal(); | + String localJndiName = target.getBeanMetaData().determineResolvedJndiName(localInterface); | if(localJndiName != null) | ref.setResolvedJndiName(localJndiName); | } | @@ -969,7 +971,8 @@ | // Determine the jndi name for the reference interface | String iface = getInterface(ref); | //LegacyEjb3JndiPolicy policy = new LegacyEjb3JndiPolicy(); | - String containerJndiName = target.getBeanMetaData().determineJndiName(); | + String businessInterface = ref.getRemote(); | + String containerJndiName = target.getBeanMetaData().determineResolvedJndiName(businessInterface); | if(containerJndiName != null) | ref.setResolvedJndiName(containerJndiName); | } This breaks smoke-tests for EJB2.x, but passes my EJB3 defining test case. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170033#4170033 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170033

17 years, 7 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: TransactionManager and AS' ServiceBindingManager

by jhalliday

I've been waiting for ServiceBindingManager to stabilize in AS trunk before updating the transaction integration code to play nice with it. Of course there is an element of chicken and egg here - SBM's not done until it works with the transaction manager :-) The MC bean lifecycle methods in the TransactionManagerService already override some of the property file configuration, for example logging and IP address binding. In the latter case we fish the address out of the ServerConfig.SERVER_BIND_ADDRESS system property, largely though ignorance of any more elegant solution. Is there an MC style way to get this value from the server meta data? For the port binding, I was planning on changing transaction-beans.xml to contain a port, probably something like: property name="port" value="some ref to SBM here" and then use that value to override the one from the jta properties file. MC would then automatically ensure SBM deployed before the transaction manager. As I understand it this is essentially your proposal 1). Since I've not actually started work on it yet I'm happy to change the approach if you feel one of the others is preferable. As it happens there is already a JBTM JIRA for adding system property substitution support, but a) I'm not sure it will make the cut for the next release and b) I don't think it's as elegant an approach for this particular problem. --- There is an additional related problem that need some attention and may as well be tacked on to this discussion: The transaction manager makes extensive use of Uids. One component of uniqueness in the Uid is a process id. Java provides no standard way to get the process id of the JVM from the O/S, so we fudge this by binding to a particular port and using that port number as a pseudo process id. We never actually process traffic sent to the listening port, we are essentially just reserving it to guarantee uniqueness for the process lifetime. There are two issues here: all the transaction using JVMs have to agree which interface to bind the port on. They can't use different real addresses, since the port is uniq only in the scope of the address. In the absence of any override we use localhost. This works from a technical standpoint but confuses users who don't understand why the server is listening on that address even if they have specified something else with -b. Secondly, each process must obviously have a different port number. Right now we start at a given number and walk the range until we find an unoccupied one. The drawback of this is we may wind up on a port that something else which has not yet started also needs. If we wish to configure this though SBM too we clearly need some more properties... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170031#4170031 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170031

17 years, 7 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 August 2008