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

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

by timfox

"clebert.suconic(a)jboss.com" wrote : | You have to change perfSender a little for this. | You have to use it transacted, and you have to make sure you use Persistent Messages. That's what it does already! Have you actually ran the test? Remember we're talking about perfSenderTransactional - not perfSender!! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151096#4151096 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151096

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 clebert.suconic＠jboss.com

"ataylor" wrote : anonymous wrote : Another point also... Making ClientProducerIimpl to use nonBlocking on transacted sends, made those to be much slower on my computer. It is taking about 200 msgs/second against 2000 as it used to be when sending blocking. | | Clebert, I ran these on my machine and the performance was fine! You have to change perfSender a little for this. You have to use it transacted, and you have to make sure you use Persistent Messages. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151093#4151093 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151093

17 years, 10 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: jboss-app.xml required for isolation

by alex.loubyansky＠jboss.com

Fixed. The testcase is org.jboss.test.deployers.ear.test.JBossAppParsingDeployerUnitTestCase View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151090#4151090 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151090

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 haven't found any Javassist documentation in this regard. This issue is mentioned, however, in an apache mail list: http://mail-archives.apache.org/mod_mbox/hivemind-user/200501.mbox/%3CBAY... anonymous wrote : The given class loader must have both getResourceAsStream() and | getResource(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151089#4151089 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151089

17 years, 10 months

1
0
0 / 0

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

by flavia.rainone＠jboss.com

A JBoss AOP user discovered a bug in JBoss AOP when using a class loader he himself defined to load interceptors and intercepted classes: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150812#4150812 JBoss AOP Class Pool is not able of finding the generated abstract joinpoint class (the one that is generated to be super class of the generated joinpoint classes). My theory is that this is happening because AOPClassPool assumes that, if it can find the resource through ClassLoader.getResource method, then the class is available. Since the class loader defined by the user does not overwrite getResource, it will return null, even if it can load the queried class. As a consequence, AOPClassPool.getCached(String) returns null, and ScopedClassPool will try to find the class file by itself. But Javassist also relies on the ClassLoader.getResource and ClassLoader.getResourceAsStream methods (at LoaderClassPath class). So, Javassist also fails to load the class. I haven't found a Java documentation affirming that we can rely on getResource methods to figure out the class file. If this is the case, is it possible to avoid this situation? If not, we should add at a constraint to the documentation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151085#4151085 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151085

17 years, 10 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - jboss-app.xml required for isolation

by alex.loubyansky＠jboss.com

I assumed it's a bug. At the moment only setting isolated to true in ear-deployer-beans.xml on JBossAppParsingDeployer will not isolate EARs. Here is the jira issue which includes a fix http://jira.jboss.com/jira/browse/JBAS-5524 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150977#4150977 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150977

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

I don't like the idea of using random UUIDs for the reasons already mentioned. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150970#4150970 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150970

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 : "jmesnil" wrote : | | It seems the bottleneck is the generation of the UUID. | | | | When using UUID.randomUUID(), the implementation uses a SecureRandom. | | If I use Random instead and creates the UUID with new UUID(rand.nextLong(), nextLong(), the perf increases significantely. | | | | I don't think we should be using random UUIDs at all, since they're... well random (so can clash). | | Instead I think we should use a variant 2 UUID. After thinking a little about it, I think we do not uniquely identify the right object. We do not need to generate a UUID for every message. We should instead generate a UUID for our MessageProducer and append a sequence number for each message sent by this producer. This means we only need to generate a single UUID per producer. This so significantely reduces the number of generated ID that I think we can consider using a Random UUID with a unsignificant risk of clash. If we do that our message ID will have the format: "ID:<producer uuid>:<sequence number>" wdyt? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150963#4150963 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150963

17 years, 10 months

1
0
0 / 0

[Design of JBoss Profiler] - profiler taking a long time to get stats on version 2.0 beta

by minixman

All I installed the beta version of the profiler as per the readMe. when i run java -jar jboss-profiler-client.jar startProfiler Login to my app running on jboss. then issue java -jar jboss-profiler-client.jar stopProfiler It just hangs for a while, and does nothing for a very long time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150961#4150961 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150961

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 ataylor

anonymous wrote : Another point also... Making ClientProducerIimpl to use nonBlocking on transacted sends, made those to be much slower on my computer. It is taking about 200 msgs/second against 2000 as it used to be when sending blocking. Clebert, I ran these on my machine and the performance was fine! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150958#4150958 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150958

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