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

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

by prabhat.jha＠jboss.com

Galder, I ran one test configuration (OL, INV_SYNC, lazy=true) in hibernate with the GC options you mentioned and results are not as good when not using these options. I am running other configurations and see how it looks like. I will update you all. Just to make sure, this is what server startup looks like: java -server -Xms3072m -Xmx3072m -XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseLargePages -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djgroups.udp.ip_ttl=1 -jar /tmp/pjha/eap43-portal26/bin/run.jar -c production -b 10.18.1.131 -Djboss.partition.name=PortalScalabilityTestPartition -Dcluster.route.name=perf13 -u 239.11.12.13 -Dsf.pid=FR5VbgAgyO09Z8vq | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170794#4170794 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170794

17 years, 7 months

1
0
0 / 0

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

by adrian＠jboss.org

"wolfc" wrote : | It's not the same semantic. The semantic is designed to be the same as | Class.get{Declared}Method(String name, Class.. parameters); | the idea is you don't need to know the method/class, only its signature, | that's why the class/key is called "Signature". :-) If get{Declared}Method was a static method I would agree with you. It's not, there always is a class in play. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170790#4170790 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170790

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message redistribution in JBM 2.0 - request for feedback

by timfox

When you say Singleton I think you really mean "non clustered queue". Singleton is something quite different - it's when you have the queue on only one node of the cluster and is not currently supported by JBM. Regarding your brain storm - I don't think this is a good idea. The idea was to simplify, not make things more complex. KISS principle again. ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170788#4170788 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170788

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Management removing all messages on shutdown

by timfox

I don't think you need to change anything related to the shutdown hook, it's just a simple bug in JMSServerDeployer. The undeploy method should just be removing the objects from jndi - not deleting them! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170786#4170786 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170786

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Management removing all messages on shutdown

by timfox

Just don't delete the queue! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170784#4170784 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170784

17 years, 7 months

1
0
0 / 0

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

by adrian＠jboss.org

"wolfc" wrote : | I'm happy to use DeclaredMethodSignature though, so if that's the solution please leave that one in. :-) | The idea of DeclaredMethodSignature is to get something working. I'd much rather use MethodSignature, it's just a case of finding a way to do it without adding performance penalities to (or even worse breaking) existing code. Like I said in an earlier post, once we know how to do that, we can retrofit DeclaredMethodSignature to be: | @Deprecated // legacy hack | public class DeclaredMethodSignature extends MethodSignature { ... } | anonymous wrote : | I still think there should be some assertion that prevents me from abusing MethodSignature though. | | assert method == ReflectionUtils.findMethod(clazz, signature.getName(), signature.getParametersTypes(clazz)) : "You're abusing JBMDR-28"; | In AnnotatedMetaDataLoader? It doesn't impose performance downgrades, but it's not really friendly/usable. Add it if you want, or raise a JIRA issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170782#4170782 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170782

17 years, 7 months

1
0
0 / 0

[Design of JBoss Profiler] - is there a web front end for Beta1 version?

by rodgerca

I've got my profiler working and some nice memory snapshots. I notice in previous releases there is a jboss-profiler.war but not in Beta1. Is this available for Beta1? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170777#4170777 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170777

17 years, 7 months

1
0
0 / 0

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

by wolfc

