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
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
"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
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