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

[Design the new POJO MicroContainer] - Re: GA releases of mc projects?

by alesj

"adrian(a)jboss.org" wrote : Why would any of the above require a change to the existing api? | You never know. ;-) And in this case, in turned out to be true, since I needed exact distinction between method params signature and constructor params signature in annotations scanning. And I added Javassist version of it all as well, but that's addition, not change. ;-) "adrian(a)jboss.org" wrote : | But bean validation is not really reflection so I'd prefer additional validation api or | integration to be in its own project. i.e. it is something that sits above the reflection layer. | You mean this ;-) - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-jsr303/ "adrian(a)jboss.org" wrote : | Allowing non-public method invocations is just an internal change to do access checks | similar to what I did for non-public fields, i.e. no api change. True. And already done. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151214#4151214 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151214

17 years, 10 months

1
0
0 / 0

[Design of JBoss Serialization] - Re: jboss serialization performance

by patrick145

I have found that on Solaris 10, Java serialization performance exceeds that of JBoss serialization for single-threaded applications across a variety of object types. However, in multi-threaded applications I have found the opposite to be true. It would seem that Java serialization has some sort of synchronization bottleneck in something called: java.lang.Ref.ReferenceQueue$Lock For highly threaded applications, JBoss performance and scalability greatly exceeded that of plain old Java Serialization. TEST #Runs Threads BufferSize File System Serializer Size X/s io 10000 1 32768 ufs Java 21474 142.6 io 10000 2 32768 ufs Java 21474 199.7 io 10000 3 32768 ufs Java 21474 208 io 10000 4 32768 ufs Java 21474 199.7 io 10000 1 32768 swap Java 21474 156.1 io 10000 2 32768 swap Java 21474 203.8 io 10000 3 32768 swap Java 21474 216.9 io 10000 4 32768 swap Java 21474 208 io 10000 1 32768 swap Jboss 25567 116.1 io 10000 2 32768 swap Jboss 25567 249.6 io 10000 3 32768 swap Jboss 25567 368.3 io 10000 4 32768 swap Jboss 25567 474.9 io 10000 8 32768 swap Jboss 25567 828.9 io 10000 12 32768 swap Jboss 25567 986.5 io 10000 16 32768 swap Jboss 25567 1095.9 For larger sample sizes the difference between Java and JBoss diverged. So, I think the answer to the "which is faster?" question is correctly answered by the age-old response "It depends." If your application is highly threaded and needs to scale, JBoss is likely for you. If single threaded serialization is fine, Java serialization may be for you. Of course, the landscape is likely to change again in Java 1.6 and 1.7. However, until WebSphere supports this version of the JDK, it is not relevant for my situation. - Pat View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151190#4151190 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151190

17 years, 10 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Relying on ClassLoader.getResource results in unexpected

by flavia.rainone＠jboss.com

I have created a jira issue for setting this requirement in the documentation: http://jira.jboss.com/jira/browse/JBAOP-574 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151174#4151174 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151174

17 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - bug triage...

by kukeltje

I did some work Closed or set 'fix-version' for 24 issues and made a placeholder for issues which I think need some triage from others. If you guys could spent a little time on http://jira.jboss.com/jira/browse/JBPM-1174, the number of dangling issues will be lower still. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151170#4151170 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151170

17 years, 10 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Relying on ClassLoader.getResource results in unexpected

by flavia.rainone＠jboss.com

David, I agree with you. But, in this case, I think I'll add an observation to the JBoss AOP docs, to avoid this type of confusion. There is no way the final user could guess that s/he has to overwite those methods without knowing the innerworkings of bytecode instrumentation (unless I'm missing something here). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151133#4151133 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151133

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Optimisations: A couple of low hanging fruits going for

by timfox

"jmesnil" wrote : | If your question is "Is Apple's JVM slow and crappy", the answer is a resounding YES! :) See, that's what happens when you sacrifice style for performance! ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151116#4151116 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151116

17 years, 10 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Relying on ClassLoader.getResource results in unexpected

by david.lloyd＠jboss.com

I don't know of any other way to either verify the existence (well, potential loadability) of a class without loading it, or getting the actual class bytes, than using the getResource methods. I know that we (in the Remoting project) also use the getResource methods to get the class bytes to transmit when using remote classloading. I think it's reasonable to require the user to implement at least getResource(URL) in their custom classloader. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151115#4151115 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151115

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Optimisations: A couple of low hanging fruits going for

by jmesnil

"timfox" wrote : Great! | | (1000 seems pretty slow though - I can send around 30K 1K messages / sec) If your question is "Is Apple's JVM slow and crappy", the answer is a resounding YES! :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151114#4151114 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151114

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Optimisations: A couple of low hanging fruits going for

by timfox

Great! (1000 seems pretty slow though - I can send around 30K 1K messages / sec) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151111#4151111 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151111

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Optimisations: A couple of low hanging fruits going for

by jmesnil

"trustin" wrote : "timfox" wrote : "timfox" wrote : | | | Instead I think we should use a variant 2 UUID. | | | | http://www.webdav.org/specs/draft-leach-uuids-guids-01.txt | | This might also be useful: | | http://jug.safehaus.org/ Thanks for the link. Using code from this project, I've substantially improved our perf: disable jms message: 10133 msg/s enabled jms message [old code]: 7183 msg/s enabled jms message [new code]: 9806 msg/s The same code path is 26% faster and very close to the "disable" case (97%) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151104#4151104 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151104

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