Message-ID: <497518187.29117.1412180866352.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_29116_2146874383.1412180866352" ------=_Part_29116_2146874383.1412180866352 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
GPars library is powerful, very simple to use, well designed and it brin=
gs advanced threading concepts like DataFlows, Agents and Actors formerly o=
nly sparsely available in Scala, Clojure to the Groovy world.
I use G= Pars in my project for a billion dollar product and services company in Nor= th America. Our application performs 14 to 20 million transactions a day wh= ich involves web service, complex computations and database calls. GPars li= brary is solid and works like a charm. With this library, our application c= ode is much shorter, clean and easier to maintain.
My work life is mu= ch easier after using Agents for monitoring and collecting stats on large b= atch processing jobs, and using Data Flow Queues and Tasks for adding and c= onsuming jobs with just a few lines of code. And we got awesome support fro= m email@example.com
GPars is awesome. Generally dealing with threading and concurrency is a = real pain. With GPars you can get some very usable concurrency going in 3 l= ines of code.
We used GPars Actors to scatter HTTP = requests in our Grails project to multiple backends, gather results and str= eam HTTP chunks of results as soon as they came back from backends. It was = just plain fun, no Thread management boilerplate, just business rules optim= izations. Would definitely re-use. http://blog.xebia.fr
Yes, I use GPars, it rocks. We've hacked a rdbms -> hbase migration a= pplication, gpars helped to improve speed by a huge factor, and it was easy= to use and didn't give us problems. http://www.ecircle.com/e= n/home.html
GPars is quite awesome - I'm building a multi-threaded App that collects= metric data across a large number of Cisco switches and Linux servers (usi= ng Groovy and Java), and GPars is working like a dream. The concept o= f stateful Actors is very nice. Well done! :)
On a data migration exercise from SugarCRM to Salesforce, some of the en= tity migrations could be performed in parallel as they weren't order depend= ent. GPars was chosen for sheer simplicity of GParsPool and eachParallel - = only requiring 3 trivial new lines of code and the addition of 'Parallel' t= o the each collection iteration. GPars dramatically reduced the time taken = to migrate the data by parallelising the processing of the database result = set and the subsequent web service calls. http://leanjavaengineering.wordpress.com/2010/10/06/groo= vy-salesforce-api
GParallelizer is very cool. I had to collect information from 200 machin= es using JSCH (http://www.jcraft.com/jsch/) and 3 lines of code m= ade it 10x faster.
... having fun with GPARS because it is so easy to experiment with. It l= ets me concentrate more on the solving the problem at hand rather than worr= ying about all the Java mechanics involving with coding the details of thre= ad lifecycle management. Plus it is more expressive!
Feel free to add your own user voice t= hrough our form! We will be happy to add you and your = project to the list of happy GPars users.