February 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Strings Experiments...

by clebert.suconic＠jboss.com

I just placed a class called UTFUtil (not being used for now), and a test on timing validating the performance. I'm getting these numbers with org.jboss.messaging.tests.timing.util.UTF8Test: | Time WriteUTF = 3271 | Time WriteUTF = 3061 | Time WriteUTF = 3058 | Time WriteUTF = 3044 | Time WriteUTF = 3055 | Time readUTF = 4166 | Time readUTF = 4137 | Time readUTF = 4153 | Time readUTF = 4144 | Time readUTF = 4151 | time NewUTF = 3003 | time NewUTF = 2849 | time NewUTF = 2834 | time NewUTF = 2832 | time NewUTF = 2837 | spentTime readUTFNew = 3207 | spentTime readUTFNew = 3179 | spentTime readUTFNew = 3179 | spentTime readUTFNew = 3180 | spentTime readUTFNew = 3181 | And these numbers after changing ChannelBufferWrapper to: public ChannelBufferWrapper(final int size) | { | buffer = ChannelBuffers.buffer(size); | buffer.writerIndex(buffer.capacity()); | } | | | Time WriteUTF = 3338 | Time WriteUTF = 3054 | Time WriteUTF = 3077 | Time WriteUTF = 3094 | Time WriteUTF = 3076 | Time readUTF = 4181 | Time readUTF = 4158 | Time readUTF = 4236 | Time readUTF = 4270 | Time readUTF = 4276 | time NewUTF = 2961 | time NewUTF = 2988 | time NewUTF = 2974 | time NewUTF = 2959 | time NewUTF = 2977 | spentTime readUTFNew = 3093 | spentTime readUTFNew = 3126 | spentTime readUTFNew = 3144 | spentTime readUTFNew = 3121 | spentTime readUTFNew = 3134 | | | Time WriteUTF = 3338 | Time WriteUTF = 3054 | Time WriteUTF = 3077 | Time WriteUTF = 3094 | Time WriteUTF = 3076 | Time readUTF = 4181 | Time readUTF = 4158 | Time readUTF = 4236 | Time readUTF = 4270 | Time readUTF = 4276 | time NewUTF = 2961 | time NewUTF = 2988 | time NewUTF = 2974 | time NewUTF = 2959 | time NewUTF = 2977 | spentTime readUTFNew = 3093 | spentTime readUTFNew = 3126 | spentTime readUTFNew = 3144 | spentTime readUTFNew = 3121 | spentTime readUTFNew = 3134 | | If we decide to use this UTF code, it is as simple as: public void putUTF(final String str) throws Exception | { | UTFUtil.saveUTF(this, str); | } | | I will let you guys (Tim) to decide if we should use it or not. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211949#4211949 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211949

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Locks on MainDeployerImpl

by alesj

That's what I meant. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211947#4211947 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211947

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Locks on MainDeployerImpl

by bstansberry＠jboss.com

For the record; I wasn't clear above; you don't need to synchronize in the other places toRedeploy is used because only a single call is made. If in any place you made 2 calls that were meant to be a single unit of work you would need to synchronize on the map. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211945#4211945 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211945

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Locks on MainDeployerImpl

by bstansberry＠jboss.com

No, you don't need to because you are using Collections.synchronizedMap. The map it returns synchronizes on itself in all methods to prevent concurrent access. So synchronizing on it will prevent other threads mutating it in the middle of the two calls. There's some obscure aspect to this I won't go into details here (unless you want), but for reference, this is discussed in detail in section 5.1.1 of Java Concurrency in Practice. You could make toRedeploy a plain HashMap and then put all the calls on it in a synchronized block. That would have the same effect and would be more understandable. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211943#4211943 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211943

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Strings Experiments...

by clebert.suconic＠jboss.com

I'm not saying it's impossible, but I'm not being successful at improving the performance on the UTF. I could save probably 1% of the time by writing directly on the OutputBuffer, with the introduction of ThreadLocals to reuse buffers on the string compressions. (Something that is probably being done at the JDK) (read it as complexity). So.. I don't think it's worth the effort. Think on the UTF as a compressed string: Characters between 1 and 0x7f will use 1 byte on the stream, characters > 0x800 will use 2 and anything between 0x7f and 0x799 will use 3 bytes on the streaming. BTW: the putString was very fast if not using the dynamicBuffer, making putStringNewWay moot. As Tim told me that we are changing this to use RegularBuffers, I'm not changing that. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211932#4211932 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211932

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Locks on MainDeployerImpl

by alesj

Shouldn't then any usage of toRedeploy be in synchronized(toRedeploy) block? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211931#4211931 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211931

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messages are lost on Queue?

by jmesnil

an update about this issue (using trunk r5910). 1. ant runServer 2. ant perfListener -Ddrain.queue=false 3. Ctl+C the perfListener task => on the server side, a RemotingServiceImpl.connectionDestroyed() is triggered * the connection is removed from RemotingServiceImpl connections collection * connection.destroy() is called => this won't call the listeners on the connection (no clean up) Since the connection has been removed from the connections collection, the FailedConnectionTask will never check if it has expired, it won't call fail() on the connection which is the place where the associated resources are cleaned-up. in short, the server will never clean up things when the client is Ctl+C. A fix would be to keep the connection in the connections when RemotingServiceImpl.connectionDestroy() is called and let the FailedConnectionTask a chance to clean up after that. One thing I don't understand: why is a connection detected as failed by the ConnectionFailedTask not removed from the connections? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211888#4211888 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211888

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: The deployers project is a mess

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : Well this appears to be eclipse thing. | | There's an "exclude" on copying *.java to test-classes which also stops .class files | getting copied. | | This changed by Kabir, previously it just used the src/resources as a library folder | directly. | | But if I change it back to be a library folder the AbstractSchemaResolver tests fail because there's now two folders with the same name and getResource() is choosing the | wrong one. | | | | String common = "/org/jboss/test/deployers/vfs/xb/test"; | | URL url = getClass().getResource(common); | | I've reverted this back to a class folder for src/test/resources and moved the jbossxb "deployments" into a seperate unique folder. Now the tests run in both eclipse and maven. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211883#4211883 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211883

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: The deployers project is a mess

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : Well this appears to be eclipse thing. It definitely needs more trace logging in this area. I should be able to understand why the candidate structure failed from the TRACE logging. I shouldn't have to modify code to understand why it is failing to find classes (in this case looking a different place to where I expected). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211879#4211879 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211879

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: The deployers project is a mess

by adrian＠jboss.org

Well this appears to be eclipse thing. There's an "exclude" on copying *.java to test-classes which also stops .class files getting copied. This changed by Kabir, previously it just used the src/resources as a library folder directly. But if I change it back to be a library folder the AbstractSchemaResolver tests fail because there's now two folders with the same name and getResource() is choosing the wrong one. | String common = "/org/jboss/test/deployers/vfs/xb/test"; | URL url = getClass().getResource(common); | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211877#4211877 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211877

17 years, 1 month

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 February 2009