Using thread pools in a Spock Spy'd class hangs during unit tests

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Using thread pools in a Spock Spy'd class hangs during unit tests

Kevin Dorff
Hi,

I tried to search Google (and here) for others reporting this or a similar problem but had no obvious success.

I am attempting to write Spock unit tests for a class which contains a method that use a thread pool to do work. I have tried GPars withPool and Java's Executor fixed-size pool. It seems that if I Spy the class when that class tries to do work with a thread pool, the unit test hangs.

I have created a simple example and set of simple Spock test cases which demonstrate what I am seeing. In my repo, the failing test cases are marked as @Ignore because they will, for me, reliably hang the test suite.


All use
  • Using Groovy 2.4.7
  • Java (1.7.0_80 or 1.8.0_92)

The CalcSpec class uses:
  • Spock-core 1.1-groovy-2.4-rc-3.
  • CGLib 3.2.4
Any opinions, suggestions, or thoughts are welcome. I initially asked this of the GPars people, but they suggested that the issue must be with the Spied class somehow not being compatible with the thread pool. This sparked me to add a method (and tests) that uses the Java Executor's pools. But these appear to exhibit the same issue.

Thanks,
Kevin

--
You received this message because you are subscribed to the Google Groups "Spock Framework - User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using thread pools in a Spock Spy'd class hangs during unit tests

kriegaex

Hi Kevin.

Your first two ignored tests do not need a Spy, they run fine with a normal Calc object.

As for the other two tests, I do not understand what you are trying to test. And why do you need a Spy anyway (Spy is usually bad and a sign that you should refactor your code)? To me those two tests do not really make sense. If I knew why you think you absolutely need a Spy there, maybe I would think about what goes wrong there. To me it just looks like you want to see what you can do with a Spy anyway instead of a test which makes any logical sense.

Regards
--
Alexander Kriegisch
https://scrum-master.de

 
Kevin Dorff schrieb am 03.02.2017 20:21:
Hi,
 
I tried to search Google (and here) for others reporting this or a similar problem but had no obvious success.
 
I am attempting to write Spock unit tests for a class which contains a method that use a thread pool to do work. I have tried GPars withPool and Java's Executor fixed-size pool. It seems that if I Spy the class when that class tries to do work with a thread pool, the unit test hangs.
 
I have created a simple example and set of simple Spock test cases which demonstrate what I am seeing. In my repo, the failing test cases are marked as @Ignore because they will, for me, reliably hang the test suite.
 
 
All use
  • Using Groovy 2.4.7
  • Java (1.7.0_80 or 1.8.0_92)
 
The CalcSpec class uses:
  • Spock-core 1.1-groovy-2.4-rc-3.
  • CGLib 3.2.4
Any opinions, suggestions, or thoughts are welcome. I initially asked this of the GPars people, but they suggested that the issue must be with the Spied class somehow not being compatible with the thread pool. This sparked me to add a method (and tests) that uses the Java Executor's pools. But these appear to exhibit the same issue.
 
Thanks,
Kevin
--
You received this message because you are subscribed to the Google Groups "Spock Framework - User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Spock Framework - User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using thread pools in a Spock Spy'd class hangs during unit tests

Spock Framework mailing list
In reply to this post by Kevin Dorff

Hi Kevin.


Your first two ignored tests do not need a Spy, they run fine with a normal Calc object.


As for the other two tests, I do not understand what you are trying to test. And why do you need a Spy anyway (Spy is usually bad and a sign that you should refactor your code)? To me those two tests do not really make sense. If I knew why you think you absolutely need a Spy there, maybe I would think about what goes wrong there. To me it just looks like you want to see what you can do with a Spy anyway instead of a test which makes any logical sense.

Regards
--
Alexander Kriegisch
https://scrum-master.de



Am Freitag, 3. Februar 2017 20:22:47 UTC+1 schrieb Kevin Dorff:
Hi,

I tried to search Google (and here) for others reporting this or a similar problem but had no obvious success.

I am attempting to write Spock unit tests for a class which contains a method that use a thread pool to do work. I have tried GPars withPool and Java's Executor fixed-size pool. It seems that if I Spy the class when that class tries to do work with a thread pool, the unit test hangs.

I have created a simple example and set of simple Spock test cases which demonstrate what I am seeing. In my repo, the failing test cases are marked as @Ignore because they will, for me, reliably hang the test suite.

<a href="https://github.com/kdorff/SpiesAndGpars" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fkdorff%2FSpiesAndGpars\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXEGH7335_CQtTRQnwchddI3UFYw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fkdorff%2FSpiesAndGpars\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXEGH7335_CQtTRQnwchddI3UFYw&#39;;return true;">https://github.com/kdorff/SpiesAndGpars

All use
  • Using Groovy 2.4.7
  • Java (1.7.0_80 or 1.8.0_92)

The CalcSpec class uses:
  • Spock-core 1.1-groovy-2.4-rc-3.
  • CGLib 3.2.4
