* ActorTimeout (akka.actor.timeout) was used to all sorts of things.
* TestKit default-timeout
* TypedActor timeout for non void methods
* Transactor coordinated-timeout
* ZeroMQ new-socket-timeout
* And in various tests
- assert locking balance when using Unsafe.instance.monitorExit
- add RouterConfig.routerDispatcher
- re-enable “busy” resizer test after switching to BalancingDispatcher
- document resizer asynchronicity and how to configure dispatchers
* Wrote a comprehensive example for pub-sub
* Clarified how publish to topic is done
* Several minor, but important, api adjustments for the java api, and some also profit for scala
* Added documentation for Java and updated documentation for Scala
- 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
- when encountering new message type, check all bindings which map apply
- if multiple are found, choose the most specific one if that exists or
verify that all mappings yield the same serializer
- in case of remaining ambiguity, throw exception
- also add special handling for “none” serializer mapping: turn off a
default
