Hi Roland
Thanks a lot for your answer.
The end target would be to have the data on the local system and allowing
creation of new data while offline. Then, on being online again, the diff
would be pushed and resolved. I had played with akka-persistence regarding
this application and I was wond
Hi - anyone tried using agents on Android? Any reason to think there would
be a problem?
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: http://akka.io/faq/
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this
I think what you are talking about is classical event sourcing or a
variation of it. Each new piece of data is a new event persisted somewhere
(e.g., file) on the local system. Then when remote system comes online the
event source stored up until this point would have to be replayed for the
remote
On Monday, February 10, 2014 8:28:49 AM UTC+1, Patrik Nordwall wrote:
>
> Hi Vince,
>
> On Sun, Feb 9, 2014 at 3:38 PM, Vince Golding
>
> > wrote:
>
>> I am in the process of investigating how I would go about implementing a
>> scalable fault tolerant order management system using an akka shar
Hi Roland,
thx for the reply, comments inline.
cheers,
Vince
On Monday, February 10, 2014 8:15:33 AM UTC+1, rkuhn wrote:
>
> Hi Vince,
>
> what you describe should work in principle, but I would like to understand
> your basic reasoning as to why orders shall have a persistent identity
> inst
Roland
thanks for the reply. To be more specific, let me take an example. I am
working on a legacy (monolithic) java web application that doesn't use any
particular framework (everything from the servlet to configuration was
manually crafted). The app uses Hibernate for ORM and a custom 'transac
Is there a simple configuration mechanism whereby one might specify a pool
of remote Akka systems upon which a given actor might be found?
Perhaps something like (pseudoconfig):
/remote1 {
enabled-transports = ["akka.remote.netty.tcp"]
pool = [
{hostname = "127.0.0.1",
Interesting. But isn't this really a question of a custom routing strategy
similar to Random, RoundRobin etc? Perhaps a router strategy that is aware
of the "remote Akka systems"?
Cheers
Oleg
On Mon, Feb 10, 2014 at 11:02 AM, bryan hunt wrote:
>
> Is there a simple configuration mechanism where
Hi guys,
I'm working on a pull request for adding SSL support to ReactiveMongo.
ReactiveMongo uses Netty and I remembered that akka-remote has a nice
NettySSLSupport, so I'm obviously borrowing stuff (not without copying in
the license and reference to Typesafe and akka of course!). Sadly I can
Use case: I have a REST endpoint which is developed with Spray Routing. It
receives requests from clients and for some services it calls another REST
service which is hosted on another server. After receiving response from
remote REST service it does some processing and returns the result back t
Consider the following example taken from the akka docs:
1. def receive = {
2. case "job" => worker ! "crunch"
3. case Shutdown =>
4. worker ! PoisonPill
5. context become shuttingDown
6. }
7.
8. def shuttingDown: Receive = {
9. case "job" => sender() ! "service unava
Hello
I want to swap between two cache implementations.
When the first fails, it swap to the second.
This is what i've came to. It works, but i wanna know if you guys have a
better way of doing this, because it seems that this solution is not a good
practice.
// Actor
val redisActor = con
Hi Levi,
since an actor cannot process the next message until the current has
finished, there is no problem.
On Mon, Feb 10, 2014 at 7:03 PM, Levi Notik wrote:
> Consider the following example taken from the akka docs:
>
>
>1. def receive = {
>2. case "job" => worker ! "crunch"
>3.
Hi gang.
What is the process for a node to gracefully exit a cluster?
Nodes in our system are going through this sequence:
- jvm gets the shutdown signal
- node calls cluster.leave(cluster.selfAddress)
- node waits until it sees MemberRemoved with its own address
- node gives singleton
What if you consider Hot Swap Actor, then you could rely on
become(behavior).
Pseudo-coding:
class CacheHotSwapActor extends Actor {
def memCacheReceiveLoop:Receive = {
// your code
}
def redisReceiveLoop:Receive = {
// your code
}
def receive = {
case java.net.ConnectException => be
Hi Dan,
Thank you for sharing this, I was just looking to know a little bit more on
this akka.io package and your project might just be the example I needed. I
started to read your code but I don't know very well akka. Looking at
https://github.com/oxlade39/STorrent/blob/master/src/main/scala/i
Hi Oleg
That's part of it indeed. However, I haven't seen anything related to
replaying history with the new events in akka so far, so I was planning to
only push events which don't need replaying. Actually I haven't seen
something similar in Akka at all to be honest. This kind of
"disconnected/e
I don't think there is anything to support. May be Akka-eng will chime in,
but IMHO Akka is not a product but a library and a framework which allows
you to build products. Git is a product and in theory you can easily
emulate its architecture using Akka.
Also, what Akka does provide is akka-persist
Hi
>From my experience, Akka in conjunction with Camel
(http://doc.akka.io/docs/akka/snapshot/scala/camel.html) provides a great
framework for building SOA applications. As a mediation and integration
framework, Camel provides a large set of prebuilt components and Enterprise
Integration Patter
19 matches
Mail list logo
