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

[Design of POJO Server] - Re: Behavior with AbstractKernelController

by anil.saldhana＠jboss.com

Scott, my last post was after I had totally revamped the testcase to use the ServiceControllerMBean to do the deployment and query for the state of the service. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967210#3967210 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967210

18 years, 1 month

1
0
0 / 0

[Design of JBoss Serialization] - Re: What should I create to frequently ask it for smart clon

by elijah.epifanov＠gmail.com

Heh.. DataContainer isn't thread-safe. DataContainerInput writes to it. public Object readObject() throws ClassNotFoundException, IOException { DataContainer.this.cache.setInput(this); return ObjectDescriptorFactory.objectFromDescription(DataContainer.this.cache, this); } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967199#3967199 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967199

18 years, 1 month

1
0
0 / 0

[Design of JBoss Serialization] - Re: What should I create to frequently ask it for smart clon

by elijah.epifanov＠gmail.com

Oooops. Only works with: synchronized (container) { ObjectInput input = container.getInput(); Object ret = input.readObject(); input.close(); return (I) ret; } When unsynchronized, the stacktrace in first post pops up. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967178#3967178 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967178

18 years, 1 month

1
0
0 / 0

[Design of JBoss Serialization] - Re: What should I create to frequently ask it for smart clon

by elijah.epifanov＠gmail.com

Thank you Clebert ) I am already doing exactly this, and this is thread-safe for read-access. Here is the benchmark for my cache implementation: Sun JDK 1.5.0_07 (x64): Without Serialization: 2.3713 usec JBossSmartClone (DataContainer): 44.784 usec JBossSerialization: 68.773 usec JavaSerialization: 167.959 usec Sun JDK 1.6.0_rc (x64): Without Serialization: 2.1233 usec JBossSmartClone (DataContainer): 34.639 usec JBossSerialization: 57.145 usec JavaSerialization: 152.6278 usec (Note that x64 JDK6 doesn't offer much performance gain, unlike x86 one) Amount of garbage generated is HUGE for all 3 copying methods. Approximate proportions are: JBossSmartClone: 300MB JBossSerialization: 800MB JavaSerialization: 1200MB Much of the garbage comes from ArrayList resizing algorithm, THash rehashing, etc. I'll try to patch some code to use Javolution's PoolContexts. Maybe this will help. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967172#3967172 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967172

18 years, 1 month

1
0
0 / 0

[Design of JBoss Serialization] - Re: What should I create to frequently ask it for smart clon

by elijah.epifanov＠gmail.com

Thank you Clebert ) I am already doing exactly this, and this is thread-safe for read-access. Here is the benchmark for my cache implementation: Sun JDK 1.5.0_07 (x64): Without Serialization: 2.3713 usec JBossSmartClone (DataContainer): 44.784 usec JBossSerialization: 68.773 usec JavaSerialization: 167.959 usec Sun JDK 1.6.0_rc (x64): Without Serialization: 2.1233 usec JBossSmartClone (DataContainer): 34.639 usec JBossSerialization: 57.145 usec JavaSerialization: 152.6278 usec (Note that x64 JDK6 doesn't offer much performance gain, unlike x86 one) Amount of garbage generated is HUGE for all 3 copying methods. Approximate proportions are: JBossSmartClone: 300MB JBossSerialization: 800MB JavaSerialization: 1200MB Much of the garbage comes from ArrayList resizing algorithm, THash rehashing, etc. I'll try to patch some code to use Javolution's PoolContexts. Maybe this will help. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967170#3967170 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967170

18 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Ordering of .ear subdeployments

by dimitris＠jboss.org

The code changes for this approach are minimal. What you've done already, plus an attribute in the ear metadata (defaulting to 'strict') to control whether to set the DeploymentInfo flag or not, (plus fixing the failing test by adding the 'implicit' flag). My only concern is the case where you need to declare the modules in the jboss-app.xml descriptor to get total order (e.g. a -ds.xml and an ejb jar). I don't know whether the standard would require the ejb module to appear in the application.xml descriptor, too. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967162#3967162 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967162

18 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Ordering of .ear subdeployments

by vickyk

Sounds definitely better that the <unifield-loader> approach , looks simpler to implement !!! anonymous wrote : | The only restriction is a module must appear only once in the 2 descriptors. | I did not understand this, why would the user define the same module in both the descriptors. Can you give some use case? I will do the impact analysis for this approach and will come up with the additional changes we need to do. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967150#3967150 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967150

18 years, 1 month

1
0
0 / 0

[Design of JBoss Profiler] - Re: JBoss Profiler Start Up Problems

by clebert.suconic＠jboss.com

It should be straight forward. Just looking for a DLL in a directory path. Take a look at your PATH definition. You might have done something wrong. As for the Eclipse, there is no eclipse integration at this point. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967141#3967141 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967141

18 years, 1 month

1
0
0 / 0

[Design of JBoss Serialization] - Re: What should I create to frequently ask it for smart clon

by clebert.suconic＠jboss.com

DataContainer was not meant to be ThreadSafe. I've never done any tests reusing the same instance in a MultiThread environment. I guess you would do that to use DataContainer as a FactoryObject. (Is that correct?) I double checked DataContainer, and if you use it read-only, it should be thread Safe, as long you don't reuse DataContainerInputs... So, If you have a DataContainer, you should always do: DataContainer source= .... init somehow ... each Thread... ObjectInput input = source.getInput(); // don't reuse these inputs. But again.. I haven't tested this with the exact same scenario you arer using it. Clebert Suconic View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967140#3967140 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967140

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Behavior with AbstractKernelController

by scott.stark＠jboss.org

The lack of an exception from the start attempt is a red-herring as this is not working anyway. The lack of an exception is masked by the catch(Throwable t) which is catching the junit fail call. If this is changed to: | try | { | server.invoke(serviceOName,"create", new Object[0], new String[0]); | server.invoke(serviceOName,"start", new Object[0], new String[0]); | fail("Service should not have started"); | } | catch(Exception t) | { | log.debug("Service has rightly disagreed to start",t); | } | the test fails. The state of the service needs to be queried to ensure that is started rather than relying on getting an exception back. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967130#3967130 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967130

18 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2006