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

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

by galder.zamarreno＠jboss.com

"bstansberry(a)jboss.com" wrote : Re: the different invoker types, is it a big deal to do them all? I suppose the biggest hassle is testing. Do you think it's possible to unit test this with mock objects, letting you basically plug in the different invokers into the same test fixture without having to deploy to the AS? Without deploying to AS?Hmmmmm, not sure. My current tests for 4.0.x worked by deploying EJBs using Mock invoker/invokerproxy versions that injected failures. I can look into it though. "bstansberry(a)jboss.com" wrote : One reason to fix them all is that I believe the current mechanism for checking if failover is allowed is broken; i.e it uses the Transaction from Invocation.getTransaction() rather than the TransactionPropagationContext. Thus it misses the case where UserTransaction is used. So, fixing that is a side benefit of JBAS-4555. +1 Ok, I'll implement this for all invokers and will look into the most efficient way to unit test them all. Re: different load balance load balance policies Couple of questions came to my mind here: 1.- Rather than implementing 4 brand new policies, it might be easier to add a new element to cluster-config XML called transaction-sticky with true/false values and modify the existing load balance policies to act upon the value of that element, what do you think? This hasn't been fully baked, it's just something that I had in mind. 2.- Should transaction sticky (either implementations or solution mentioned in 1) be the default? IMO, 4.x should maintain existing (default) behavior while transaction sticky should be default in trunk. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080109#4080109 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080109

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Maven depency issues

by scott.stark＠jboss.org

Looking at the jdk5 javac docs, I don't see any dependency related options. I thought there used to be such a thing. I don't know how throughly class to class file dependency checking is done then. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080100#4080100 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080100

17 years, 4 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

by bstansberry＠jboss.com

anonymous wrote : So, I believe you suggest that I create different versions of TxLoadBalancePolicy which default on the ones mentioned above (as well as RR) if no transactions are running, correct? Correct. Re: the different invoker types, is it a big deal to do them all? I suppose the biggest hassle is testing. Do you think it's possible to unit test this with mock objects, letting you basically plug in the different invokers into the same test fixture without having to deploy to the AS? One reason to fix them all is that I believe the current mechanism for checking if failover is allowed is broken; i.e it uses the Transaction from Invocation.getTransaction() rather than the TransactionPropagationContext. Thus it misses the case where UserTransaction is used. So, fixing that is a side benefit of JBAS-4555. The JRMP/Pooled invokers still exist in trunk and are deployed. They are gone from standard-jboss.xml though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080097#4080097 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080097

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Maven depency issues

by scott.stark＠jboss.org

The main question is how the artifacts seem to be getting out of date for the mc projects. For the case I just ran into it could be that javac is not picking up dependencies correctly in terms of rebuilding classes and not a mvn issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080089#4080089 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080089

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mvn vs eclipse test runs

by scott.stark＠jboss.org

So after doing a mvn clean/install from the mc root, all is well: anonymous wrote : | [starksm@succubus kernel]$ mvn test | [INFO] Scanning for projects... | [INFO] ---------------------------------------------------------------------------- | [INFO] Building JBoss Microcontainer Kernel | [INFO] task-segment: [test] | ... | Tests run: 823, Failures: 0, Errors: 0, Skipped: 0 | so apparently mvn is not tracking the state of the mc projects correctly? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080085#4080085 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080085

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mvn vs eclipse test runs

by scott.stark＠jboss.org

