[akka-user] ClusterSingleton, multiple proxies?
Hi, I have several utility ClusterSingleton actors in my cluster that are used by several client actors (some of them are also singleton or ClusterSharding entries). Those client actors are currently created by passing the ActoRef of said utility singletons proxies as Props arguments. This can't work when those actors are themselves singletons or sharded entries, because they might run on a different node than the passed-in proxies (and props might not even be serialized?). So I need to refactor all this to not pass any ActorRef. My question finally is what would be the best way to achieve that: * have client actors create their own proxy (or ClusterShard region). This doesn't seem the good solution :( or * have a well known per-node registry actor that creates the needed proxies (and region) at start and can send those ActorRef to client actors. I'm much more inclined toward the second solution, but unfortunately it makes the various tests a bit more complex (setup a registry instead of injecting TestProbe). What do you think? Is there a better solution I didn't think about? -- 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.
[akka-user] Re: Sharing behavior among Actors in Java
Hi Adam
Really appreciate your ideas and code samples! Thank you.
These are interesting angles to take and I'm definitely trying to see how
this can fit my specific case. I'll be most likely bound to Java 7 so the
composition approach is more possible (though using interfaces with default
methods is interesting). It's a bit of a struggle though as while
composition does come on top (of inheritance) in many cases, in this
specific case inheritance seems like a classic fit. I'm using it mainly for
code reuse but there are multiple levels of derived classes where 90
percent of the code is in the parent class and the rest is overridden by
the children.
An equivalent to your example would be:
class DbAccess
class SqlServerAccess extends DbAccess
class SqlServer2012Access extends SqlServerAccess
where
DbAccess implements all that is needed to access any database (say, over
JDBC) - run ad-hoc queries, use JDBC metadata interface, etc. Almost all of
the code is here.
SqlServerAccess inherits all of DbAccess functionality but perhaps
overrides a single routine that needs to use a sqlserver specific syntax
(e.g, use TOP instead of LIMIT for getting sample data).
SqlServer2012Access inherits all of the above, but also adds another call
for using a feature that only exists in this version.
so it's a classic 'is-a' case (in IMO at least), and assuming that some
cases have 4 or 5 levels of inheritance - composition is no longer trivial.
It could be though that redesigning/rearranging the classes in a different
way logically will change that. Like you, I'm not a big fan of inheritance
with many hierarchy levels.
Thx
Alon
On Wednesday, January 14, 2015 at 11:26:21 PM UTC+2, Adam wrote:
Hi,
I guess the correct answer is it depends J, but I can describe what we
use right now, as we're also using Akka (and seeing as it's been very
rewarding to do so we do it more and more), but are confined to Java.So
first of all, I would recommend against inheritance.
That route quickly becomes very tangled and results in a huge hierarchy of
classes with way too many methods.
We typically use composition.
I assume the real issue is cases where you want to reuse code that relies
on running inside an Actor.
Unfortunately UntypedActor is not an interface, so it's indeed difficult
to mix in behavior.However, since a class method is really not much more
than a static method that implicitly accepts the this pointer (some
languages like python and Ada even work that way and specify all arguments
explicitly), your actors can contain other classes that either have methods
which accept an UntypedActor as a parameter, or accept it in their
constructor.
We use that often for synchronous paths.
An example:
public class DbAccess {
private final UntypedActor owner;
public DbAccess(UntypedActor owner) {
this.owner = owner;
}
//methods for DB access
}
public class Auth {
private final UntypedActor owner;
public Auth(UntypedActor owner) {
this.owner = owner;
}
//methods for Authentication
}
public class MyActor extends UntypedActor{
private final DbAccess db = new DbAccess(this);
private final Auth auth = new Auth(this);
public void onReceive(Object msg){
//use the shared logic of db and auth wherever needed
}
}
(One nasty issue here is that the constructor of MyActor is sending this
before it's fully constructed, so it's probably better to move the
initialization of dependencies to preStart, but I kept the code shorter
here)
There are exceptions to this rule.
For example, if you wanted to override any of the UntypedActor methods
(e.g. we do that for one-off actors so they will stop in case of an
unhandled message), you'd have to use inheritance, so in some cases we do
use that, but we try to keep it down to as few levels of it as possible.
Another alternative if you're using Java 8 AND your methods don't rely on
state, is to use interfaces with default methods,as a poor man's
replacement for Scala traits.
In that case, if you wanted to rely on running inside an actor you could
require actors to implement a single interface that exposes the this
pointer and then add as many interfaces with default methods as you wish.
For example:
public interface ActorExposer {
public UntypedActor getActor();
}
public interface DbUser extends ActorExposer{
//methods for DB access
public default ...
}
public class Auth extends ActorExposer{
//methods for Authentication
public default ...
}
public class MyActor implements DbUser, Auth{
public void onReceive(Object msg){
//use the shared logic of db and auth whereever needed
}
@Override
public UntypedActor getActor() {
return this;
}
}
Finally, for asynchronous paths we simply use more actors, but I assume
that was already obvious to you and you
Re: [akka-user] Akka Cluster and Persistence Consistency
Hello! On Thursday, January 15, 2015 at 8:50:23 AM UTC+2, Patrik Nordwall wrote: On Wed, Jan 14, 2015 at 6:58 PM, Oleg Mürk oleg...@gmail.com javascript: wrote: I'd like to better understand what happens to a Leader if it becomes unreachable. Auto-down is impossible because it can only be performed by the Leader, right? Can I execute Down command on non-leader member of cluster when the Leader is unreachable? Akka Cluster doesn't require a strict leader for managing the cluster membership. The membership data is a Conflict Free Replicated Data Type (CRDT) so if there are conflicting updates they can be merged anyway. The leader is just a role for a node that performs certain actions and it is alright if several nodes thinks they have this role. Got it, thanks! So Persistence and consequently Sharding cannot be used in potential split-brain cluster configurations? Because ShardCoordinator could potentially run on both partitions simultaneously? It is right that you must only be one active instance of a PersistentActor with a given persistenceId, i.e. single writer to the journal. That is true also for the ShardCoordinator, since it is a PersistentActor. That means that you must handle network partitions carefully and use a proper downing strategy as discussed earlier. We have acknowledged that a packaged solution for improving this have been requested by many users. ... We don't need strong coordination for cluster membership and we have the goal to support large clusters http://typesafe.com/blog/running-a-2400-akka-nodes-cluster-on-google-compute-engine, which I believe would not be possible with Zookeeper. Zookeeper is great, but it is solving a different set of problems. I agree that current Akka's CRDT based group membership protocol serves its purpose well. It's also possible to build coordination services on top of Akka Cluster, as illustrated by Konrad's akka-raft https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fktoso%2Fakka-raftsa=Dsntz=1usg=AFQjCNFeBbv21ujT_X6PqpivN5ZMzZHkYw prototype. I suppose one could use Zookeeper for ensuring uniqueness of a Singleton or ShardCoordinator/ShardRegion? AFAIK Zookeeper scales to 1000s of *clients*? Another question I had is how to handle situations when eg ShardCoordinator/ShardRegion cannot communicate with Zookeeper, while ShardRegion's persistent Entities can communicate with, say, HBase. But I guess it a question for another mailig list :) Thanks! Oleg -- 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] WartRemover error on Akka receive methods
Hello there,
As I understand it, wart-remover is configurable to which warts” it should be
reporting.
In the case of Actor.Receive it’s not happy because it is an alias to Any =
Unit.
Without a large philosophical dive why it is such and not a different signature
(and btw. Roland will soon soon get a new impl ot akka.typed out for preview
;-)),
let’s address your problem and question at hand.
Two solutions come to mind:
1) Since the wart is triggered for “inferred type contains Any”, you can write
the type explicitly (def receive: Receive = …) instead of it being inferred I
assume? (Did not try that though)
2) As seen on: https://github.com/puffnfresh/wartremover these warts can be
enabled / disabled at will.
warts can be configured and in your case you’d like to keep all “except
inferred type contains Any”,
so you could use:
wartremoverErrors := Warts.allBut(Wart.Any)
which should make it happy on receive methods.
Hope this helps!
Disclaimer: I did not try this, but it seems to all logically fall into place
:-)
--
Konrad 'ktoso’ Malawski
Akka @ Typesafe
On 15 January 2015 at 22:24:00, javierg (javierg1...@gmail.com) wrote:
Hi all,
Apologies for the more than slightly offtopic question.
I recently started using WartRemover and one of the first things that I
encountered is a barrage of error notifications like what follows (for, as long
as I can see, every receive method in my codebase)
Error:(31, 7) Inferred type containing Any
def receive = {
^
Before WartRemover this code used to compile (and run) without issues.
WartRemover claims it doesn't report false positives, but I'm getting this
error on cases as simple and trivial as the following (admittedly contrived)
example
def receive = {
case a:String = log.info(a)
case _ = log.info(Unexpected input)
}
Is there a way to solve this (other than asking WartRemover to not report this)?
Thanks in advance,
Javier
--
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.
--
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] WartRemover error on Akka receive methods
One idea:
def receive = { case = ... } : Receive
(On my phone so may not work)
--
Cheers,
√
On 15 Jan 2015 23:06, javierg javierg1...@gmail.com wrote:
Hi Konrad,
Adding the type signature doesn't seem to have any effect
*Error:(31, 26) Inferred type containing Any*
* def receive: Receive = {*
* ^*
I'm aware that WartRemover can be configured.
I could set this particular wart to be reported as a *warning* and not an
*error* but that will also make any other (valid) instances to marked as
such and it's my experience that warnings get, more often than not, swept
under the rug (something I was trying to avoid.)
Still, like you mentioned, there doesn't seem to be a solution for this at
the moment. I just wanted to be sure I wasn't missing something obvious.
Many thanks for the prompt reply.
On Thursday, January 15, 2015 at 4:32:47 PM UTC-5, Konrad Malawski wrote:
Hello there,
As I understand it, wart-remover is configurable to which warts” it
should be reporting.
In the case of Actor.Receive it’s not happy because it is an alias to Any
= Unit.
Without a large philosophical dive why it is such and not a different
signature (and btw. Roland will soon soon get a new impl ot akka.typed out
for preview ;-)),
let’s address your problem and question at hand.
Two solutions come to mind:
1) Since the wart is triggered for “inferred type contains Any”, you can
write the type explicitly (def receive: Receive = …) instead of it being
inferred I assume? (Did not try that though)
2) As seen on: https://github.com/puffnfresh/wartremover these warts can
be enabled / disabled at will.
warts can be configured and in your case you’d like to keep all “except
inferred type contains Any”,
so you could use:
wartremoverErrors := Warts.allBut(Wart.Any)
which should make it happy on receive methods.
Hope this helps!
Disclaimer: I did not try this, but it seems to all logically fall into
place :-)
--
Konrad 'ktoso’ Malawski
Akka http://akka.io @ Typesafe http://typesafe.com
On 15 January 2015 at 22:24:00, javierg (javie...@gmail.com) wrote:
Hi all,
Apologies for the more than slightly offtopic question.
I recently started using WartRemover and one of the first things that I
encountered is a barrage of error notifications like what follows (for, as
long as I can see, every receive method in my codebase)
*Error:(31, 7) Inferred type containing Any*
* def receive = {*
* ^*
Before WartRemover this code used to compile (and run) without issues.
WartRemover claims it doesn't report false positives, but I'm getting this
error on cases as simple and trivial as the following (admittedly
contrived) example
*def receive = {*
*case a:String = log.info http://log.info(a)*
*case _ = log.info http://log.info(Unexpected input)*
*} *
Is there a way to solve this (other than asking WartRemover to not report
this)?
Thanks in advance,
Javier
--
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.
--
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.
--
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] WartRemover error on Akka receive methods
Hi Konrad,
Adding the type signature doesn't seem to have any effect
*Error:(31, 26) Inferred type containing Any*
* def receive: Receive = {*
* ^*
I'm aware that WartRemover can be configured.
I could set this particular wart to be reported as a *warning* and not an
*error* but that will also make any other (valid) instances to marked as
such and it's my experience that warnings get, more often than not, swept
under the rug (something I was trying to avoid.)
Still, like you mentioned, there doesn't seem to be a solution for this at
the moment. I just wanted to be sure I wasn't missing something obvious.
Many thanks for the prompt reply.
On Thursday, January 15, 2015 at 4:32:47 PM UTC-5, Konrad Malawski wrote:
Hello there,
As I understand it, wart-remover is configurable to which warts” it
should be reporting.
In the case of Actor.Receive it’s not happy because it is an alias to Any
= Unit.
Without a large philosophical dive why it is such and not a different
signature (and btw. Roland will soon soon get a new impl ot akka.typed out
for preview ;-)),
let’s address your problem and question at hand.
Two solutions come to mind:
1) Since the wart is triggered for “inferred type contains Any”, you can
write the type explicitly (def receive: Receive = …) instead of it being
inferred I assume? (Did not try that though)
2) As seen on: https://github.com/puffnfresh/wartremover these warts can
be enabled / disabled at will.
warts can be configured and in your case you’d like to keep all “except
inferred type contains Any”,
so you could use:
wartremoverErrors := Warts.allBut(Wart.Any)
which should make it happy on receive methods.
Hope this helps!
Disclaimer: I did not try this, but it seems to all logically fall into
place :-)
--
Konrad 'ktoso’ Malawski
Akka http://akka.io @ Typesafe http://typesafe.com
On 15 January 2015 at 22:24:00, javierg (javie...@gmail.com javascript:)
wrote:
Hi all,
Apologies for the more than slightly offtopic question.
I recently started using WartRemover and one of the first things that I
encountered is a barrage of error notifications like what follows (for, as
long as I can see, every receive method in my codebase)
*Error:(31, 7) Inferred type containing Any*
* def receive = {*
* ^*
Before WartRemover this code used to compile (and run) without issues.
WartRemover claims it doesn't report false positives, but I'm getting this
error on cases as simple and trivial as the following (admittedly
contrived) example
*def receive = {*
*case a:String = log.info http://log.info(a)*
*case _ = log.info http://log.info(Unexpected input)*
*} *
Is there a way to solve this (other than asking WartRemover to not report
this)?
Thanks in advance,
Javier
--
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.
--
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 retries
Hi. I am working on something that processes messages from a kafka topic using akka-camel When i receive a message i attempt to contact a third party system when this system is unavailable i'd like to retry in 10 minutes, 20 minutes, etc up to 5 times. I guess I could accomplish this easily by using context.system.scheduler.scheduleOnce but id the system reboots 5 minutes after a message failed to process then i would loose the retry. Additionally I am not entirely comfortable with piling up all retry messages in memory (potentially I could exhaust all of the available memory) So I am looking for a solution that addresses both of these issues. Can anyone offer any guidance ? --jelmer -- 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] WartRemover error on Akka receive methods
Maybe wartremover should be able to be more configurable, as in “if it’s an
Actor don’t report this - I know already”.
Sounds like a possible cool improvement - maybe you could bring it up on their
issue tracker?
Related, the Scala have a tool called scala-abide which works in a similar way
as wartremover: https://github.com/scala/scala-abide
They also have this warning about “inferred any” I believe (core module), and
additionally they have some typical Akka warnings (closing over sender() etc):
https://github.com/scala/scala-abide/tree/master/rules
I’m not sure if they can enable the warning we’re talking about contextually
though hm...
Both look like like great tools, great to see more linters coming to scala :-)
--
Konrad 'ktoso’ Malawski
Akka @ Typesafe
On 15 January 2015 at 23:18:49, Viktor Klang (viktor.kl...@gmail.com) wrote:
One idea:
def receive = { case = ... } : Receive
(On my phone so may not work)
--
Cheers,
√
On 15 Jan 2015 23:06, javierg javierg1...@gmail.com wrote:
Hi Konrad,
Adding the type signature doesn't seem to have any effect
Error:(31, 26) Inferred type containing Any
def receive: Receive = {
^
I'm aware that WartRemover can be configured.
I could set this particular wart to be reported as a warning and not an error
but that will also make any other (valid) instances to marked as such and it's
my experience that warnings get, more often than not, swept under the rug
(something I was trying to avoid.)
Still, like you mentioned, there doesn't seem to be a solution for this at the
moment. I just wanted to be sure I wasn't missing something obvious.
Many thanks for the prompt reply.
On Thursday, January 15, 2015 at 4:32:47 PM UTC-5, Konrad Malawski wrote:
Hello there,
As I understand it, wart-remover is configurable to which warts” it should be
reporting.
In the case of Actor.Receive it’s not happy because it is an alias to Any =
Unit.
Without a large philosophical dive why it is such and not a different signature
(and btw. Roland will soon soon get a new impl ot akka.typed out for preview
;-)),
let’s address your problem and question at hand.
Two solutions come to mind:
1) Since the wart is triggered for “inferred type contains Any”, you can write
the type explicitly (def receive: Receive = …) instead of it being inferred I
assume? (Did not try that though)
2) As seen on: https://github.com/puffnfresh/wartremover these warts can be
enabled / disabled at will.
warts can be configured and in your case you’d like to keep all “except
inferred type contains Any”,
so you could use:
wartremoverErrors := Warts.allBut(Wart.Any)
which should make it happy on receive methods.
Hope this helps!
Disclaimer: I did not try this, but it seems to all logically fall into place
:-)
--
Konrad 'ktoso’ Malawski
Akka @ Typesafe
On 15 January 2015 at 22:24:00, javierg (javie...@gmail.com) wrote:
Hi all,
Apologies for the more than slightly offtopic question.
I recently started using WartRemover and one of the first things that I
encountered is a barrage of error notifications like what follows (for, as long
as I can see, every receive method in my codebase)
Error:(31, 7) Inferred type containing Any
def receive = {
^
Before WartRemover this code used to compile (and run) without issues.
WartRemover claims it doesn't report false positives, but I'm getting this
error on cases as simple and trivial as the following (admittedly contrived)
example
def receive = {
case a:String = log.info(a)
case _ = log.info(Unexpected input)
}
Is there a way to solve this (other than asking WartRemover to not report this)?
Thanks in advance,
Javier
--
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.
--
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.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search
Re: [akka-user] WartRemover error on Akka receive methods
*Not sure if double-posting (my last reply seems to have dissapeared.)
Apologies in advance if you get this twice*
Hi guys,
Viktor's idea doesn't seem to have any effect either.
Konrad, yes, that'd be ideal and I'll raise the issue with them.
I wasn't aware of scala-abide, it seems a bit more inmature than
WartRemove, but what you mention about Akka specific warts might make it
worth the extra effort. I'll definitely check it out.
Thanks for the pointer.
On Thursday, January 15, 2015 at 5:26:22 PM UTC-5, Konrad Malawski wrote:
Maybe wartremover should be able to be more configurable, as in “if it’s
an Actor don’t report this - I know already”.
Sounds like a possible cool improvement - maybe you could bring it up on
their issue tracker?
Related, the Scala have a tool called scala-abide which works in a similar
way as wartremover: https://github.com/scala/scala-abide
They also have this warning about “inferred any” I believe (core module),
and additionally they have some typical Akka warnings (closing over
sender() etc):
https://github.com/scala/scala-abide/tree/master/rules
I’m not sure if they can enable the warning we’re talking about
contextually though hm...
Both look like like great tools, great to see more linters coming to scala
:-)
--
Konrad 'ktoso’ Malawski
Akka http://akka.io @ Typesafe http://typesafe.com
On 15 January 2015 at 23:18:49, Viktor Klang (viktor...@gmail.com
javascript:) wrote:
One idea:
def receive = { case = ... } : Receive
(On my phone so may not work)
--
Cheers,
√
On 15 Jan 2015 23:06, javierg javie...@gmail.com javascript: wrote:
Hi Konrad,
Adding the type signature doesn't seem to have any effect
*Error:(31, 26) Inferred type containing Any*
* def receive: Receive = {*
* ^*
I'm aware that WartRemover can be configured.
I could set this particular wart to be reported as a *warning* and not
an *error* but that will also make any other (valid) instances to marked
as such and it's my experience that warnings get, more often than not,
swept under the rug (something I was trying to avoid.)
Still, like you mentioned, there doesn't seem to be a solution for this
at the moment. I just wanted to be sure I wasn't missing something obvious.
Many thanks for the prompt reply.
On Thursday, January 15, 2015 at 4:32:47 PM UTC-5, Konrad Malawski wrote:
Hello there,
As I understand it, wart-remover is configurable to which warts” it
should be reporting.
In the case of Actor.Receive it’s not happy because it is an alias to
Any = Unit.
Without a large philosophical dive why it is such and not a different
signature (and btw. Roland will soon soon get a new impl ot akka.typed out
for preview ;-)),
let’s address your problem and question at hand.
Two solutions come to mind:
1) Since the wart is triggered for “inferred type contains Any”, you
can write the type explicitly (def receive: Receive = …) instead of it
being inferred I assume? (Did not try that though)
2) As seen on: https://github.com/puffnfresh/wartremover these warts
can be enabled / disabled at will.
warts can be configured and in your case you’d like to keep all
“except inferred type contains Any”,
so you could use:
wartremoverErrors := Warts.allBut(Wart.Any)
which should make it happy on receive methods.
Hope this helps!
Disclaimer: I did not try this, but it seems to all logically fall into
place :-)
--
Konrad 'ktoso’ Malawski
Akka http://akka.io @ Typesafe http://typesafe.com
On 15 January 2015 at 22:24:00, javierg (javie...@gmail.com) wrote:
Hi all,
Apologies for the more than slightly offtopic question.
I recently started using WartRemover and one of the first things that I
encountered is a barrage of error notifications like what follows (for, as
long as I can see, every receive method in my codebase)
*Error:(31, 7) Inferred type containing Any*
* def receive = {*
* ^*
Before WartRemover this code used to compile (and run) without issues.
WartRemover claims it doesn't report false positives, but I'm getting this
error on cases as simple and trivial as the following (admittedly
contrived) example
*def receive = {*
*case a:String = log.info http://log.info(a)*
*case _ = log.info http://log.info(Unexpected input)*
*} *
Is there a way to solve this (other than asking WartRemover to not
report this)?
Thanks in advance,
Javier
--
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-user] WartRemover error on Akka receive methods
Hi all,
Apologies for the more than slightly offtopic question.
I recently started using WartRemover and one of the first things that I
encountered is a barrage of error notifications like what follows (for, as
long as I can see, every receive method in my codebase)
*Error:(31, 7) Inferred type containing Any*
* def receive = {*
* ^*
Before WartRemover this code used to compile (and run) without issues.
WartRemover claims it doesn't report false positives, but I'm getting this
error on cases as simple and trivial as the following (admittedly
contrived) example
*def receive = {*
*case a:String = log.info(a)*
*case _ = log.info(Unexpected input)*
*} *
Is there a way to solve this (other than asking WartRemover to not report
this)?
Thanks in advance,
Javier
--
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] Implementing at-least-once ingestion pipeline with Akka streams
Hey folks, I would like to implement an at-least-once ingestion pipeline, say from a source like Kafka, to a datastore, using Akka streams. The method of at-least-once is that each incoming message has an increasing numeric offset, and the idea is that successful writes into the datastore would send back the last committed offset, which should increase over time. If a failure occurs, then the ingestion can be restarted from the last committed offset, by replaying messages from the source (or a write-ahead log, for example). How would I design such a system? Let's start with the naive implementation: kafkaSource.map(someTransformFunc).to(dataStoreSink) This gives us backpressure, but no ack feedbacks. I can think of two ways to add the ack feedback. One is to make the writing to the datastore not a sink but a mapAsync stage that uses futures to write, and returns the latest completed offset. kafkaSource.map(someTransformFunc).mapAsync(writeToDataStoreFuture _) This is incomplete, because there is no flow. Ideally, the stream of completed offsets would be fed back to kafkaSource so it knows the latest committed offset, and if some error occurred (possibly also a result), then the source could replay messages. How to do this? A second approach, which seems hacky and not so idiomatic, is to make kafkaSource and dataStoreSink into ActorPublisher and ActorSubscribers, respectively. Then, the dataStoreSink could send out of band ack messages to the kafkaSource actor directly. It's not clear to me that backpressure is really needed for the acks, I think the most critical part is that writing to the datastore has backpressure. Any thoughts? Many thanks, Evan -- 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] Dispatcher assignment issue for Http Server
I am trying to assign a dispatcher to be used for my http server (using the
new Akka HTTP Server) and can’t get it to honor my pool size settings.
Logs show it is using the dispatcher, but visualvm shows it is not using
the core pool size settings. Loos like it might be using the defaults for
a thread-pool-executor.
All I did was modify the example:
1. import akka.http.Http
2. import akka.stream.FlowMaterializer
3.
4. implicit val system = ActorSystem()
5. implicit val materializer = FlowMaterializer(*MaterializerSettings*(
*system*).withDispatcher(*“myhttpRequestHandler.dispatcher*))
6.
7. val serverBinding = Http(system).bind(interface = localhost, port =
8080)
8. serverBinding.connections.foreach { connection = // foreach
materializes the source
9. println(Accepted new connection from + connection.remoteAddress)
10. }
11. …
myhttpRequestHandler {
dispatcher {
type = Dispatcher
executor = *thread-pool-executor*
name = httprequesthandler-dispatcher
thread-pool-executor {
core-pool-size-min = 100
core-pool-size-factor = 2.0
core-pool-size-max = 100
}
throughput = 5
}
}
[INFO] [2015-01-15 17:24:27,516] [DUDE-myhttpRequestHandler.dispatcher-79]
HttpRequestHandler(akka://DUDE): Accepted new connection from
/127.0.0.1:54046
What am I missing?
Thanks,
Randy Fox
--
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: weird reason of association with remote system has failed
This happened to me before. If Reply is available for both actorsystem with the same classpath, then when creating your actorsystem, supply the second and third argument especially the third argument for class loader. Somthing like ActorSystem(name, config, getClass.getClassLoader) -- 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.
