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

[Design of EJB 3.0] - Re: Unnecessary memory allocation in MethodMetaData & Method

by ALRubinger

Could you send along this benchmark so we can run it on the current impl (head is now in JBossAS 5.x)? re: The simplicity of your implementation - since optimization is done individually by identifying each bottleneck, this is exactly the type of isolation I'd like to see :) S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170880#4170880 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170880

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Unnecessary memory allocation in MethodMetaData & Method

by fl_

Of course I forgot .... versions: JBoss 4.2.1GA (jboss-aop-1.5.5.GA) Java(TM) SE Runtime Environment (build 1.6.0_05-b13) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170878#4170878 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170878

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Unnecessary memory allocation in MethodMetaData & MethodHash

by fl_

Hi, Last time I noticed that our application that we are working on is used to allocating around 500MB per second. As it can be expected GC is getting crazy ;) To accomplish one request our application perform around 10-20 remote invocations. Load under which application allocate 500M/s is about 100 request per second. I just finished small test. The goal of test was check how much memory is allocated per EJB invocation and find a way to optimize it. So testing environment was prepared: Client ---> FacadeBean ----> Worker MDB ------ (X times) -----> TargetBean So Client connect to Facade which was entry point. Facade put one message describing testcase into queue (home many invocation, local or remote interface should be used). Worker MDB perform testcase by invoking TargetBean in loop. Testcase: 500 000 invocations to TargetBean was performed. Each invocation use null values as parameters to reduce synchronization. I found out that one of hot spots of memory allocation was method: java.lang.reflect.Method.toString() which was mostly invoked by following two classes: org.jboss.aop.metadata.MethodMetaData.getMethodMetaData(java.lang.reflect.Method, Object, Object) org.jboss.aop.util.MethodHashing.calculateHash(java.lang.reflect.Method) So I introduced small cache for these strings and modified above two classes to use this cache. Results: | | Remote interface: | time[ms] allocatedMemory[GB] GCscavenge | Baseline: 49559 37.67 7878 | Optimized: 36910 23.38 5339 | | Local interface: | time[ms] allocatedMemory[GB] GCscavenge | Baseline: 18705 18.04 3856 | Optimized: 5267 1.41 449 | Time - is the time needed to accomplish all invocations allocatedMemory - is amount of memory that was allocated to accomplish all invocation. It is not exactly value, it should be treated as estimation, it was measured by -Xloggc GCscavenge - number of scavenge GC events, measured by -Xloggc Do you think it can be point for optimization? 3 times faster for local invocations and ~25% faster for remote. Of course my implementation was extremely simple: 1) concurrent access wasn't taken under consideration - ConcurrentHashMap was used but only one thread thread were used in test scenario so 2) cache maintenance wasn't taken under consideration - is it can cause memory leak if applications will be redeployed often ? Let me know if you want more details about results. BR ps. notice that performance improvement depends on method signature ... so ... to achieve better performance we should use shorter package names ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170877#4170877 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170877

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

Just to conclude the thread... and as we talked today over #jbossmessaging@freenode, I thought undeploy could be translated as deleting the queue to the user, and I thought that would end up with Messages stuck on the journal. As this is not the case this was just my misunderstanding. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170838#4170838 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170838

17 years, 7 months

1
0
0 / 0

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

by timfox

"clebert.suconic(a)jboss.com" wrote : | As I said on the first post: Reclaiming would break... The linked list effect. That was an option on Databases, and that's not an option on the circular journal file system. Why would reclaiming break? It shouldn't make any difference to reclaiming. Can you explain yourself a bit more? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170834#4170834 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170834

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

anonymous wrote : If you want to delete the queue and all it's messages you use the delete queue method. As long as you ensure this is done when the Queue is deleted.. that's fine. My understanding is.. the user has the option of remove/delete the queue by simply removing the XML. If that's not the case.. than it's fine.. but I panic with the possibility of the user removing a queue with pending messages and leaving them stuck forever on the journal. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170833#4170833 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170833

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

Guys, please stick to the topic, I asked whether we should keep message redistribution or not (or change it), not whether we have clustered queues or how we implement clustered queues - that's not changing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170831#4170831 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170831

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

anonymous wrote : The answer is yes. Why is yes not an option? That's the way we did in 1.x and that's the way we do it in 2.0. First message: Reclaiming would break... The linked list effect. That was an option on Databases, and that's not an option on the circular journal file system. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170830#4170830 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170830

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

Anyway... Whatever you do... the requirement I see on Journal is: I - If the user removes the queue -> Message must be removed, or else you would break reclaiming, and it would be impossible reloading the server II - If the user shutdown the server -> Messages should be kept on the journal As long as we respect these requirements this could be implemented anyway you want. My suggestion was just what I saw on the code, and what would be easier implementing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170828#4170828 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170828

17 years, 7 months

1
0
0 / 0

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

by timfox

"clebert.suconic(a)jboss.com" wrote : | Ok.. what you do when the user really undeploy the queue then? You just leave the messages on the journal? | | (Well... yes is not really an option here!) The answer is yes. Why is yes not an option? That's the way we did in 1.x and that's the way we do it in 2.0. Deploy means "I do not want the queue in jndi" that's all. It *does not* and never has meant "delete queue". If you want to delete the queue and all it's messages you use the delete queue method. It's pretty straightforward. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170827#4170827 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170827

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