[JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1728 at 11/6/13 1:13 PM:
--------------------------------------------------------------------
So, because JGroups uses suite files to control the testsuite, there is no easy way to turn parallelism on and off.
There was a mechanism in place which used the system properties listed in the first comment and passed those through to the runtest macro, but these had no effect on the suite definition files. We must somehow modify these files for parallel and non-parallel test execution modes.
One way would be to have a set of suite files for non-parallel mode, and another set of suite files for parallel mode. We could then use the parallel.tests and parallel.methods build properties to control which suite definition file (parallel or non-parallel) was picked up for test execution. But if you wanted to change say the thread-count of the functional tests, you would have to go into the file and change it.
Another way is to take the suite files in conf/testng and pre-process them before use, based on the parallel= and thread-count= attributes passed to runtest. This can be acheived by using a small XSLT transform which runs in a step just before the testNG task is invoked and configures the suite file on the fly.
When the runtest macro gets called, it takes the parallel= and thread-count= parameters passed to runtest and uses an XSLT transform called configParallel.xsl to change the corresponding attributes in the suite file. The transformed suite file is then stored in the temp.dir where the test results are also stored in named directories. This modified suite file is then used to control the test and will be cleaned up when the clean ant task is run.
Here is the xslt file, in conf/testng/parallelConfig.xsl:
{noformat}
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes" indent="yes"/>
<xsl:param name="parallel" select="'methods'"/>
<xsl:param name="thread-count" select="'1'"/>
<!-- copy everything -->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<!-- change value of parallel attribute -->
<xsl:template match="@parallel[parent::suite]">
<xsl:attribute name="parallel">
<xsl:value-of select="$parallel"/>
</xsl:attribute>
</xsl:template>
<!-- change value of thread-count attribute -->
<xsl:template match="@thread-count[parent::suite]">
<xsl:attribute name="thread-count">
<xsl:value-of select="$thread-count"/>
</xsl:attribute>
</xsl:template>
</xsl:stylesheet>
{noformat}
and here is the invocation of the xslt task from within runtest:
{noformat}
<!-- use XSLT to add parallelism directives to the suite definition files -->
<xslt in="${testng.conf.dir}/(a){testng.xmlfile}" out="${tmp.dir}/(a){testng.xmlfile}"
extension=".xml" style="${testng.conf.dir}/parallelConfig.xsl">
<param name="parallel" expression="@{parallel}"/>
<param name="thread-count" expression="@{threadcount}"/>
</xslt>
{noformat}
I've set up a PR and have this mechanism working. No extra jars or other mechanisms are required.
was (Author: rachmato):
So, because JGroups uses suite files to control the testsuite, there is no easy way to turn parallelism on and off.
There was a mechanism in place which used the system properties listed in the first comment and passed those through to the runtest macro, but these had no effect on the suite definition files. We must somehow modify these files for parallel and non-parallel test execution modes.
One way would be to have a set of suite files for non-parallel mode, and another set of suite files for parallel mode. We could then use the parallel.tests and parallel.methods build properties to control which suite definition file (parallel or non-parallel) was picked up for test execution. But if you wanted to change say the thread-count of the functional tests, you would have to go into the file and change it.
Another way is to take the suite files in conf/testng and pre-process them before use, based on the parallel= and thread-count= attributes passed to runtest. This can be acheived by using a small XSLT transform which runs in a step just before the testNG task is invoked and configures the suite file on the fly.
When the runtest macro gets called, it takes the parallel= and thread-count= parameters passed to runtest and uses an XSLT transform called configParallel.xsl to change the corresponding attributes in the suite file. The transformed suite file is then stored in the temp.dir where the test results are also stored in named directories. This modified suite file is then used to control the test and will be cleaned up when the clean ant task is run.
Here is the xslt file, in conf/testng/parallelConfig.xsl:
{noformat}
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes" indent="yes"/>
<xsl:param name="parallel" select="'methods'"/>
<xsl:param name="thread-count" select="'1'"/>
<!-- copy everything -->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<!-- change value of parallel attribute -->
<xsl:template match="@parallel[parent::suite]">
<xsl:attribute name="parallel">
<xsl:value-of select="$parallel"/>
</xsl:attribute>
</xsl:template>
<!-- change value of thread-count attribute -->
<xsl:template match="@thread-count[parent::suite]">
<xsl:attribute name="thread-count">
<xsl:value-of select="$thread-count"/>
</xsl:attribute>
</xsl:template>
</xsl:stylesheet>
{noformat}
and here is the invocation of the xslt task:
{noformat}
<!-- use XSLT to add parallelism directives to the suite definition files -->
<xslt in="${testng.conf.dir}/(a){testng.xmlfile}" out="${tmp.dir}/(a){testng.xmlfile}"
extension=".xml" style="${testng.conf.dir}/parallelConfig.xsl">
<param name="parallel" expression="@{parallel}"/>
<param name="thread-count" expression="@{threadcount}"/>
</xslt>
{noformat}
I've set up a PR and have this mechanism working. No extra jars or other mechanisms are required.
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
> Key: JGRP-1728
> URL: https://issues.jboss.org/browse/JGRP-1728
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1728:
-------------------------------------------
If you aren't happy with the XSLT transform, the only other approach I can think of (until C. Beust provides property substitution in this suite definition files) is to have two sets of suite definition files in conf/testng:
{noformat}
testng-udp.xml
...
testng-udp-sequential.xml
...
{noformat}
and use some form of switch in the build.xml file to pick the desirted mode. But this loses the ability to configure the suite file's thread-count value, among other things.
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
> Key: JGRP-1728
> URL: https://issues.jboss.org/browse/JGRP-1728
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1728 at 11/6/13 1:09 PM:
--------------------------------------------------------------------
So, because JGroups uses suite files to control the testsuite, there is no easy way to turn parallelism on and off.
There was a mechanism in place which used the system properties listed in the first comment and passed those through to the runtest macro, but these had no effect on the suite definition files. We must somehow modify these files for parallel and non-parallel test execution modes.
One way would be to have a set of suite files for non-parallel mode, and another set of suite files for parallel mode. We could then use the parallel.tests and parallel.methods build properties to control which suite definition file (parallel or non-parallel) was picked up for test execution. But if you wanted to change say the thread-count of the functional tests, you would have to go into the file and change it.
Another way is to take the suite files in conf/testng and pre-process them before use, based on the parallel= and thread-count= attributes passed to runtest. This can be acheived by using a small XSLT transform which runs in a step just before the testNG task is invoked and configures the suite file on the fly.
When the runtest macro gets called, it takes the parallel= and thread-count= parameters passed to runtest and uses an XSLT transform called configParallel.xsl to change the corresponding attributes in the suite file. The transformed suite file is then stored in the temp.dir where the test results are also stored in named directories. This modified suite file is then used to control the test and will be cleaned up when the clean ant task is run.
Here is the xslt file, in conf/testng/parallelConfig.xsl:
{noformat}
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes" indent="yes"/>
<xsl:param name="parallel" select="'methods'"/>
<xsl:param name="thread-count" select="'1'"/>
<!-- copy everything -->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<!-- change value of parallel attribute -->
<xsl:template match="@parallel[parent::suite]">
<xsl:attribute name="parallel">
<xsl:value-of select="$parallel"/>
</xsl:attribute>
</xsl:template>
<!-- change value of thread-count attribute -->
<xsl:template match="@thread-count[parent::suite]">
<xsl:attribute name="thread-count">
<xsl:value-of select="$thread-count"/>
</xsl:attribute>
</xsl:template>
</xsl:stylesheet>
{noformat}
and here is the invocation of the xslt task:
{noformat}
<!-- use XSLT to add parallelism directives to the suite definition files -->
<xslt in="${testng.conf.dir}/(a){testng.xmlfile}" out="${tmp.dir}/(a){testng.xmlfile}"
extension=".xml" style="${testng.conf.dir}/parallelConfig.xsl">
<param name="parallel" expression="@{parallel}"/>
<param name="thread-count" expression="@{threadcount}"/>
</xslt>
{noformat}
I've set up a PR and have this mechanism working. No extra jars or other mechanisms are required.
was (Author: rachmato):
So, because JGroups uses suite files to control the testsuite, there is no easy way to turn parallelism on and off.
There was a mechanism in place which used the system properties listed in the first comment and passed those through to the runtest macro, but these had no effect on the suite definition files. We must somehow modify these files for parallel and non-parallel test execution modes.
One way would be to have a set of suite files for non-parallel mode, and another set of suite files for parallel mode. We could then use the parallel.tests and parallel.methods build properties to control which suite definition file (parallel or non-parallel) was picked up for test execution. But if you wanted to change say the thread-count of the functional tests, you would have to go into the file and change it.
Another way is to take the suite files in conf/testng and pre-process them before use, based on the parallel= and thread-count= attributes passed to runtest. This can be acheived by using a small XSLT transform which runs in a step just before the testNG task is invoked and configures the suite file on the fly.
When the runtest macro gets called, it takes the parallel= and thread-count= parameters passed to runtest and uses an XSLT transform called configParallel.xsl to change the corresponding attributes in the suite file. The transformed suite file is then stored in the temp.dir where the test results are also stored in named directories. This modified suite file is then used to control the test and will be cleaned up when the clean ant task is run.
Here is the xslt file, in conf/testng/parallelConfig.xsl:
{noformat}
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes" indent="yes"/>
<xsl:param name="parallel" select="'methods'"/>
<xsl:param name="thread-count" select="'1'"/>
<!-- copy everything -->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<!-- change value of parallel attribute -->
<xsl:template match="@parallel[parent::suite]">
<xsl:attribute name="parallel">
<xsl:value-of select="$parallel"/>
</xsl:attribute>
</xsl:template>
<!-- change value of thread-count attribute -->
<xsl:template match="@thread-count[parent::suite]">
<xsl:attribute name="thread-count">
<xsl:value-of select="$thread-count"/>
</xsl:attribute>
</xsl:template>
</xsl:stylesheet>
{noformat}
and here is the invocation of the xslt task:
{noformat}
<!-- use XSLT to add parallelism directives to the suite definition files -->
<xslt in="${testng.conf.dir}/(a){testng.xmlfile}" out="${tmp.dir}/(a){testng.xmlfile}"
extension=".xml" style="${testng.conf.dir}/parallelConfig.xsl">
<param name="parallel" expression="@{parallel}"/>
<param name="thread-count" expression="@{threadcount}"/>
</xslt>
{noformat}
I've set up a PR and have this mechanism working.
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
> Key: JGRP-1728
> URL: https://issues.jboss.org/browse/JGRP-1728
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1728 at 11/6/13 1:08 PM:
--------------------------------------------------------------------
So, because JGroups uses suite files to control the testsuite, there is no easy way to turn parallelism on and off.
There was a mechanism in place which used the system properties listed in the first comment and passed those through to the runtest macro, but these had no effect on the suite definition files. We must somehow modify these files for parallel and non-parallel test execution modes.
One way would be to have a set of suite files for non-parallel mode, and another set of suite files for parallel mode. We could then use the parallel.tests and parallel.methods build properties to control which suite definition file (parallel or non-parallel) was picked up for test execution. But if you wanted to change say the thread-count of the functional tests, you would have to go into the file and change it.
Another way is to take the suite files in conf/testng and pre-process them before use, based on the parallel= and thread-count= attributes passed to runtest. This can be acheived by using a small XSLT transform which runs in a step just before the testNG task is invoked and configures the suite file on the fly.
When the runtest macro gets called, it takes the parallel= and thread-count= parameters passed to runtest and uses an XSLT transform called configParallel.xsl to change the corresponding attributes in the suite file. The transformed suite file is then stored in the temp.dir where the test results are also stored in named directories. This modified suite file is then used to control the test and will be cleaned up when the clean ant task is run.
Here is the xslt file, in conf/testng/parallelConfig.xsl:
{noformat}
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes" indent="yes"/>
<xsl:param name="parallel" select="'methods'"/>
<xsl:param name="thread-count" select="'1'"/>
<!-- copy everything -->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<!-- change value of parallel attribute -->
<xsl:template match="@parallel[parent::suite]">
<xsl:attribute name="parallel">
<xsl:value-of select="$parallel"/>
</xsl:attribute>
</xsl:template>
<!-- change value of thread-count attribute -->
<xsl:template match="@thread-count[parent::suite]">
<xsl:attribute name="thread-count">
<xsl:value-of select="$thread-count"/>
</xsl:attribute>
</xsl:template>
</xsl:stylesheet>
{noformat}
and here is the invocation of the xslt task:
{noformat}
<!-- use XSLT to add parallelism directives to the suite definition files -->
<xslt in="${testng.conf.dir}/(a){testng.xmlfile}" out="${tmp.dir}/(a){testng.xmlfile}"
extension=".xml" style="${testng.conf.dir}/parallelConfig.xsl">
<param name="parallel" expression="@{parallel}"/>
<param name="thread-count" expression="@{threadcount}"/>
</xslt>
{noformat}
I've set up a PR and have this mechanism working.
was (Author: rachmato):
So, because JGroups uses suite files to control the testsuite, there is no easy way to turn parallelism on and off.
There was a mechanism in place which used the system properties listed in the first comment and passed those through to the runtest macro, but these had no effect on the suite definition files. We must somehow modify these files for parallel and non-parallel test execution modes.
One way would be to have a set of suite files for non-parallel mode, and another set of suite files for parallel mode. We could then use the parallel.tests and parallel.methods build properties to control which suite definition file (parallel or non-parallel) was picked up for test execution. But if you wanted to change say the thread-count of the functional tests, you would have to go into the file and change it.
Another way is to take the suite files in conf/testng and pre-process them before use, based on the parallel= and thread-count= attributes passed to runtest. This can be acheived by using a small XSLT transform which runs in a step just before the testNG task is invoked and configures the suite file on the fly.
When the runtest macro gets called, it takes the parallel= and thread-count= parameters passed to runtest and uses an XSLT transform called configParallel.xsl to change the corresponding attributes in the suite file. The transformed suite file is then stored in the temp.dir where the test results are also stored in named directories. This modified suite file is then used to control the test and will be cleaned up when the clean ant task is run.
Here is the xslt file, in conf/testng/parallelConfig.xsl:
{noformat}
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes" indent="yes"/>
<xsl:param name="parallel" select="'methods'"/>
<xsl:param name="thread-count" select="'1'"/>
<!-- copy everything -->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<!-- change value of parallel attribute -->
<xsl:template match="@parallel[parent::suite]">
<xsl:attribute name="parallel">
<xsl:value-of select="$parallel"/>
</xsl:attribute>
</xsl:template>
<!-- change value of thread-count attribute -->
<xsl:template match="@thread-count[parent::suite]">
<xsl:attribute name="thread-count">
<xsl:value-of select="$thread-count"/>
</xsl:attribute>
</xsl:template>
</xsl:stylesheet>
{noformat}
and here is the invocation of the xslt task:
{noformat}
<!-- use XSLT to add parallelism directives to the suite definition files -->
<xslt in="${testng.conf.dir}/(a){testng.xmlfile}" out="${tmp.dir}/(a){testng.xmlfile}"
extension=".xml" style="${testng.conf.dir}/parallelConfig.xsl">
<param name="parallel" expression="@{parallel}"/>
<param name="thread-count" expression="@{threadcount}"/>
</xslt>
{noformat}
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
> Key: JGRP-1728
> URL: https://issues.jboss.org/browse/JGRP-1728
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1728:
-------------------------------------------
So, because JGroups uses suite files to control the testsuite, there is no easy way to turn parallelism on and off.
There was a mechanism in place which used the system properties listed in the first comment and passed those through to the runtest macro, but these had no effect on the suite definition files. We must somehow modify these files for parallel and non-parallel test execution modes.
One way would be to have a set of suite files for non-parallel mode, and another set of suite files for parallel mode. We could then use the parallel.tests and parallel.methods build properties to control which suite definition file (parallel or non-parallel) was picked up for test execution. But if you wanted to change say the thread-count of the functional tests, you would have to go into the file and change it.
Another way is to take the suite files in conf/testng and pre-process them before use, based on the parallel= and thread-count= attributes passed to runtest. This can be acheived by using a small XSLT transform which runs in a step just before the testNG task is invoked and configures the suite file on the fly.
When the runtest macro gets called, it takes the parallel= and thread-count= parameters passed to runtest and uses an XSLT transform called configParallel.xsl to change the corresponding attributes in the suite file. The transformed suite file is then stored in the temp.dir where the test results are also stored in named directories. This modified suite file is then used to control the test and will be cleaned up when the clean ant task is run.
Here is the xslt file, in conf/testng/parallelConfig.xsl:
{noformat}
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes" indent="yes"/>
<xsl:param name="parallel" select="'methods'"/>
<xsl:param name="thread-count" select="'1'"/>
<!-- copy everything -->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<!-- change value of parallel attribute -->
<xsl:template match="@parallel[parent::suite]">
<xsl:attribute name="parallel">
<xsl:value-of select="$parallel"/>
</xsl:attribute>
</xsl:template>
<!-- change value of thread-count attribute -->
<xsl:template match="@thread-count[parent::suite]">
<xsl:attribute name="thread-count">
<xsl:value-of select="$thread-count"/>
</xsl:attribute>
</xsl:template>
</xsl:stylesheet>
{noformat}
and here is the invocation of the xslt task:
{noformat}
<!-- use XSLT to add parallelism directives to the suite definition files -->
<xslt in="${testng.conf.dir}/(a){testng.xmlfile}" out="${tmp.dir}/(a){testng.xmlfile}"
extension=".xml" style="${testng.conf.dir}/parallelConfig.xsl">
<param name="parallel" expression="@{parallel}"/>
<param name="thread-count" expression="@{threadcount}"/>
</xslt>
{noformat}
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
> Key: JGRP-1728
> URL: https://issues.jboss.org/browse/JGRP-1728
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1728 at 11/6/13 12:56 PM:
---------------------------------------------------------------------
The first implementation of this change was incorrect. The problem lies with the way in which paralleism is configured in testNG, which I summarise here:
- you can specify attributes parallel= and thread-count= on the <testng/> ant task in order to control parallelism of test classes specified within the testng task itself ;
- you can specify attributes parallel= and thread-count= on the <suite/> elements of the XML suite definition files to control parallelism of tests defined in the suite
- the parallelism directives of the testng ant task, and the paralleism directives of the suite elements are completely independent
What this means is that if you define your tests via suite definition files (as te JGroups testsuite does), then in order to control parallelism of test execution, you have to modify the parallelism directives in the suite files themselves
This situation is made worse by the fact that you cannot use variable substitution in the testNGs suite files (i.e. no chance for defining a system property and then referencing that system property in the suite file, as in
{noformat}
<suite parallel="${parallel.methods}"/>)
{noformat}
So in order to configure parallelism, on the fly, we need to be able to modify or otherwise configure the suite files which are passed to the test cases.
was (Author: rachmato):
The first implementation of this change was incorrect. The problem lies with the way in which paralleism is configured in testNG, which I summarise here:
- you can specify attributes parallel= and thread-count= on the <testng/> ant task in order to control parallelism of test classes specified within the testng task itself ;
- you can specify attributes parallel= and thread-count= on the <suite/> elements of the XML suite definition files to control parallelism of tests defined in the suite
- the parallelism directives of the testng ant task, and the paralleism directives of the suite elements are completely independent
What this means is that if you define your tests via suite definition files (as te JGroups testsuite does), then in order to control parallelism of test execution, you have to modify the parallelism directives in the suite files themselves
This situation is made worse by the fact that you cannot use variable substitution in the testNGs suite files (i.e. no chance for defining a system property and then referencing that system property in the suite file, as in <suite parallel="${parallel.methods}"/>)
So in order to configure parallelism, on the fly, we need to be able to modify or otherwise configure the suite files which are passed to the test cases.
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
> Key: JGRP-1728
> URL: https://issues.jboss.org/browse/JGRP-1728
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1728:
-------------------------------------------
The first implementation of this change was incorrect. The problem lies with the way in which paralleism is configured in testNG, which I summarise here:
- you can specify attributes parallel= and thread-count= on the <testng/> ant task in order to control parallelism of test classes specified within the testng task itself ;
- you can specify attributes parallel= and thread-count= on the <suite/> elements of the XML suite definition files to control parallelism of tests defined in the suite
- the parallelism directives of the testng ant task, and the paralleism directives of the suite elements are completely independent
What this means is that if you define your tests via suite definition files (as te JGroups testsuite does), then in order to control parallelism of test execution, you have to modify the parallelism directives in the suite files themselves
This situation is made worse by the fact that you cannot use variable substitution in the testNGs suite files (i.e. no chance for defining a system property and then referencing that system property in the suite file, as in <suite parallel="${parallel.methods}"/>)
So in order to configure parallelism, on the fly, we need to be able to modify or otherwise configure the suite files which are passed to the test cases.
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
> Key: JGRP-1728
> URL: https://issues.jboss.org/browse/JGRP-1728
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1731) Make parallelism of JGroups testsuite configurable from command line
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1731?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz closed JGRP-1731.
-------------------------------------
Resolution: Duplicate Issue
> Make parallelism of JGroups testsuite configurable from command line
> --------------------------------------------------------------------
>
> Key: JGRP-1731
> URL: https://issues.jboss.org/browse/JGRP-1731
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
>
> The JGroups testsuite uses testNG, which can be configured to execute tests in parallel or in sequence. The JGroups testsuite currently executes tests in parallel by default.
> When running the JGroups testsuite in the QA lab, we see this:
> - when parallelism is enabled, we see a large number testsuite failures which vary from run to run
> - when parallelism is disabled, we see a small number of testsuite failures, which are much more consistent across runs
> We need to run the JGroups testsuite in sequential mode when running in the QA lab, to get a truer picture of actual failures.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1731) Make parallelism of JGroups testsuite configurable from command line
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created JGRP-1731:
-----------------------------------------
Summary: Make parallelism of JGroups testsuite configurable from command line
Key: JGRP-1731
URL: https://issues.jboss.org/browse/JGRP-1731
Project: JGroups
Issue Type: Feature Request
Reporter: Richard Achmatowicz
Assignee: Bela Ban
Priority: Minor
The JGroups testsuite uses testNG, which can be configured to execute tests in parallel or in sequence. The JGroups testsuite currently executes tests in parallel by default.
When running the JGroups testsuite in the QA lab, we see this:
- when parallelism is enabled, we see a large number testsuite failures which vary from run to run
- when parallelism is disabled, we see a small number of testsuite failures, which are much more consistent across runs
We need to run the JGroups testsuite in sequential mode when running in the QA lab, to get a truer picture of actual failures.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (DROOLS-323) Incremental Builds Result in ClassCastExceptions
by David Templin (JIRA)
[ https://issues.jboss.org/browse/DROOLS-323?page=com.atlassian.jira.plugin... ]
David Templin updated DROOLS-323:
---------------------------------
Description:
Incremental builds via the {{KnowledgeAgent}} occasionally result in a {{ClassCastException}}, such as the following:
{noformat}
java.lang.ClassCastException: org.drools.reteoo.AlphaNode$AlphaMemory cannot be cast to org.drools.reteoo.BetaMemory
at org.drools.reteoo.JoinNode.updateSink(JoinNode.java:398)
at org.drools.reteoo.RuleTerminalNode.attach(RuleTerminalNode.java:346)
at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:174)
at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:134)
at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:113)
at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445)
at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:952)
at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:629)
at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:149)
at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:1117)
at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:1003)
at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:686)
at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:207)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run_aroundBody0(KnowledgeAgentImpl.java:1301)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector$AjcClosure1.run(KnowledgeAgentImpl.java:1)
at com.foo.DroolsBugAspect.ajc$around$com_foo_DroolsBugAspect$1$b7e32854proceed(DroolsBugAspect.aj:8)
at com.foo.DroolsBugAspect.ajc$around$com_foo_DroolsBugAspect$1$b7e32854(DroolsBugAspect.aj:10)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1295)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:695)
{noformat}
Steps to reproduce:
# Download the attached zip file ({{drools-bug.tar.gz}})
# Extract the contents into a directory
# {{cd <directory>}}
# {{mvn install}}
# Type {{sh target/classes/run.sh}}, or else type {{java -classpath target/classes:target/lib/* -javaagent:target/lib/aspectjweaver-1.7.3.jar com.foo.Main}}
# Wait for a sequence of log messages similar to the following messages to begin to print to the console:
{noformat}
[2013-11-06 11:05:33,742:debug] ResourceChangeScanner attempt to scan 1 resources
[2013-11-06 11:05:33,743:debug] ResourceChangeScanner thread is waiting for 2 seconds.
{noformat}
# Edit {{target/classes/recommendations.drl}} in some trivial manner; for instance, I have found that editing the RHS of rule "Initialize Recommendations" by adding a print statement ({{e.g. System.out.println("test");}}) and editing the print statement a few times will reliably reproduce the problem; occasionally, merely touching the file will cause the problem to manifest.
# Wait for the exception to print to the console; it will look like the exception above
Note that the exception is suppressed by the executor architecture in Drools. Thus, I had to weave an aspect that catches the exception and prints it.
This bug also results in a memory leak, since the {{ResourceChangeNotifier}} continues to produce {{ChangeSet}} objects, but there are no consumers after the {{ChangeSetNotificationDetector}} thread terminates, resulting in an unbounded queue.
I also noticed the following exception in development, yet was unable to reproduce it in the attached demonstration project:
{noformat}
java.lang.ClassCastException: com.foo.AidAgreement cannot be cast to com.foo.Unit
at org.drools.base.com.foo.Unit1155259690$getAgency.getValue(Unknown Source)
at org.drools.base.extractors.BaseObjectClassFieldReader.getHashCode(BaseObjectClassFieldReader.java:204)
at org.drools.base.ClassFieldReader.getHashCode(ClassFieldReader.java:193)
at org.drools.core.util.AbstractHashTable$SingleIndex.hashCodeOf(AbstractHashTable.java:521)
at org.drools.core.util.index.RightTupleIndexHashTable.getOrCreate(RightTupleIndexHashTable.java:438)
at org.drools.core.util.index.RightTupleIndexHashTable.add(RightTupleIndexHashTable.java:319)
at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:136)
at org.drools.reteoo.ObjectTypeNode.updateSink(ObjectTypeNode.java:334)
at org.drools.reteoo.BetaNode.attach(BetaNode.java:408)
at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:145)
at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:142)
at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:134)
at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:113)
at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445)
at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:952)
at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:629)
at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:149)
at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:1117)
at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:1003)
at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:686)
at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:207)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run_aroundBody0(KnowledgeAgentImpl.java:1301)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector$AjcClosure1.run(KnowledgeAgentImpl.java:1)
at com.foo.DroolsBugAspect.ajc$around$com.foo_DroolsBugAspect$1$b7e32854proceed(DroolsBugAspect.aj:8)
at com.foo.DroolsBugAspect.ajc$around$com.foo_DroolsBugAspect$1$b7e32854(DroolsBugAspect.aj:10)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1295)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:695)
{noformat}
The demonstration code is, of course, only intended to demonstrate the problem. It is a highly simplified and slightly sanitized version of actual code that is in development.
was:
Incremental builds via the {{KnowledgeAgent}} occasionally result in a {{ClassCastException}}, such as the following:
{noformat}
java.lang.ClassCastException: org.drools.reteoo.AlphaNode$AlphaMemory cannot be cast to org.drools.reteoo.BetaMemory
at org.drools.reteoo.JoinNode.updateSink(JoinNode.java:398)
at org.drools.reteoo.RuleTerminalNode.attach(RuleTerminalNode.java:346)
at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:174)
at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:134)
at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:113)
at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445)
at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:952)
at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:629)
at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:149)
at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:1117)
at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:1003)
at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:686)
at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:207)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run_aroundBody0(KnowledgeAgentImpl.java:1301)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector$AjcClosure1.run(KnowledgeAgentImpl.java:1)
at com.foo.DroolsBugAspect.ajc$around$com_foo_DroolsBugAspect$1$b7e32854proceed(DroolsBugAspect.aj:8)
at com.foo.DroolsBugAspect.ajc$around$com_foo_DroolsBugAspect$1$b7e32854(DroolsBugAspect.aj:10)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1295)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:695)
{noformat}
Steps to reproduce:
# Download the attached zip file ({{drools-bug.tar.gz}})
# Extract the contents into a directory
# {{cd <directory>}}
# {{mvn install}}
# Type {{sh target/classes/run.sh}}, or else type {{java -classpath target/classes:target/lib/* -javaagent:target/lib/aspectjweaver-1.7.3.jar com.foo.Main}}
# Wait for a sequence of log messages similar to the following messages to begin to print to the console:
{noformat}
[2013-11-06 11:05:33,742:debug] ResourceChangeScanner attempt to scan 1 resources
[2013-11-06 11:05:33,743:debug] ResourceChangeScanner thread is waiting for 2 seconds.
{noformat}
# Edit {{target/classes/recommendations.drl}} in some trivial manner; for instance, I have found that editing the RHS of rule "Initialize Recommendations" by adding a print statement ({{e.g. System.out.println("test");}}) and editing the print statement a few times will reliably reproduce the problem; occasionally, merely touching the file will cause the problem to manifest.
# Wait for the exception to print to the console; it will look like the exception above
Note that the exception is suppressed by the executor architecture in Drools. Thus, I had to weave an aspect that catches the exception and prints it.
This bug also results in a memory leak, since the {{ResourceChangeNotifier}} continues to produce {{ChangeSet}} objects, but there are no consumers after the {{ChangeSetNotificationDetector}} thread terminates, resulting in an unbounded queue.
> Incremental Builds Result in ClassCastExceptions
> ------------------------------------------------
>
> Key: DROOLS-323
> URL: https://issues.jboss.org/browse/DROOLS-323
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: David Templin
> Assignee: Mark Proctor
> Attachments: drools-bug.tar.gz
>
>
> Incremental builds via the {{KnowledgeAgent}} occasionally result in a {{ClassCastException}}, such as the following:
> {noformat}
> java.lang.ClassCastException: org.drools.reteoo.AlphaNode$AlphaMemory cannot be cast to org.drools.reteoo.BetaMemory
> at org.drools.reteoo.JoinNode.updateSink(JoinNode.java:398)
> at org.drools.reteoo.RuleTerminalNode.attach(RuleTerminalNode.java:346)
> at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:174)
> at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:134)
> at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:113)
> at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445)
> at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:952)
> at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:629)
> at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
> at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:149)
> at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:1117)
> at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:1003)
> at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:686)
> at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:207)
> at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run_aroundBody0(KnowledgeAgentImpl.java:1301)
> at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector$AjcClosure1.run(KnowledgeAgentImpl.java:1)
> at com.foo.DroolsBugAspect.ajc$around$com_foo_DroolsBugAspect$1$b7e32854proceed(DroolsBugAspect.aj:8)
> at com.foo.DroolsBugAspect.ajc$around$com_foo_DroolsBugAspect$1$b7e32854(DroolsBugAspect.aj:10)
> at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1295)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:695)
> {noformat}
> Steps to reproduce:
> # Download the attached zip file ({{drools-bug.tar.gz}})
> # Extract the contents into a directory
> # {{cd <directory>}}
> # {{mvn install}}
> # Type {{sh target/classes/run.sh}}, or else type {{java -classpath target/classes:target/lib/* -javaagent:target/lib/aspectjweaver-1.7.3.jar com.foo.Main}}
> # Wait for a sequence of log messages similar to the following messages to begin to print to the console:
> {noformat}
> [2013-11-06 11:05:33,742:debug] ResourceChangeScanner attempt to scan 1 resources
> [2013-11-06 11:05:33,743:debug] ResourceChangeScanner thread is waiting for 2 seconds.
> {noformat}
> # Edit {{target/classes/recommendations.drl}} in some trivial manner; for instance, I have found that editing the RHS of rule "Initialize Recommendations" by adding a print statement ({{e.g. System.out.println("test");}}) and editing the print statement a few times will reliably reproduce the problem; occasionally, merely touching the file will cause the problem to manifest.
> # Wait for the exception to print to the console; it will look like the exception above
> Note that the exception is suppressed by the executor architecture in Drools. Thus, I had to weave an aspect that catches the exception and prints it.
> This bug also results in a memory leak, since the {{ResourceChangeNotifier}} continues to produce {{ChangeSet}} objects, but there are no consumers after the {{ChangeSetNotificationDetector}} thread terminates, resulting in an unbounded queue.
> I also noticed the following exception in development, yet was unable to reproduce it in the attached demonstration project:
> {noformat}
> java.lang.ClassCastException: com.foo.AidAgreement cannot be cast to com.foo.Unit
> at org.drools.base.com.foo.Unit1155259690$getAgency.getValue(Unknown Source)
> at org.drools.base.extractors.BaseObjectClassFieldReader.getHashCode(BaseObjectClassFieldReader.java:204)
> at org.drools.base.ClassFieldReader.getHashCode(ClassFieldReader.java:193)
> at org.drools.core.util.AbstractHashTable$SingleIndex.hashCodeOf(AbstractHashTable.java:521)
> at org.drools.core.util.index.RightTupleIndexHashTable.getOrCreate(RightTupleIndexHashTable.java:438)
> at org.drools.core.util.index.RightTupleIndexHashTable.add(RightTupleIndexHashTable.java:319)
> at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:136)
> at org.drools.reteoo.ObjectTypeNode.updateSink(ObjectTypeNode.java:334)
> at org.drools.reteoo.BetaNode.attach(BetaNode.java:408)
> at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:145)
> at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:142)
> at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
> at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
> at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:134)
> at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:113)
> at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445)
> at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:952)
> at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:629)
> at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
> at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:149)
> at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:1117)
> at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:1003)
> at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:686)
> at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:207)
> at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run_aroundBody0(KnowledgeAgentImpl.java:1301)
> at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector$AjcClosure1.run(KnowledgeAgentImpl.java:1)
> at com.foo.DroolsBugAspect.ajc$around$com.foo_DroolsBugAspect$1$b7e32854proceed(DroolsBugAspect.aj:8)
> at com.foo.DroolsBugAspect.ajc$around$com.foo_DroolsBugAspect$1$b7e32854(DroolsBugAspect.aj:10)
> at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1295)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:695)
> {noformat}
> The demonstration code is, of course, only intended to demonstrate the problem. It is a highly simplified and slightly sanitized version of actual code that is in development.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months