Infinity: Easier Than You Think. Infinitely.

Spaghettified musings on software

  • February 2020
    S M T W T F S
    « Jun    

Posts Tagged ‘concurrency’

groovy gpars – trials and tribulations Part Duex

Posted by gdjsky01 on 2009/10/10

When we left off in part one of this sojourn I had given up for the night hoping someone might see my tweet a take a look. Well getting the authors of gpars to take a look is a good thing! 😉 Thank you both.

A quick update to my part one, I see the download link for gpars is live on CodeHaus.

First I tried to join the gpars mailing list. I tried to join the google code mailing list first because that had recent activity. But I am awaiting the normal confirmation. It occurred to me, being the sharp guy I am :P, that when the move was made from Google Code to CodeHaus, the mailing list moved. So I went over to CodeHaus and tried to join a list over there. And I  am awaiting a confirmation approval. ;P

In the mean time I thought I’d browse the archive there. However the list of mailing lists showed no gpars mailinglist. So maybe the google group is the only group for now.

While this may all seem annoying, I assure you it is not. It is all completely understandable when you realize the authors are moving to a new home, and they probably have real work, jobs, and familiy to attend to. So patience should be extended to them. In time everything will straighten itself out. I did not know Dierk König was on the project! Mr “Groovy in Action!”, very cool! And I believe Vaclav works on Intellij? Is that right. I love IDEA and have used it since 2005.

Ok back to the grind….

So I am back to using the MacBook Pro since using Windows XP gave essentially the same results. First thing I did is look in lib directory of gpars. Duh!!! Right there was the correct version of the jsr166y jar. Who knew? 🙂 Okay so that was not in my classpath and needed to be. I copied that JAR to the groovy 1.6.5 library directory and deleted the one I had downloaded elsewhere Voilà! Now the DemoParallelizer and Enhancer works.

Vaclav was correct that the integration page of the CodeHaus site would have tipped me off to the correct version, but I was impatient and did not want to work with maven (ick), or gradle, or grape, or.. <insert favorite build system here>. etc.

However the Actor demos, like the DemoDiningPhilosophers were still not compiling at all. So I was perplexed at the comment about using Groovy 1.6.5 since that is what I am using. But then a light bulb (more like flash blub) went off in my head. Maybe what I had to do is compile the gpars project with Groovy 1.6.5… and do so with the source of gparallelizer 0.8.4… so now I had to find the 0.8.4 source of gpars.

I have no knowledge at all of gradle or git except for a very interesting interview with the author of gradle on the Groovy and Grails Podcast. You DO listen to that right? No? Go subscribe… I wait… go on… I’ll wait… Back? Excellent.

What I know and dislike for the most part is maven (that should be another blog post). I know Subversion, and I am learning bazaar. But git and gradle were not on the radar. For this ‘spike‘ I was just using the demonstration gpars source. No build system. Just the jars, the source, and good ole Groovy 1.6.5. I had no intention of building from source.

Best I could figure, on CodeHaus I was able to find a tag that said “Updated to groovy 1.6.5” That sounded promising so I clicked on ‘snapshot‘ which downloaded a tar file.

Again being a baby in the cradle of gradle all I could do is poke about. Like a –help switch. 🙂 Ah ha! A  –gui switch produced a nice GUI (imagine that!!) and I tried a build. Once again the building process got to :compileTests and hung. About 30 seconds later it ran out of heap space. Well I’d been down this road before (BTW: in Intellij, using the project ipr provided, the tests run just fine… weird huh?). For some reason the unit tests will not compile using gradlew. I tried using JAVA_OPTS set to  -Xmx2048m and still no worky. 🙂

So I clicked on the assemble gradle target which (apparently) skips the tests. (Yes yes I know that is not good, but this is a code spike – not production.) Hmmm… that produced a .0.9-SNAPSHOT jar, where I’d been expecting 0.8.4… no matter, that is where the SCM tag indicated the switch to groovy 1.6.5 took place. I copied that jar to groovy lib directory and ran some of the demos that had given me problems.

Success is Nearly Ours!

The jar I built ran most of the demos. Not all of them, the DemoMashupWithMethods in the Dataflow demos still, on the Mac, just starts the downloads and exits. But virtually all the Actor demos ran. Whether they are correct, of course I can not know without the unit tests working. I will bring the project into Intellij and see if the unit tests pass. They did yesterday. The difference is Intellij is compiling and running the tests, not Gradle. Not that I know that is the problem. I don’t.

I believe I have enough working now to study what types of object in gpars might map to my use case and how. Then to try some ideas of my own with gpars in the service tier of my application. For now it’ll just be ‘playing around’. At least until gpars settles down in its new home and everything runs ‘out of the box’.

More to come… comments are very welcome. Hope to see some of you (and talk) at SpringOne 2GX

Quick update: For those still curious, I did build the IntelliJ project and IntelliJ ran all the test except one. An exception test. This could be just a result of getting an intermediate build from the GIT repository instead of an official release.

I see the author of gpars did an interview with the Groovy and Grails Podcast. It will be interesting to listen. As I mentioned, Glen Smith and Sven Haiges podcast is definitely worth a listen if you are in any way involved with Groovy, GrailsGradle, or Griffon development.

Posted in Coding | Tagged: , , , , | 1 Comment »

