- PropertyMaster is the only place in Akka which calls
ClassLoader.getClass (apart from kernel, which might be special)
- all PropertyMaster methods (there are only three) take a ClassManifest
of what is to be constructed, and they verify that the obtained object
is actually compatible with the required type
Other stuff:
- noticed that I had forgotten to change to ExtendedActorSystem when
constructing Extensions by ExtensionKey (damn you, reflection!)
- moved Serializer.currentSystem into JavaSerializer, because that’s the
only one needing it (it’s only used in readResolve() methods)
- Serializers are constructed now with one-arg constructor taking
ExtendedActorSystem (if that exists, otherwise no-arg as before), to
allow JavaSerializer to do its magic; possibly necessary for others as
well
- Removed all Option[ClassLoader] signatures
- made it so that the ActorSystem will try context class loader, then
the class loader which loaded the class actually calling into
ActorSystem.apply, then the loader which loaded ActorSystemImpl
- for the second of the above I added a (reflectively accessed hopefully
safe) facility for getting caller Class[_] objects by using
sun.reflect.Reflection; this is optional an defaults to None, e.g. on
Android, which means that getting the caller’s classloader is done on
a best effort basis (there’s nothing we can do because a StackTrace
does not contain actual Class[_] objects).
- refactored DurableMailbox to contain the owner val and use that
instead of declaring that in all subclasses
Fixes an interesting "bug" in RandomRouter. Tests failed on my 12 core Linux box. After some investigation I found that it hanged randomly inside the SecureRandom seed generator.
[JVM-Node4] "main" prio=10 tid=0x0000000001701000 nid=0x1942 runnable [0x00007fee631dc000]
[JVM-Node4] java.lang.Thread.State: RUNNABLE
[JVM-Node4] at java.io.FileInputStream.readBytes(Native Method)
[JVM-Node4] at java.io.FileInputStream.read(FileInputStream.java:236)
[JVM-Node4] at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedBytes(SeedGenerator.java:509)
[JVM-Node4] at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:135)
[JVM-Node4] at sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:131)
[JVM-Node4] at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:188)
[JVM-Node4] - locked <0x00000007c3d84130> (a sun.security.provider.SecureRandom)
[JVM-Node4] at java.security.SecureRandom.nextBytes(SecureRandom.java:450)
[JVM-Node4] - locked <0x00000007c3d843d0> (a java.security.SecureRandom)
[JVM-Node4] at java.security.SecureRandom.next(SecureRandom.java:472)
[JVM-Node4] at java.util.Random.nextInt(Random.java:272)
[JVM-Node4] at akka.routing.RandomLike$class.getNext$2(Routing.scala:466)
Puzzled at first I Googled the problem and found this bug report: http://bugs.sun.com/view_bug.do?bug_id=6521844
In short it is designed to block on /dev/random (on Linux) when the entropy pool is empty until some "environmental noise is gathered".
From the Linux manual:
"Hanging at generateSeed is not a bug, since that's what was designed:
When the entropy pool is empty, reads from /dev/random will block until
additional environmental noise is gathered.
(Source: Linux Programmer's Manual, section 4)"
Fix was to switch to java.util.Random.
Fun one
Signed-off-by: Jonas Bonér <jonas@jonasboner.com>