Looking at one test failure, the problem seems to be that the dependency module is not up to date: | <testcase time="0.004" name="testValueFactory"> | ? | <error type="java.lang.AbstractMethodError" message="org.jboss.dependency.plugins.AbstractDependencyInfo.setAutowireCandidate(Z)V"> | java.lang.AbstractMethodError: org.jboss.dependency.plugins.AbstractDependencyInfo.setAutowireCandidate(Z)V | at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.&init&(AbstractKernelControllerContext.java:87) | at org.jboss.kernel.plugins.dependency.AbstractKernelController.install(AbstractKernelController.java:94) | at org.jboss.kernel.plugins.dependency.AbstractKernelController.install(AbstractKernelController.java:89) | at org.jboss.test.kernel.config.test.AbstractKernelConfigTest.instantiate(AbstractKernelConfigTest.java:114) | at org.jboss.test.kernel.config.test.AbstractKernelConfigTest.instantiate(AbstractKernelConfigTest.java:108) | at org.jboss.test.kernel.config.test.ValueFactoryTestCase.instantiateHolder(ValueFactoryTestCase.java:89) | at org.jboss.test.kernel.config.test.ValueFactoryTestCase.testValueFactory(ValueFactoryTestCase.java:70) | at org.jboss.test.kernel.config.test.ValueFactoryTestCase.testValueFactory(ValueFactoryTestCase.java:70) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at junit.framework.TestCase.runTest(TestCase.java:154) | at junit.framework.TestCase.runBare(TestCase.java:127) | at junit.framework.TestResult$1.protect(TestResult.java:106) | at junit.framework.TestResult.runProtected(TestResult.java:124) | at junit.framework.TestResult.run(TestResult.java:109) | at junit.framework.TestCase.run(TestCase.java:118) | at junit.framework.TestSuite.runTest(TestSuite.java:208) | at junit.framework.TestSuite.run(TestSuite.java:203) | at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) | at junit.extensions.TestSetup$1.protect(TestSetup.java:19) | at junit.framework.TestResult.runProtected(TestResult.java:124) | at junit.extensions.TestSetup.run(TestSetup.java:23) | at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) | at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) | at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) | at org.apache.maven.surefire.Surefire.run(Surefire.java:132) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) | at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) | </error> | anonymous wrote : | [DEBUG] jboss-dependency: using locally installed snapshot | [DEBUG] Retrieving parent-POM: org.jboss.microcontainer:jboss-microcontainer::2.0.0-SNAPSHOT for project: null:jboss-dependency:jar:2.0.0-SNAPSHOT from the repository. | and it looks like this could be out of date: anonymous wrote : | [starksm@succubus bin]$ ls -lt /home/svn/repository.jboss.com/maven2/org/jboss/microcontainer/jboss-dependency/2.0.0-SNAPSHOT/ | total 380 | -rw-rw-r-- 1 starksm starksm 374 Aug 31 09:05 maven-metadata-jboss-snapshots.xml | -rw-rw-r-- 1 starksm starksm 374 Aug 31 09:05 maven-metadata-snapshots.jboss.org.xml | -rw-rw-r-- 1 starksm starksm 40 Aug 31 07:58 maven-metadata-jboss-snapshots.xml.sha1 | -rw-rw-r-- 1 starksm starksm 40 Aug 31 07:58 maven-metadata-snapshots.jboss.org.xml.sha1 | -rw-rw-r-- 1 starksm starksm 57104 Aug 30 23:50 jboss-dependency-2.0.0-SNAPSHOT.jar | -rw-rw-r-- 1 starksm starksm 57017 Aug 30 23:50 jboss-dependency-2.0.0-SNAPSHOT-plugins.jar | -rw-rw-r-- 1 starksm starksm 2316 Aug 30 23:50 jboss-dependency-2.0.0-SNAPSHOT.pom | -rw-rw-r-- 1 starksm starksm 56237 Aug 30 23:50 jboss-dependency-2.0.0-SNAPSHOT-sources.jar | -rw-rw-r-- 1 starksm starksm 15476 Aug 30 23:50 jboss-dependency-2.0.0-SNAPSHOT-spi.jar | -rw-rw-r-- 1 starksm starksm 328 Aug 30 23:50 maven-metadata-local.xml | -rw-rw-r-- 1 starksm starksm 52054 Aug 28 20:16 jboss-dependency-2.0.0-20070809.154918-6.jar | -rw-rw-r-- 1 starksm starksm 40 Aug 28 20:16 jboss-dependency-2.0.0-20070809.154918-6.jar.sha1 | -rw-rw-r-- 1 starksm starksm 47496 Jul 28 13:45 jboss-dependency-2.0.0-SNAPSHOT-jdk14.jar | After doing a clean/install of the dependency project, I see a different result for the kernel: anonymous wrote : | Tests run: 805, Failures: 240, Errors: 135, Skipped: 0 | so it looks like the mc modules are not being properly rebuilt. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080083#4080083 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080083

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Maven depency issues

