July 2007 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Deployment heuristics - all or nothing

by adrian＠jboss.org

I've completed the other heuristics on that feature request except for those at the front end which depend upon what the Scanner/ProfileService does rather than what the deployers do. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069157#4069157 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069157

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Speeding up the test suite

by timfox

But there is another issue with Hudson. Since Hudson uses VMWare, and does not fully utilise the machines, it is: a) Significantly slower than running the test suite on a dedicated machine b) More seriously, because of the virtualization, any timing issues are brought to the front. Although it still runs a Java program "correctly" you will observer wild differences in thread scheduling and timing which is good for showing up race conditions but extremely bad for any tests that rely on timing to give correct results. Unfortunately, for messaging, some tests do rely on timing. E.g. testing that the expiration of a message happens pretty much on time (also scheduled delivery etc). Now, of course Java even without virtualization is not real time, and gc can happen anytime screwing the timing, but, in practice without virtualization if we add a small margin of error in our timing tests they give good results, this is not the case with virtualization in to play - the required margin of error because so large as to make the test pointless. This may mean I will separate any timing sensitive tests into their own (small) testsuite and this will need to be run on a dedicated team. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069069#4069069 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069069

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Speeding up the test suite

by timfox

Hudson has some windows machines configured. Once I've got everything running fast we'll be able to do full runs on Windows and Linux boxes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069067#4069067 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069067

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: how to delete process deifinitons

by kukeltje

wrong forum... use the user forum for this View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069040#4069040 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069040

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Speeding up the test suite

by ovidiu.feodorov＠jboss.com

I noticed that running tests on Windows is not part of the release checklist anymore. Is this on purpose? People are still running messaging on windows ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069027#4069027 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069027

17 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Space versus time, e.g. JBCACHE-1157

by manik.surtani＠jboss.com

Eh? 1157 has nothing to do with a CHM in UnversionedNode. I did try using a CHM at one point, which did "hide" the issue again, but this posed other problems (inability to store nulls in the node). It's back to HashMap in UnversionedNode now, and the correct fix for 1157 is in the PessimisticLockInterceptor. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069022#4069022 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069022

17 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Space versus time, e.g. JBCACHE-1157

by genman

I meant, Fqn<Integer> versus Fqn<String. Which is why I don't want to make Fqn be only for strings... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068970#4068970 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068970

17 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Space versus time, e.g. JBCACHE-1157

by genman

JBCACHE-1157 changes the HashMap used in an UnversionedNode to a ConcurrentHashMap, which makes an empty node take about 1.3K to store, from about 150 bytes. To do this sort of change on 1.4 might affect people's runtime memory usage quite a bit. For 2.0, I don't know. A cache that has so much overhead sort of bothers me. Perhaps with a "global" NavigableMap (backported from 1.6), you could store all the data in a single flat map, with the following techniques: 1. Node.put(k, v) -> NM.put(new Pair(Fqn, k), v) 2. Node.getMap() -> NM.getRange(new Pair(Fqn, FirstKey), new Pair(Fqn, LastKey)); The main downside is that all operations are of course slower, depending on how the Fqn is constructed. (A Fqn is much faster than Fqn). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068969#4068969 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068969

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JBossAppParsingDeployer issue

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : "scott.stark(a)jboss.org" wrote : I don't see how allowing the structural parse to introduce deployment metadata has any affect on a programmatic deployment. | | | | Because the structural deployer is not invoked if I tell it explicitly what the | structure of the ear is. It is also not invoked if I add a META-INF/jboss-structure.xml | ... | Ok, that is the real problem but I'm ignoring why this has any impact on programmatic deployments other than that to properly provide the structure metadata for an ear without an application.xml, you would have to also provide the J2eeApplicationMetaData. It is too much to assume this will also be programmatic available, so if that is what your saying I agree. I have created an EARContentsDeployer that is ordered after the AppParsingDeployer and runs on ears without META-INF/application.xml to produce the implicit J2eeApplicationMetaData. The jboss-app.xml only ear is being correctly processed with this deployer in the chain. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068959#4068959 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068959

17 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - New message payload types

by mark.little＠jboss.com

Back here Bill asked the question about richer message structures than had at the time. Well we've introduced a few new message payload types and updated the programmer's guide accordingly. The types are: (i) BytesMessage - a structured byte stream. (ii) ObjectMessage - a serialized Java object. (iii) TextMessage - a String. (iv) MapMessage - a tuple space <attribute, value) pairs. (v) ControlMessage - reserved for internal ESB control messages. These are essentially just different views on to the underlying Message payload, but may make it easier to work with/conceptualize complex data structures within the Message. They can all be accessed through the Payload class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068926#4068926 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068926

17 years, 5 months

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 July 2007