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

[Design of JBoss internal QA (Test Suite)] - Re: AS testsuite using wrong jvm to exectute tests?

by emuckenhuber

"akostadinov" wrote : | That sounds like a better solution but I still see concerns about tests themselves forking by just executing "java". | Well that's why it should be based on the junit.jvm property - as it has the default value "java". If it's not set it would fallback to the one on the PATH. And just execution "java" seems wrong to me. "akostadinov" wrote : | So I still prefer the check if PATH and JAVA_HOME match and fail otherwise. | Well this basically breaks the main benefit for me using JAVA_HOME - so that i can easily switch jdks for testing. Requiring that jdk5 is the first java entry in my PATH would make some other java based apps unusable requiring jdk6. For example the eclipse which comes bundled fedora - not sure about the java plugin for firefox... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209602#4209602 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209602

15 years, 9 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: AS testsuite using wrong jvm to exectute tests?

by akostadinov

"emuckenhuber" wrote : | | ant_exec_command="exec \"$JAVACMD\" $ANT_OPTS | | -classpath \"$LOCALCLASSPATH\" -Dant.home=\"$ANT_HOME\" | | -Dant.library.dir=\"$ANT_LIB\" $ant_sys_opts org.apache.tools.ant.launch.Launcher $ANT_ARGS | | -cp \"$CLASSPATH\" $ant_exec_args" | | | | So you can add -Djunit.jvm= $JAVACMD - then you use the same jdk calling ant :) That sounds like a better solution but I still see concerns about tests themselves forking by just executing "java". So I still prefer the check if PATH and JAVA_HOME match and fail otherwise. Others might think differently though. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209587#4209587 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209587

15 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: split-brain between live and backup node

by jmesnil

moving forward... The test SplitBrainTest.testDemonstrateSplitBrain shows how to reach a split-brain tests where the same messages are consumed by 2 different consumers. To prevent this split-brain to occur where live node remains active once the backup node has been activated, the strategy would be: when the live node lose its replicating connection - this can be because the backup node has been activated or crashed or the network is cut b/w the live and backup node - to check if the live node is isolated or not, it sends a messages to other nodes - if it reaches the quorum, it stays alive - else, it has been cut from both the backup and the other cluster nodes, it kills itself => the backup is the only active node However, this won't solve the split-brain which may occur when the network is cut between the live & backup nodes but the live node remains connected to other cluster nodes. In that case, the live node will reach the quorum and remain active while the backup node has also been activated. What is the required quorum? The simplest solution is to have a majority of members; the members being: - the live node - the backup node - the other live nodes of the cluster Given the special relation between the backup and the live node, the live node should pay special attention to a response from the backup: - if the backup does not reply => the network is still cut between the live and backup node or the backup node is crashed - if it replied => the network failure was transient. In that case, the backup response should include a "active" boolean - if the backup node is active, the live node should kill itself - else, the live node can continue to live (and perhaps it can also reopen its replicating connection to the backup) If there are no other nodes in the cluster, we can't apply this strategy. Another thing worth mentioning: the live & backup should be on the same LAN while the other cluster nodes may be on a WAN. To sum up, I need to think about it more... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209575#4209575 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209575

15 years, 9 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: AS testsuite using wrong jvm to exectute tests?

by emuckenhuber

"akostadinov" wrote : | That should never be a problem for hudson, because it always sets both - JAVA_HOME and PATH. As well our QA scripts do the same when changing java version. | okay good to know :) "akostadinov" wrote : | It makes some sense to have junit.jvm property default to JAVA_HOME/... but see the logic in ant.sh to guess the java executable location. Yes, how about adding this in tools/bin/ant - because there you already have the logic for calling ant with the correct jdk: | ant_exec_command="exec \"$JAVACMD\" $ANT_OPTS | -classpath \"$LOCALCLASSPATH\" -Dant.home=\"$ANT_HOME\" | -Dant.library.dir=\"$ANT_LIB\" $ant_sys_opts org.apache.tools.ant.launch.Launcher $ANT_ARGS | -cp \"$CLASSPATH\" $ant_exec_args" | So you can add -Djunit.jvm= $JAVACMD - then you use the same jdk calling ant :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209574#4209574 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209574

15 years, 9 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: AS testsuite using wrong jvm to exectute tests?

by akostadinov

I see what is the case now. build.sh and ant construct java executable location based on JAVA_HOME environment variable where junit relies on PATH being set correctly. That should never be a problem for hudson, because it always sets both - JAVA_HOME and PATH. As well our QA scripts do the same when changing java version. It makes some sense to have junit.jvm property default to JAVA_HOME/... but see the logic in ant.sh to guess the java executable location. As well there are often cases where JAVA_HOME is not set (AFAIK when user is using the default jvm installed with the OS and probably on systems like azul). It should be possible to change it to: 1. if JAVA_HOME is not set, then set to "java" 2. if JAVA_HOME is set, then to setup like ant.sh does But actually I think it is better to check if the first java executable in PATH is within JAVA_HOME, and if not, then fail the build. I'm sure everybody happened to mismatch these a couple of times, so saved hassle could be considerable. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209569#4209569 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209569

15 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by dimitris＠jboss.org

Can you guys create a JIRA so this DeynamicEndpointDeploymentAspect is fixed properly in a following release? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209568#4209568 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209568

15 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by kabir.khan＠jboss.com

"richard.opalka(a)jboss.com" wrote : "kabir.khan(a)jboss.com" wrote : | | If that doesn't work I think you need to create a ClassLoadingMetaData from the Module, and put that into the deployment as an attachment. | We don't have the Module reference available :( As I said above, we're doing all the magic from servlet code (we're not in deployers processing chain when creating that "minimalistic Deployment") :( You obviously have access to the ClassLoader, so: "kabir.khan(a)jboss.com" wrote : | If you have the deployment's ClassLoader, you can obtain the Module by calling | org.jboss.classloading.spi.dependency.ClassLoading.getModuleForClassLoader() | This method exists in the version of jboss-cl that exists in AS Branch_5_0. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209565#4209565 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209565

15 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by richard.opalka＠jboss.com

However hints/suggestions from AlesJ, AdrianB and others are welcomed to implement it properly. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209564#4209564 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209564

15 years, 9 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: JBoss Profiler 2 Results

by jesper.pedersen

JBoss Profiler 2 doesn't provide a memory leak view, as it is based on 100% on Java - and we would require a native back-end for that. We have a JIRA for it though. But JBoss Profiler 1 will provide you with a memory leak report, so you can you this version :) HTH View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209563#4209563 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209563

15 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by richard.opalka＠jboss.com

"kabir.khan(a)jboss.com" wrote : To be clear I can work around this with my AOP release. So this is not blocking me All the dynamic webservice endpoint publish hara-kiri is one big ugly hack. This JAX-WS spec. requirement is real challenge to be implemented properly. If you can workaround it, then do it please. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209561#4209561 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209561

15 years, 9 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 February 2009