by pgier

I just wanted to bring up some of the issues with dependencies in maven that came up recently. Here is a summary of the issues and how to deal with them, as far as I see it. Classpath ordering in maven Currently, maven puts transitive dependencies before direct dependencies in the compile and test classpaths. I believe this is incorrect, and I will be submitting a patch to reverse this, but it won't be available until the next maven version. It normally isn't an issue, unless there are two different versions of the same artifact in the dependency tree. The way to get around this, is to exclude the conflicting versions from the transitive dependencies. | <dependency> | <groupId>jboss</groupId> | <artifactId>jbossxb</artifactId> | <exclusions> | <exclusion> | <groupId>jboss</groupId> | <artifactId>jboss-common-core</artifactId> | </exclusion> | <exclusion> | <groupId>jboss</groupId> | <artifactId>jboss-common-logging-spi</artifactId> | </exclusion> | </exclusions> | </dependency> | The easiest way that I know of to find these conflicting dependencies is by using the dependencies project info report mvn project-info-reports:dependencies It's a pita to go through all the modules and find instances of these conflicts, but someone (maybe me) should go through the mc modules and fix them. Another command that can help clean up dependencies is this one: mvn dependency:analyze The report will tell you if you have unused dependencies listed, or if you are directly dependent on one of your transitive dependencies. When I have time, I plan to add a feature to this plugin that will tell you if you are including two versions of the same artifact. Non-deterministic builds? As far as I have seen, the classpath ordering seems to be the same every time. I think when Adrian had a different result, it was probably do to an out of date pom, or possibly something different in the local repository. Anyway, I don't think this is an issue because as far as I've seen, the ordering of the dependencies is consistent. Releases/assembly The assembly plugin can be used to package up dependencies with the project. As long as the conflicting versions are excluded from the transitive dependencies, we should always get the correct version included in the release. The assembly plugin will also have the same behaviour during a normal build as during a release, so there shouldn't be any difference in the generated artifact when doing the release, or when re-creating the release at a later time. Hopefully this addresses some of the concerns that people have had about the maven builds. Obviously, all this is open to discussion :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080082#4080082 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080082

17 years, 4 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

by galder.zamarreno＠jboss.com

"bstansberry(a)jboss.com" wrote : A minor limitation of this is the tpc/target map is stored as a static field in the invoker proxy. So, if two beans involved in the tx use different proxy types (say unified and pooled), the chosen server won't be the same. There's no real good way around this, since use of different proxy types implies different invokers on the server side, and hence different sets of targets. | | The above comment is meant for the tiny fine print at the bottom of the documentation of this. ;-) As far as 4.2 is concerned, JRMP/Pooled and Unified invokers exist although the default ones are Unified. JRMP/Pooled are legacy so is there any reason why customers would want to use these? I'd expect for Unified to be at least as good as JRMP/Pooled, but I can see customers wanting to stick their environment to what it was like in 4.0.x, i.e. having as less changes as possible. I haven't checked the trunk codebase, but the descriptors in trunk don't even show the JRMP/Pooled invokers. To sum up, +1 on fine print :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080071#4080071 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080071

17 years, 4 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

by galder.zamarreno＠jboss.com

"bstansberry(a)jboss.com" wrote : Don't assume the client uses a transaction. A requirement for JBAS-4455 is that the LBP impl has to work the same as the existing impls if there is no tx in effect. | | 1) If you only create a RoundRobin version of this, and people configure it for an SFSB, a client that doesn't start a tx can't get sticky session semantics (FirstAvailable). Even if they do start w/ a tx, they become unstuck if they keep using the bean after they commit the tx. | | 2) People who want Random semantics if no tx is in effect also can't have that. | | 3) Same for FirstAvailableIdenticalAllProxies. Yeah, you're right on this. So, I believe you suggest that I create different versions of TxLoadBalancePolicy which default on the ones mentioned above (as well as RR) if no transactions are running, correct? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080068#4080068 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080068

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-204, isX getter

by scott.stark＠jboss.org

Yes, I know and seem to remember tests explicitly for this in jmx tests. Its just that this behavior seems obsolete with autoboxing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080043#4080043 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080043

17 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2007