I have created an issue so that someone (great community contribution) can
pick it up: https://github.com/akka/akka/issues/17738
On Sun, Jun 7, 2015 at 12:12 PM, Akka Team akka.offic...@gmail.com wrote:
Hi Guido,
You cannot import the release-2.3-dev in newest IntelliJ, I filed them a
bug
Awesome, thanks for making Akka better!
/Patrik
On Tue, Jun 16, 2015 at 10:51 AM, Guido Medina oxyg...@gmail.com wrote:
I'll send you the pull request in several minutes, also the signing for
contribution.
On Tuesday, June 16, 2015 at 9:22:16 AM UTC+1, Patrik Nordwall wrote:
I have created
I'll send you the pull request in several minutes, also the signing for
contribution.
On Tuesday, June 16, 2015 at 9:22:16 AM UTC+1, Patrik Nordwall wrote:
I have created an issue so that someone (great community contribution) can
pick it up: https://github.com/akka/akka/issues/17738
On
Awesome, thanks a lot Guido!
--
Cheers,
Konrad 'ktoso’ Malawski
Akka @ Typesafe
On 16 June 2015 at 10:55:03, Patrik Nordwall (patrik.nordw...@gmail.com) wrote:
Awesome, thanks for making Akka better!
/Patrik
On Tue, Jun 16, 2015 at 10:51 AM, Guido Medina oxyg...@gmail.com wrote:
I'll send you
Hi Guido,
You cannot import the release-2.3-dev in newest IntelliJ, I filed them a
bug last week. Can you still make this a proper PR? You can build Akka
using sbt only, or you can still use the old sbt-idea plugin to make a
project that IDEA can read (that is what I use now until they fix the
I modified the original to be correct, theoretically when your AtomicLong
reaches the *Long.MAX_VALUE* + 1 it will shift to *Long.MIN_VALUE* making
the mod (%) function return negative which will make the application fail
due to invalid list index *-list.get(neg_index)-*
In practice that is
Will do that ;-)
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
Sounds like a great contribution!
/Patrik
29 maj 2015 kl. 17:55 skrev Konrad Malawski kt...@typesafe.com:
Hi Guido,
we're happy to take performance improvement contributions however they should
be backed with some JMH benchmark to prove the claimed perf benefits :-)
You can easily run
Hi Guido,
we're happy to take performance improvement contributions however they
should be backed with some JMH benchmark to prove the claimed perf benefits
:-)
You can easily run benchmarks by just adding one to our akka-bench-jmh
subproject.
Looking forward to the PR, then we can discuss
In fact, I think my implementation should not only be faster but it is also
safer due to the *-unlikely event?-* of reaching Long.MAX_VALUE, a side by
side comparison:
- Both implementations compare and set the value atomically, but mine
does it for an *AtomicInteger vs AtomicLong* which
Have you profiled this to quantify the performance improvement, and if so,
did you run it under high contention situations to be sure the locks on the
atomic don't start to be an issue under high contention?
On Thursday, May 28, 2015 at 11:43:24 AM UTC-4, Guido Medina wrote:
Hi,
I have my
There is one thing to clarify and two differences:
- There are no locks in atomic operations, remember atomic operations
are based on CAS.
- Incrementing an *AtomicInteger* will definitely be cheaper than
incrementing an *AtomicLong.*
- Comparing the value and returning is
12 matches
Mail list logo