gpars – trials and tribulations

Posted by gdjsky01 on 2009/10/10

I am trying to get gpars (formerly known as gparallelizer) to simply run it’s demos. I thought that would be a great introduction to gpars and the use cases it can solve. Needless to say, either I am not so swift, or its harder that I imagined it would be. So far I failed miserably on Mac OS-X with Java 1.6 (from Apple of course) and Groovy 1.6.5 so I thought I would start from scratch on a native Windows XP box.


  • I downloaded and installed Java 1.6. Here is what I see at the command prompt
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)
  • I downloaded and installed Groovy 1.6.5. Just took all the defaults.
C:\Dev\gparallelizer\samples>groovy --version
Groovy Version: 1.6.5 JVM: 1.6.0_16

Ok! So far so good. So now I go to the gpars site. Now I hit my first snag. This snag is common to Mac and Windows. The download link is not. Not a link that is. Drats. I don’t want to build from source. So I head to the old Google Code Site because there I can get the gparallelizer 0.8.4 jar. Which I do. I install it into the groovy lib directory… this might be a mistake, but with no other guidance, I took a chance.

While at the old Google Code Site I also grab version 0.8.4 of the samples. Now I should be stylin’

I tried this:

C:\Dev\gparallelizer\samples>groovy DemoParallelEnhancer.groovy
Caught: java.lang.NoClassDefFoundError: jsr166y/forkjoin/ForkJoinTask
at org.gparallelizer.ParallelEnhancer.class$(ParallelEnhancer.groovy)
at org.gparallelizer.ParallelEnhancer.$get$$class$org$gparallelizer$actors$pooledActors$FJPool(ParallelEnhancer.groovy)
at org.gparallelizer.ParallelEnhancer.<clinit>(ParallelEnhancer.groovy:40)
at org.gparallelizer.samples.DemoParallelEnhancer.class$(DemoParallelEnhancer.groovy)
at org.gparallelizer.samples.DemoParallelEnhancer.$get$$class$org$gparallelizer$ParallelEnhancer(DemoParallelEnhancer.groovy)

Ok so things are still complicated. 😀 So what’s JSR-166 I ask? Concurrency Utilities. I sorta gathered something like that from the ForkJoin thing. Well I downloaded from here. Ah well no… see that’s packaged as

C:\Dev\gparallelizer\samples>jar tvf "\Program Files\Groovy\Groovy-1.6.5\lib\jsr166y.jar"
 0 Tue Oct 06 15:36:08 PDT 2009 META-INF/
 102 Tue Oct 06 15:36:06 PDT 2009 META-INF/MANIFEST.MF
 0 Tue Oct 06 15:36:06 PDT 2009 jsr166y/
 1096 Tue Oct 06 15:36:06 PDT 2009 jsr166y/ForkJoinPool$1.class
 912 Tue Oct 06 15:36:06 PDT 2009 jsr166y/ForkJoinPool$DefaultForkJoinWorkerThreadFactory.class
 305 Tue Oct 06 15:36:06 PDT 2009 jsr166y/ForkJoinPool$ForkJoinWorkerThreadFactory.class
 1101 Tue Oct 06 15:36:06 PDT 2009 jsr166y/ForkJoinPool$InvokeAll.class
 306 Tue Oct 06 15:36:06 PDT 2009 jsr166y/ForkJoinPool$ManagedBlocker.class
 1308 Tue Oct 06 15:36:06 PDT 2009 jsr166y/ForkJoinPool$WaitQueueNode.class
 28273 Tue Oct 06 15:36:06 PDT 2009 jsr166y/ForkJoinPool.class
 1096 Tue Oct 06 15:36:06 PDT 2009 jsr166y/ForkJoinTask$1.class

See it’s jsr166y/ForkJoinTask not jsr166y/forkjoin/ForkJoinTask

So I figured, the gparallelizer maybe was compiled against a different version. Two of the four top level demos ran, lets try Actors.

C:\Dev\gparallelizer\samples\actors>groovy DemoLoadBalancer.groovy
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed,
General error during semantic analysis: Type ActorMessage not present

So that’s where I am right now.

Some Mac OS-X notes as well.

Most of the time I work on a MacBook Pro. All day I tinkered with gpars. On the Mac I did a GIT on src and tried to use the gradlew program. But the process hung at :compileTests and eventually (no matter how much heap I gave it with JAVA_OPTS and -XmxNNNNm) it would alway run out of heap space. I could get the assemble goal to run as it skips the tests.  Then I wound up with a 0.9-SNAPSHOT jar. But it acted strangely on the demos as well. For example the DemoMashupsWithMethods.groovy would printout “Starting download from XXXXX” and exit. Nothing else. Just exit. The Mac is running Apple’s latest 1.6 JVM and Groovy 1.6.5.

Now I know this is a pretty new item so I am not too worried. I hope maybe I can talk to folks about this at SpringOne 2GX. My use case is to break N sequential SOAP web service calls into N parallel calls joining the results. I also want to introduce groovy into production and this is finally a great use case if I can make it work. Simple, Groovy, and not introducing a whole new language which could meet with a lot more resistance (like Scala).  The point is to make more efficient use of the service tier.

Posted in Coding | Tagged: , , , , | 3 Comments »