"adrian(a)jboss.org" wrote : Not it's not a DeclaredMethodSignature. The metadata contexts associated | with those are not populated with the data loaded into MethodSignatures. | | The DeclaredMethodSignatures is a hack so you can shadow | methods on the super class. | | It's not the same semantic. The semantic is designed to be the same as | Class.get{Declared}Method(String name, Class.. parameters); | the idea is you don't need to know the method/class, only its signature, | that's why the class/key is called "Signature". :-) If get{Declared}Method was a static method I would agree with you. It's not, there always is a class in play. "adrian(a)jboss.org" wrote : No it's not. It just does not do the horrible semantic you want it to do | which is why we introduced the DeclaredMethodSignature. | | The test currently passes anyway, but then it is a useless test. Hehe, actually it does my semantic. That's the horrible thing about it. :-) This one does your semantic: public void testMutable() throws Exception | { | MemoryMetaDataLoader loader = new MemoryMetaDataLoader(); | MetaData metaData = new MetaDataRetrievalToMetaDataBridge(loader); | | Method superMethod = SuperClassOfNotPublic.class.getDeclaredMethod("sameName"); | loader.addAnnotation(superMethod, new TestAnnotationImpl()); | MetaData superMethodMetaData = metaData.getComponentMetaData(Signature.getSignature(superMethod)); | assertAnnotation(superMethodMetaData, TestAnnotation.class); | | Method method = NotPublic.class.getDeclaredMethod("sameName"); | MetaData methodMetaData = metaData.getComponentMetaData(Signature.getSignature(method)); | assertNoAnnotation(methodMetaData, TestAnnotation.class); | } And it fails in the last assert (because I wrote it according to my semantics). It's exactly the same as the AnnotatedMetaDataLoader test. "adrian(a)jboss.org" wrote : The test that demonstrates the semantic you asked for is | AnnotatedElementLoaderDeclaredMethodSignatureTestCase. | | The root of your difficulty is this call | | | MetaData superMethodMetaData = metaData.getComponentMetaData(Signature.getSignature(superMethod)); | | | | which doesn't return the superMethod metadata. | | When you should be doing | | | | MetaData superMethodMetaData = metaData.getComponentMetaData(new DeclaredMethodSignature(superMethod)); | | This is were I'm going now. I now pass in the DeclaredMethodSignature and it works out fine. "adrian(a)jboss.org" wrote : We could add a new method: | | | public static Signature getSignature(Class<?> clazz, Member member) | | { | | if (member == null) | | throw new IllegalArgumentException("Null member"); | | | | if (member instanceof Method) | | { | | Method method = Method.class.cast(member); | | Method other = method; | | // See if we are masking the method | | if (clazz != method.getDeclaringClass()) | | other = ReflectionUtils.findMethod(clazz, method); | | // Yes | | if (other.equals(method) == false) | | return new DeclaredMethodSignature(member); | | // No | | else | | return new MethodSignature(method); | | } | | ... | | | | But then it would be horribly slow for all other users. I don't want to impose performance penalties for all. We already have code in EJB3 which checks for overloading. "adrian(a)jboss.org" wrote : Alternatively, we could change MethodSIgnature to include the "DeclaringClass" | in its equals(). But then people who don't know the DeclaringClass, | e.g. populating metadata from xml would have to do the findMethod().getDeclaringClass() | upfront to populate the MethodSignature, otherwise the equals() would no longer work. | | Since Signature.equals() is designed to work before the classes are loaded | that would be difficult - though not impossible with javassist, | | Nothing actually uses it that way at the moment, but there are obvious performance | improvements (on the roadmap) to be gained by not duplicating annotation | loading, javassist parsing and caching work across AOP, annotation scanning, ClassInfo, etc. | | If you continue to just say it is a bug, instead of suggesting how we make | your semantic work without breaking (including performance) every other | use case, I'd be inclined to just remove the *experimental* DeclaredMethodSignature | and tell you to do the hack yourself in your code. :-) Oi, I've already refactored ejb3-metadata on top of it. I just find it weird that AnnotatedElementMetaDataLoader semantics have changed with JBMDR-28 (in my favour though :-) ). And that MemoryMetaDataLoader doesn't adhere to Java semantics. (If used in conjunction with MethodSignature.) It also means that both MetaDataLoaders do not behave in the same fashion. This nags me. I'm happy to use DeclaredMethodSignature though, so if that's the solution please leave that one in. :-) I still think there should be some assertion that prevents me from abusing MethodSignature though. assert method == ReflectionUtils.findMethod(clazz, signature.getName(), signature.getParametersTypes(clazz)) : "You're abusing JBMDR-28"; In AnnotatedMetaDataLoader? It doesn't impose performance downgrades, but it's not really friendly/usable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170776#4170776 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170776

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Management removing all messages on shutdown

by clebert.suconic＠jboss.com

We just need the shutdown hook on JBMBootstrapServer somehow stopping deployments instead of undeploying them. That would give us the differentiation we need: | public void shutDown() | { | log.info("Shutting down"); | ListIterator<KernelDeployment> iterator = deployments.listIterator(deployments.size()); | while (iterator.hasPrevious()) | { | KernelDeployment deployment = (KernelDeployment) iterator.previous(); | try {undeploy(deployment);} catch (Throwable ignored){} | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170761#4170761 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170761

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message redistribution in JBM 2.0 - request for feedback

by clebert.suconic＠jboss.com

IMO the user should have an option. In some cases where you don't have more than few messages/second in a queue, the Singleton queue would make more sense for the user, but in cases where you would flood the servers the clustered queue is necessary. Just a brain storm: Maybe we could change the behavior based in some statistics? Say after a message start flooding one server we change the distribution schema from single to partial queue? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170759#4170759 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170759

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