Re: [akka-user] Can Akka run without listening on a port?
Hi Bryn, On Thu, Oct 30, 2014 at 7:20 PM, Bryn Keller xol...@xoltar.org wrote: Thanks, Endre. I'm not quite clear on what you're saying - I understand Akka wants to work in peer-to-peer mode, but I don't understand this part: It is not about Akka wanting to work in peer-to-peer mode, it is *Akka Remoting* wanting to work in P2P. This does not mean that you cannot use Akka in a Client-Server setup though, but you will need to implement your own client-server connection. This can be done over pure TCP using akka.io, but you can also make a REST endpoint using Spray server and client. Are you saying that Akka *can* work client-server if I implement some class or classes myself and configure Akka to use it/them, or are you saying that I can't use Akka for communication between client and server in this scenario at all (other than Akka I/O, which is not what I'm asking about)? No, what I wanted to say that Akka Remoting is not the only possible way to connect actor systems. The main goal of Remoting is to provide complete location transparency of ActorRefs, but that implies peer-to-peer operation. Clustering is also a P2P technology and works on top of Remoting. Remoting is recommended to be used in large cooperative backend systems where this P2P trust relationship is fine. If you want to have Akka systems in a pure client-server setting then you should use an *alternate *mechanism of communication between them instead of remoting. One option is to use Akka IO and build a TCP connection between the two systems. Other option is simply to use HTTP, and implement a restful service on the server which you connect to from the client. Spray provides all these tools and is working on top of Akka. If I need to implement some custom transport for Akka myself, how would I go about that? Akka custom transport doesn't produce much in a Google search, are there some other resources? Custom transports will not work here. The assumption of complete symmetry between actors is deep in the underlying actor model and implies the P2P architecture. I.e. you cannot build a non P2P transport without breaking location transparency. To be clear, I have an existing third party application that uses Akka actor systems for remote communication, so I would prefer a solution that lets me simply configure Akka to use some custom built components rather than having to completely change the interface between client and server. Is this possible? No, this is not possible. Also, due to location transparency if you use remoting to connect clients, then it can accidentally happen that an ActorRef from one client leaks to the other, or an ActorRef from the backend leaks (the sender field is enough for that to happen). By using a clearly demarkated interface: - you prevent leaks and decrease the trust between client and system - you are free to evolve your client-server protocol no longer tied to Akka, maybe exposing it to 3rd parties later -Endre Thanks, Bryn -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Stopping a reactive stream
Hi Adam,
On Thu, Oct 30, 2014 at 1:43 PM, Adam Warski a...@warski.org wrote:
There's an OnCompleteDrain :) (btw. - sink, drain, subscriber - a lot of
names ;) )
Drain is no longer there (as a name at least) and you should usually not
see a Subscriber ;)
How do I use broadcast, thought? I can see it can be a vertex in the
graph, but how to add it?
An example:
FlowGraph { implicit b ⇒
val bcast = Broadcast[Int](broadcast)
Source(List(1, 2, 3)) ~ bcast
bcast ~ Flow[Int] ~ Sink(s1)
bcast ~ Flow[Int] ~ Sink(s2)
}.run()
So I'll end up with sth like this:
/--- sink1 (output
stream)
source -- trans1 -- broadcast --
\--- sink2 (on
complete drain)
Will the failure of sink1 propagate to a completion of the whole stream?
In theory it could continue in a crippled way (with only one branch
remaining).
True, in this setup sink2 will get the termination event of source but
will not get the canceled event of sink1. Internally it is configurable if
broadcast should continue or not in this case but this is not exposed to
the users (it continues by default now).
Btw, in your TCP example you don't use the inputStream of the connection,
if you use that stream it will give you the termination events of the TCP
connection (normal/error). Output stream can only say cancelled but not
why.
-Endre
Thanks!
Adam
On Thursday, October 30, 2014 1:22:41 PM UTC+1, Akka Team wrote:
Hi Adam,
You can use broadcast to split out the stream going into the Sink, and
then attach to that side of the graph an OnCompleteSink which takes a
function callback: Try[Unit] ⇒ Unit which is called during normal and
failure termination.
-Endre
On Thu, Oct 30, 2014 at 12:31 PM, Adam Warski ad...@warski.org wrote:
Sure :) I'm using streams 0.9, scaladsl2 and I want to add failure
detection to that:
https://github.com/adamw/reactmq/blob/master/src/main/
scala/com/reactmq/Sender.scala
Adam
On Thursday, October 30, 2014 12:04:23 PM UTC+1, Akka Team wrote:
Hi Adam,
I'm not running Windows (MacOS), but how could these signals be
handled? I was looking for some handlers in the value returned by run()
(e.g. onComplete, onError), but it seems not much is there :)
Which version of Akka Stream are you using and which version of the
scaladsl? How does your pipeline look like, what is the sink element (the
thing in which you pipe TCP into).
In general, a code snippet would help a lot.
-Endre
Thanks,
Adam
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/c
urrent/additional/faq.html
Search the archives: https://groups.google.com/grou
p/akka-user
---
You received this message because you are subscribed to the Google
Groups Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send
an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
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 User List group.
To unsubscribe from this group and stop receiving emails from it, send
an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
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 User List group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
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
Re: [akka-user] Akka Persistence journal size
Hi Dan, On Thu, Oct 30, 2014 at 6:36 PM, Dan Ellis d...@danellis.me wrote: You can delete them by reacting to a snapshot succcess by issuing an deleteMessages(toSequenceNr = lastseqnr). If I only care about recovery and not auditing, are there any disadvantages to doing that? This is also about recovery. If you have the full event log you can recover *corrupted* storage much easier, since you can delete corrupted events, modify events, etc. if necessary, which is way harder with a corrupted blob. There is a reason why many filesystems use a journal, and many databases provide an oplog, too. If you are worried about growing journal size and you really want to delete, I recommend first going without delete, seeing how quickly the journal grows and then implement a deletion policy that preferably keeps logs not just after the latest snapshot, but maybe after the 3rd latest snapshot or so, depending on your disk space requirement. -Endre Would it be considered an anti-pattern? I'm just evaluating and considering my options at the moment -- I don't know that space will be an issue. -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Stopping a reactive stream
On Thu, Oct 30, 2014 at 1:43 PM, Adam Warski ad...@warski.org
javascript: wrote:
There's an OnCompleteDrain :) (btw. - sink, drain, subscriber - a lot of
names ;) )
Drain is no longer there (as a name at least) and you should usually not
see a Subscriber ;)
It is in 0.9, but as I understand it's not in master :)
How do I use broadcast, thought? I can see it can be a vertex in the
graph, but how to add it?
An example:
FlowGraph { implicit b ⇒
val bcast = Broadcast[Int](broadcast)
Source(List(1, 2, 3)) ~ bcast
bcast ~ Flow[Int] ~ Sink(s1)
bcast ~ Flow[Int] ~ Sink(s2)
}.run()
Thanks, I'll try that.
So I'll end up with sth like this:
/--- sink1
(output stream)
source -- trans1 -- broadcast --
\--- sink2 (on
complete drain)
Will the failure of sink1 propagate to a completion of the whole stream?
In theory it could continue in a crippled way (with only one branch
remaining).
True, in this setup sink2 will get the termination event of source but
will not get the canceled event of sink1. Internally it is configurable if
broadcast should continue or not in this case but this is not exposed to
the users (it continues by default now).
So even if sink1 fails, the whole setup will continue? So using sink2 (on
complete sink/drain) won't have any effect? Is there a way to detect errors
in such case then?
Btw, in your TCP example you don't use the inputStream of the connection,
if you use that stream it will give you the termination events of the TCP
connection (normal/error). Output stream can only say cancelled but not
why.
Well this application only sends data, so I don't need the input stream for
anything.
Even supposing broadcast does work, shouldn't there be some other way to
detect and handle failures/errors/completions? E.g. wouldn't it make sense
to add a callback to run()? Or make run() return some kind of Future?
Creating an artificial broadcast just to detect errors seems not optimal :)
Adam
--
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
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Stopping a reactive stream
On Fri, Oct 31, 2014 at 10:50 AM, Adam Warski a...@warski.org wrote: So even if sink1 fails, the whole setup will continue? So using sink2 (on complete sink/drain) won't have any effect? Is there a way to detect errors in such case then? Sink2 will detect the failure of source, but not of sink1. Currently there is no way to detect it, because most people expect the broadcast to continue instead of failing. We can make it configurable though. You should be aware though that using the stream TCP you *don't* get an error event from the outputStream anyway, you only get notified that it has cancelled (Reactive Streams specify only cancel as an event propagated from downstream to upstream), but not the reason why. See my other answer a bit below before you panic :) Btw, in your TCP example you don't use the inputStream of the connection, if you use that stream it will give you the termination events of the TCP connection (normal/error). Output stream can only say cancelled but not why. Well this application only sends data, so I don't need the input stream for anything. This is not true, you always need to connect something to the input stream, because it is the thing that carries the termination events of the *TCP stream pair* -- i.e. failures in outputs will be also reported on this channel. You don't need to do anything with the input data though, you can just attach an OnComplete Drain/Sink (whatever it is named in that version ;) ), that will discard all data anyway, but will not clog the inbound TCP buffers even if the remote part happens to send things, and you will get the TCP termination events in the callback you provided to OnComplete Even supposing broadcast does work, shouldn't there be some other way to detect and handle failures/errors/completions? E.g. wouldn't it make sense to add a callback to run()? Or make run() return some kind of Future? Creating an artificial broadcast just to detect errors seems not optimal :) There is a common misconception here. Imagine a setup like this: inputFile - someProcessing - outputFile Now imagine that we provided an API that gives a completion future after you call run(). Now if that future completes, would that mean that writing to the file finished? Unfortunately no, since the completion of a Reactive Streams means that no elements in flight anymore and everyone is aware of that, but this does not imply that all the buffers of the outputFile writer has been flushed and the file has been closed. This is exactly why Akka Streams provide Sinks (formerly Drains) that can return a completion Future (or whatever they want to return) of their own that is completely library dependent -- for example a file writer Sink can give a Future that represents the event while the file has been completely closed. -Endre Adam -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Persistent View needs to recover to work correctly
Hi,
It looks like a View can't work if I disable its recovery.
For my specific case I really don't care about the recovery since this
view is just storing its events in a different datastore (and format)
than the original journal.
For instance this short test doesn't work:
class TestPersistentActor extends PersistentActor with ActorLogging {
override def persistenceId = test
def receiveRecover = Actor.emptyBehavior
def receiveCommand = LoggingReceive {
case test = persist(test) { e =
sender() ! done
}
}
}
class TestPersistentView extends PersistentView with ActorLogging {
override def persistenceId = test
override def viewId = view
override def autoUpdateInterval: FiniteDuration = 50.millis
// disable recovery
override def preStart() = {}
var seenTest = false
def receive = LoggingReceive {
case test if isPersistent = seenTest = true
case check = sender() ! seenTest
}
}
...
it(should work) {
val probe = TestProbe()
val view: ActorRef = system.actorOf(Props(new TestPersistentView()), name =
view)
val actor: ActorRef = system.actorOf(Props(new TestPersistentActor()), name
= actor)
actor.!(test)(probe.ref)
probe.expectMsg(done)
Thread.sleep(500)
view.!(check)(probe.ref)
probe.expectMsg(true)
}
The documentation says that it works like PersistentActor recovery
(which also explains how to prevent recovery).
Is that a bug or did I miss something?
--
Brice Figureau
My Blog: http://www.masterzen.fr/
--
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
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Stopping a reactive stream
So even if sink1 fails, the whole setup will continue? So using sink2 (on complete sink/drain) won't have any effect? Is there a way to detect errors in such case then? Sink2 will detect the failure of source, but not of sink1. Currently there is no way to detect it, because most people expect the broadcast to continue instead of failing. We can make it configurable though. Right, I can imagine needing both. Similar to a one-for-one and one-for-all failover strategy when using actor supervisor hierarchies. Btw. the javadoc for Broadcast currently says: It will not shutdown until the subscriptions for at least two downstream subscribers have been established.. Why two? Shouldn't it be either one or all? :) You should be aware though that using the stream TCP you *don't* get an error event from the outputStream anyway, you only get notified that it has cancelled (Reactive Streams specify only cancel as an event propagated from downstream to upstream), but not the reason why. See my other answer a bit below before you panic :) Would it make sense to add something to the current API which could detect such failures? Btw, in your TCP example you don't use the inputStream of the connection, if you use that stream it will give you the termination events of the TCP connection (normal/error). Output stream can only say cancelled but not why. Well this application only sends data, so I don't need the input stream for anything. This is not true, you always need to connect something to the input stream, because it is the thing that carries the termination events of the *TCP stream pair* -- i.e. failures in outputs will be also reported on this channel. You don't need to do anything with the input data though, you can just attach an OnComplete Drain/Sink (whatever it is named in that version ;) ), that will discard all data anyway, but will not clog the inbound TCP buffers even if the remote part happens to send things, and you will get the TCP termination events in the callback you provided to OnComplete Ok, that's in fact much nicer, I didn't like the approach of broadcasting just to detect errors :). I'll try that in the evening. Even supposing broadcast does work, shouldn't there be some other way to detect and handle failures/errors/completions? E.g. wouldn't it make sense to add a callback to run()? Or make run() return some kind of Future? Creating an artificial broadcast just to detect errors seems not optimal :) There is a common misconception here. Imagine a setup like this: inputFile - someProcessing - outputFile Now imagine that we provided an API that gives a completion future after you call run(). Now if that future completes, would that mean that writing to the file finished? Unfortunately no, since the completion of a Reactive Streams means that no elements in flight anymore and everyone is aware of that, but this does not imply that all the buffers of the outputFile writer has been flushed and the file has been closed. This is exactly why Akka Streams provide Sinks (formerly Drains) that can return a completion Future (or whatever they want to return) of their own that is completely library dependent -- for example a file writer Sink can give a Future that represents the event while the file has been completely closed. So each sink should provide a sink-dependent way of letting the user know when things are done or cancelled. Doesn't it mean that there should be a way to provide a callback or sth like that when creating the specific Subscriber, here it's implemented by the TCP extension? E.g. a Future or similar as part of the binding: StreamTcp.OutgoingTcpConnection? Adam -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Right Place To Instantiate Persistence View
Team, We are currently instantiating Persistence View's from postStartup method of persistent actor. Is this the right place? What are the recommendations for instantiating Persistence View's? and from where? -Prakhyat M M -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Best way to integrate akka into a legacy/existing app
Hi Francois, On Thu, Oct 30, 2014 at 11:36 PM, Francois fan...@gmail.com wrote: Hello everybody, I want to add Akka to an existing scala web application (not play), and I'm wondering how it could be best achieve. The goal for now is not to build a fully distributed and fault tolerant system, but to introduce Akka at some point in the application and let its use grow, allowing to set clear bound in that application and define subsystems. A nice and solution would be to have a new application in Akka side by side with the legacy one, providing new services or REST endpoint or something. This is one option. You can also embed an ActorSystem in other applications and you might be able to expose a Future based API to its external collaborators. In this case Akka would not communicate over-the-wire but in JVM. But I prefer to not investigate that solution for now and try to understand how Akka can be incorporated into an existing app. I'm particulary intersted into knowing how 1/ Akka boot in that case and 2/ how to deals with the bound between actors and legacy code. Akka does not need any special thing to boot. You can just create an ActorSystem instance and it starts. You can even explicitly pass in a Config object if you want to fully control how it gets its initial configuration. For 1/, http://doc.akka.io/docs/akka/1.3.1/scala/http.html seems to be the correct resources. Is there other example or documentation on the subject ? (I didn't find many other intersting one, any help would be appreciated). That is a very outdated link since it refers to Akka 1.3.1 which is very old now. Some of the current frameworks for HTTP related work are: - Play (playframework.com) which can be used as a REST endpoint, but generally geared towards Web development - Spray (spray.io) which is built on top of Akka and integrates easily with Akka. Best used for REST endpoints - Akka Http which is Spray ported to the new Akka Streams infrastructure. This is currently pre-experimental and the docs are sketchy right now. Also we change the API very aggressively in every 2-3 weeks I thought it could be linked to http://doc.akka.io/docs/akka/2.3.6/scala/typed-actors.html. Typed actors are no longer recommended, we will eventually phase them out. Is it correct ? If so, is there any ressources demoing a more complexe integration ? Because I'm not sure how I implement my actor subsystem from the typed actor boundaries with the legacy app. Thanks for any help or pointer to ressources ! As a very first step you should read the documentation ( http://doc.akka.io/docs/akka/2.3.6/scala.html?_ga=1.228976988.1520294582.1409309043) especially the Introduction, General and Actors sections. There is also a list of books that can be helpful: http://doc.akka.io/docs/akka/2.3.6/additional/books.html (although some of them might be about earlier Akka versions, but 2.2 and 2.3 are sufficiently similar) -Endre -- Francois ARMAND http://rudder-project.org http://www.normation.com -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Best way to integrate akka into a legacy/existing app
As you say Typed actors are no longer recommended, we will eventually phase them out. and I have question for you what is alternative for cases where need integrate exists application with akka? пятница, 31 октября 2014 г., 16:33:45 UTC+3 пользователь Akka Team написал: Hi Francois, On Thu, Oct 30, 2014 at 11:36 PM, Francois fan...@gmail.com javascript: wrote: Hello everybody, I want to add Akka to an existing scala web application (not play), and I'm wondering how it could be best achieve. The goal for now is not to build a fully distributed and fault tolerant system, but to introduce Akka at some point in the application and let its use grow, allowing to set clear bound in that application and define subsystems. A nice and solution would be to have a new application in Akka side by side with the legacy one, providing new services or REST endpoint or something. This is one option. You can also embed an ActorSystem in other applications and you might be able to expose a Future based API to its external collaborators. In this case Akka would not communicate over-the-wire but in JVM. But I prefer to not investigate that solution for now and try to understand how Akka can be incorporated into an existing app. I'm particulary intersted into knowing how 1/ Akka boot in that case and 2/ how to deals with the bound between actors and legacy code. Akka does not need any special thing to boot. You can just create an ActorSystem instance and it starts. You can even explicitly pass in a Config object if you want to fully control how it gets its initial configuration. For 1/, http://doc.akka.io/docs/akka/1.3.1/scala/http.html seems to be the correct resources. Is there other example or documentation on the subject ? (I didn't find many other intersting one, any help would be appreciated). That is a very outdated link since it refers to Akka 1.3.1 which is very old now. Some of the current frameworks for HTTP related work are: - Play (playframework.com) which can be used as a REST endpoint, but generally geared towards Web development - Spray (spray.io) which is built on top of Akka and integrates easily with Akka. Best used for REST endpoints - Akka Http which is Spray ported to the new Akka Streams infrastructure. This is currently pre-experimental and the docs are sketchy right now. Also we change the API very aggressively in every 2-3 weeks I thought it could be linked to http://doc.akka.io/docs/akka/2.3.6/scala/typed-actors.html. Typed actors are no longer recommended, we will eventually phase them out. Is it correct ? If so, is there any ressources demoing a more complexe integration ? Because I'm not sure how I implement my actor subsystem from the typed actor boundaries with the legacy app. Thanks for any help or pointer to ressources ! As a very first step you should read the documentation ( http://doc.akka.io/docs/akka/2.3.6/scala.html?_ga=1.228976988.1520294582.1409309043) especially the Introduction, General and Actors sections. There is also a list of books that can be helpful: http://doc.akka.io/docs/akka/2.3.6/additional/books.html (although some of them might be about earlier Akka versions, but 2.2 and 2.3 are sufficiently similar) -Endre -- Francois ARMAND http://rudder-project.org http://www.normation.com -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com javascript:. To post to this group, send email to akka...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka Persistence insights
Thanks, √ :) On Thursday, 30 October 2014 11:54:50 UTC, √ wrote: Hi Saparbek, If sequenceNr is a Long (64-bit) you'd have to generate 1 event per nanosecond for 292 years before it overflows. If your system is still running in 292 years and you are able to generate 1 event per nanosecond, let us know :) On Thu, Oct 30, 2014 at 12:48 PM, Saparbek Smailov s.sm...@ocado.com javascript: wrote: Hello all, I have been looking into this library https://github.com/sclasen/akka-persistence-dynamodb/ and I got couple of questions both about the library and the Akka Persistence in general. One of the questions that I have is this: Is persistence counter going to ever reset? As far I understand sequence numbers are generated as highest sequence number + 1, but isn't it going to overflow? Is there any mechanism to delete all messages and start counter from the beginning? Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the “Ocado Group” are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Titan Court, 3 Bishops Square, Hatfield Business Park, Hatfield, Herts. AL10 9NE. -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com javascript:. To post to this group, send email to akka...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Cheers, √ -- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the “Ocado Group” are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Titan Court, 3 Bishops Square, Hatfield Business Park, Hatfield, Herts. AL10 9NE. -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Per-Request Actor
I'm just wondering if there's anything in Akka (post request hook?) or Scala pattern matching that would allow me to create a Per-Request Actor type that would call context.stop(self) after handling any message? -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: Per-Request Actor
Take a look to this: http://typesafe.com/activator/template/spray-actor-per-request пятница, 31 октября 2014 г., 19:25:22 UTC+3 пользователь rpr...@sprypoint.com написал: I'm just wondering if there's anything in Akka (post request hook?) or Scala pattern matching that would allow me to create a Per-Request Actor type that would call context.stop(self) after handling any message? -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Stopping a reactive stream
Ok, so getting closer, seems to work :) Thanks a lot for the help. On the sender side I added a separate flow for the input stream, attached an on complete drain and I get the callback. One small thing, even if I kill the other side of the connection, the callback contains a Success(()). On the receiver side I added the forking (broadcast), and I'm getting the callback when the other side is killed. Doesn't it mean that there should be a way to provide a callback or sth like that when creating the specific Subscriber, here it's implemented by the TCP extension? E.g. a Future or similar as part of the binding: StreamTcp.OutgoingTcpConnection? The input stream conveys all the information you need about closing events, I don't see the need currently for a side-channel. We prefer to keep as much as possible in-stream and not out-of-stream. Since TCP is a stream in itself it works quite well, unlike with the file example I had where there is a pure sink. That said, we might add more functionality if needed but the design goal is to keep these external signals minimal. Sure, this makes sense. Having as little of an additional protocol as possible is certainly nice. Though the fact that a socket died doesn't always require protocol support (I mean, often you will know that a socket isn't working without sending special pings or such). So this could get exposed to the user. Adam -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: Per-Request Actor
What kind of requests are you talking about ? HTTP or an message to Actor's receive method ? On Friday, October 31, 2014 12:25:22 PM UTC-4, rpr...@sprypoint.com wrote: I'm just wondering if there's anything in Akka (post request hook?) or Scala pattern matching that would allow me to create a Per-Request Actor type that would call context.stop(self) after handling any message? -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: Best way to integrate akka into a legacy/existing app
I personally feel it's better to isolate your new and legacy application into two separate JVMs and connect them using REST and pub/sub endpoints. Of course this could be a deal breaker if you cannot afford the overhead of the REST endpoints. Spray (which is based on Akka) is the ideal choice for this IMO. This will not only allow you to do parallel development (once REST endpoints are defined) but also you can start to move functionality from the legacy system to the new system incrementally. This will also ensure that you can isolate bugs, failure and performance issues independently and measure and demonstrate the value of introducing a new technology into your existing system. One of the best things about the Akka/Spray/Play is that they are container-less and can be used as a library into a system. I applied this system approach to migrate a system that was written in Java/Storm/Jetty to Scala/Akka/Spray/Play incrementally with great success. HTH -Soumya On Thursday, October 30, 2014 6:39:36 PM UTC-4, fanf wrote: Hello everybody, I want to add Akka to an existing scala web application (not play), and I'm wondering how it could be best achieve. The goal for now is not to build a fully distributed and fault tolerant system, but to introduce Akka at some point in the application and let its use grow, allowing to set clear bound in that application and define subsystems. A nice and solution would be to have a new application in Akka side by side with the legacy one, providing new services or REST endpoint or something. But I prefer to not investigate that solution for now and try to understand how Akka can be incorporated into an existing app. I'm particulary intersted into knowing how 1/ Akka boot in that case and 2/ how to deals with the bound between actors and legacy code. For 1/, http://doc.akka.io/docs/akka/1.3.1/scala/http.html seems to be the correct resources. Is there other example or documentation on the subject ? (I didn't find many other intersting one, any help would be appreciated). For 2/, let me start by saying that I have two places where I want to use akka at first: some kind of batch processes, which are more or less standalone (and so, not very interesting), and repository, or at least the proxy code between backend data storage base and the remaining code. So, at one point, I imagine having an actor at the place of the existing repository service, accepting messages in place of method calls. But I don't see how to do that. I thought it could be linked to http://doc.akka.io/docs/akka/2.3.6/scala/typed-actors.html. Is it correct ? If so, is there any ressources demoing a more complexe integration ? Because I'm not sure how I implement my actor subsystem from the typed actor boundaries with the legacy app. Thanks for any help or pointer to ressources ! -- Francois ARMAND http://rudder-project.org http://www.normation.com -- 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 User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