Any opinions, suggestions, or thoughts are welcome. I initially asked this of the GPars people, but they suggested that the issue must be with the Spied class somehow not being compatible with the thread pool. This sparked me to add a method (and tests) that uses the Java Executor's pools. But these appear to exhibit the same issue.

Thanks,
Kevin

--
You received this message because you are subscribed to the Google Groups "Spock Framework - User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using thread pools in a Spock Spy'd class hangs during unit tests

Kevin Dorff
In reply to this post by Kevin Dorff
Hi,

What I have presented is a (hopefully) easy bit of code to understand which demonstrates the problem. This is not the actual production code, which is property of my company and if I posted that I'd have to answer SO MANY more questions. This simple code should be consumable by anyone and clearly demonstrates the issue I am having. Yes, perhaps i can refactor my code such that I don't have to use Spy or can spy a class that doesn't contain a thread pool which might fix it. That said...

The purpose for my first failing test is to demonstrates that (two kinds of) thread pools hang because of something about the Spy (not the Spy plus any method mocking). The tests all exist to exercise the Calc.groovy code in some way. The failing tests do the same things as the non-failing tests do, but use one of two different thread pools. In both cases, using the thread pool within a Spied object hangs the execution. Which is why I am asking.

Kevin


On Friday, February 3, 2017 at 1:22:47 PM UTC-6, Kevin Dorff wrote:
Hi,

I tried to search Google (and here) for others reporting this or a similar problem but had no obvious success.

I am attempting to write Spock unit tests for a class which contains a method that use a thread pool to do work. I have tried GPars withPool and Java's Executor fixed-size pool. It seems that if I Spy the class when that class tries to do work with a thread pool, the unit test hangs.

I have created a simple example and set of simple Spock test cases which demonstrate what I am seeing. In my repo, the failing test cases are marked as @Ignore because they will, for me, reliably hang the test suite.

<a href="https://github.com/kdorff/SpiesAndGpars" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fkdorff%2FSpiesAndGpars\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXEGH7335_CQtTRQnwchddI3UFYw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fkdorff%2FSpiesAndGpars\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXEGH7335_CQtTRQnwchddI3UFYw&#39;;return true;">https://github.com/kdorff/SpiesAndGpars

All use
  • Using Groovy 2.4.7
  • Java (1.7.0_80 or 1.8.0_92)

The CalcSpec class uses:
  • Spock-core 1.1-groovy-2.4-rc-3.
  • CGLib 3.2.4
Any opinions, suggestions, or thoughts are welcome. I initially asked this of the GPars people, but they suggested that the issue must be with the Spied class somehow not being compatible with the thread pool. This sparked me to add a method (and tests) that uses the Java Executor's pools. But these appear to exhibit the same issue.

Thanks,
Kevin

--
You received this message because you are subscribed to the Google Groups "Spock Framework - User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using thread pools in a Spock Spy'd class hangs during unit tests

Spock Framework mailing list
Well, Kevin,

all I can tell you is that a Spy is a CGLIB dynamic proxy class with all its features and limitations. For more in-depth infos I leave it to others with more expertise to answer. But in the meantime why don't you just use a good old anonymous subclass? ;-)

void "gpars: Test with calc as spy, add a 2x number and a list of 2x numbers (parallel)"() {
setup:
calc = new Calc() {
@Override
Integer add(Integer n) {
return super.add(n * 2)
}
}

expect:
calc.add(3) == 6
calc.addListParallelGpars([-5, 4, 8]) == 20
}

This works nicely. Call it your home-grown spy if you like. I guess this should unblock you until you come up with a solution you like better. But I think this is simple and readable, so why not use it for good?

Regards
--
Alexander Kriegisch
https://scrum-master.de

Am Freitag, 3. Februar 2017 22:36:48 UTC+1 schrieb Kevin Dorff:
Hi,

What I have presented is a (hopefully) easy bit of code to understand which demonstrates the problem. This is not the actual production code, which is property of my company and if I posted that I'd have to answer SO MANY more questions. This simple code should be consumable by anyone and clearly demonstrates the issue I am having. Yes, perhaps i can refactor my code such that I don't have to use Spy or can spy a class that doesn't contain a thread pool which might fix it. That said...

The purpose for my first failing test is to demonstrates that (two kinds of) thread pools hang because of something about the Spy (not the Spy plus any method mocking). The tests all exist to exercise the Calc.groovy code in some way. The failing tests do the same things as the non-failing tests do, but use one of two different thread pools. In both cases, using the thread pool within a Spied object hangs the execution. Which is why I am asking.

Kevin


On Friday, February 3, 2017 at 1:22:47 PM UTC-6, Kevin Dorff wrote:
Hi,

I tried to search Google (and here) for others reporting this or a similar problem but had no obvious success.

I am attempting to write Spock unit tests for a class which contains a method that use a thread pool to do work. I have tried GPars withPool and Java's Executor fixed-size pool. It seems that if I Spy the class when that class tries to do work with a thread pool, the unit test hangs.

I have created a simple example and set of simple Spock test cases which demonstrate what I am seeing. In my repo, the failing test cases are marked as @Ignore because they will, for me, reliably hang the test suite.

<a href="https://github.com/kdorff/SpiesAndGpars" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fkdorff%2FSpiesAndGpars\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXEGH7335_CQtTRQnwchddI3UFYw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fkdorff%2FSpiesAndGpars\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXEGH7335_CQtTRQnwchddI3UFYw&#39;;return true;">https://github.com/kdorff/SpiesAndGpars

All use
  • Using Groovy 2.4.7
  • Java (1.7.0_80 or 1.8.0_92)

The CalcSpec class uses:
  • Spock-core 1.1-groovy-2.4-rc-3.
  • CGLib 3.2.4
Any opinions, suggestions, or thoughts are welcome. I initially asked this of the GPars people, but they suggested that the issue must be with the Spied class somehow not being compatible with the thread pool. This sparked me to add a method (and tests) that uses the Java Executor's pools. But these appear to exhibit the same issue.

Thanks,
Kevin

--
You received this message because you are subscribed to the Google Groups "Spock Framework - User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using thread pools in a Spock Spy'd class hangs during unit tests

Kevin Dorff
Thank you for the information and suggestions.

Kevin

On Friday, February 3, 2017 at 4:31:42 PM UTC-6, Alexander Kriegisch wrote:
Well, Kevin,

all I can tell you is that a Spy is a CGLIB dynamic proxy class with all its features and limitations. For more in-depth infos I leave it to others with more expertise to answer. But in the meantime why don't you just use a good old anonymous subclass? ;-)

void "gpars: Test with calc as spy, add a 2x number and a list of 2x numbers (parallel)"() {
setup:
calc = new Calc() {
@Override
Integer add(Integer n) {
return super.add(n * 2)
}
}

expect:
calc.add(3) == 6
calc.addListParallelGpars([-5, 4, 8]) == 20
}

This works nicely. Call it your home-grown spy if you like. I guess this should unblock you until you come up with a solution you like better. But I think this is simple and readable, so why not use it for good?

Regards
--
Alexander Kriegisch
<a href="https://scrum-master.de" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fscrum-master.de\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGL4aV3k3PRWgz0CH7v0Fw8I05SRQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fscrum-master.de\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGL4aV3k3PRWgz0CH7v0Fw8I05SRQ&#39;;return true;">https://scrum-master.de

Am Freitag, 3. Februar 2017 22:36:48 UTC+1 schrieb Kevin Dorff:
Hi,

What I have presented is a (hopefully) easy bit of code to understand which demonstrates the problem. This is not the actual production code, which is property of my company and if I posted that I'd have to answer SO MANY more questions. This simple code should be consumable by anyone and clearly demonstrates the issue I am having. Yes, perhaps i can refactor my code such that I don't have to use Spy or can spy a class that doesn't contain a thread pool which might fix it. That said...

The purpose for my first failing test is to demonstrates that (two kinds of) thread pools hang because of something about the Spy (not the Spy plus any method mocking). The tests all exist to exercise the Calc.groovy code in some way. The failing tests do the same things as the non-failing tests do, but use one of two different thread pools. In both cases, using the thread pool within a Spied object hangs the execution. Which is why I am asking.

Kevin


On Friday, February 3, 2017 at 1:22:47 PM UTC-6, Kevin Dorff wrote:
Hi,

I tried to search Google (and here) for others reporting this or a similar problem but had no obvious success.

I am attempting to write Spock unit tests for a class which contains a method that use a thread pool to do work. I have tried GPars withPool and Java's Executor fixed-size pool. It seems that if I Spy the class when that class tries to do work with a thread pool, the unit test hangs.

I have created a simple example and set of simple Spock test cases which demonstrate what I am seeing. In my repo, the failing test cases are marked as @Ignore because they will, for me, reliably hang the test suite.

<a href="https://github.com/kdorff/SpiesAndGpars" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fkdorff%2FSpiesAndGpars\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXEGH7335_CQtTRQnwchddI3UFYw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fkdorff%2FSpiesAndGpars\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXEGH7335_CQtTRQnwchddI3UFYw&#39;;return true;">https://github.com/kdorff/SpiesAndGpars

All use
  • Using Groovy 2.4.7
  • Java (1.7.0_80 or 1.8.0_92)

The CalcSpec class uses:
  • Spock-core 1.1-groovy-2.4-rc-3.
  • CGLib 3.2.4
Any opinions, suggestions, or thoughts are welcome. I initially asked this of the GPars people, but they suggested that the issue must be with the Spied class somehow not being compatible with the thread pool. This sparked me to add a method (and tests) that uses the Java Executor's pools. But these appear to exhibit the same issue.

Thanks,
Kevin

--
You received this message because you are subscribed to the Google Groups "Spock Framework - User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.
Loading...