Strange indeed
Anyway, while I don't believe that's your issue I just wanted to point out
that the code below proves nothing:
> Log.error("classloaders: " + other.getClass.getClassLoader.
eq(None.getClass.getClassLoader)) // true
. . . since it will always be 'true'
I believe your were trying t
to have them
> already tackled, if only partly, would be of a great help :$ It's almost to
> the point where having to do it all from scratch make me wonder whether
> akka would be right the right tool for the job. There may be easier ways...
>
> Thanks again !
> joseph
>
Think about what you are asking with when(_). Even if it did work it would
simply make all other when(..) irrelevant in the context of state
transitions within such FSM actor.
Now to some of your other points.
> ManagerFSM to create the child as long as the actor is preStarted
So, why not just ov
o
> have them already tackled, if only partly, would be of a great help :$ It's
> almost to the point where having to do it all from scratch make me wonder
> whether akka would be right the right tool for the job. There may be easier
> ways...
>
> Thanks again !
> jo
oment ;-)
>
> Regards,
>
> Roland
>
>
>
> On Mon, Feb 10, 2014 at 10:27 PM, Oleg Zhurakousky <
> oleg.zhurakou...@gmail.com> wrote:
>
>> What if you consider Hot Swap Actor, then you could rely on
>> become(behavior).
>> Pseudo-coding:
>> cl
ng. Actually I haven't seen
> something similar in Akka at all to be honest. This kind of
> "disconnected/extra master" doesn't seem to be supported by akka AFAIK. Am
> I right ?
>
> Best,
>
>
> On Mon, Feb 10, 2014 at 2:11 PM, Oleg Zhurakousky <
> ole
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
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
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
Interesting problem if you look at it deeper. While there are changes in
Actor between 2.2.3 and 2.3.* I can't see how those changes would make the
definition of these two Actor versions incompatible. Few methods were
added, but that should not cause binary incompatibility issue. . . until
you rea
Although I can't reproduce your issue (so may be sharing a reproducible
sample would help)
But this is somewhat common issue and could be managed with turning off the
aditivity in log4j
Try to add this line:
log4j.additivity.akka.actor.RepointableActorRef=false
Cheers
Oleg
On Thu, Feb 6, 2014 at
Well, you are not creating MDC, rather getting it from 'intmSoapResponse',
so not sure what's going on there and if there are possibilities of another
thread making entries to it.
Also, is it possible that even within the same Actor you may be modifying
MDC from separate threads (e..g, from Future
(EnabledState)(
> (s: TypeSafeState) => DisabledState
> )
> when(EnabledState)(
> (s: TypeSafeState) => TerminatedState
> )
>
> when(DisabledState)(
> (s: TypeSafeState) => EnabledState
> )
> when(DisabledState)(
> (s: TypeSafeState) =>
g\scala-lang\scala-library\2.10.1\scala-library-2.10.1.jar
> com\typesafe\config\1.0.2\config-1.0.2.jar
>
> ciao
> carlo
>
> Il giorno mercoledì 5 febbraio 2014 17:22:47 UTC+1, Oleg Zhurakousky ha
> scritto:
>>
>> What version of Akka you are using?
>>
Carlo
Can you please include the rest of the stack trace that follows:
at akka.actor.dungeon.ChildrenContainer$NormalChildrenContainer.
reserve(ChildrenContainer.scala:130)
I want to see the origin of it and since you have "do something. . .'
comments I am not sure if there is some other code tha
Have you tried to override the logger with:
loggers = ["akka.event.slf4j.Slf4jLogger"]
Cheers
Oleg
On Wed, Feb 5, 2014 at 7:28 AM, Selim Öber wrote:
> Hi,
>
> I'm using Slf4j (with logback) for both actor and non-actor logging.
> But I noticed that when auxiliary logging options are used, lik
Some versions of Hadoop did, but there are so many Hadoop distributions
(vendor packaged products) its hard to count ;). The one in question is
from Cloudera
Cheers
Oleg
On Tue, Feb 4, 2014 at 4:56 PM, √iktor Ҡlang wrote:
> The update to Protobuf 2.5 was done partly to accomodate Hadoop users
Erik
I am pretty sure that protobuf 2.5 itself is binary compatible with 2.4, so
what if you simply update CDH dependency to use protobuff 2.5. Based on the
changes I read here
https://code.google.com/p/protobuf/source/browse/trunk/CHANGES.txt I'd
seriously doubt that it would cause any issues with
ption would be sufficient.
>
>
> On Tuesday, February 4, 2014 2:23:59 PM UTC-6, Oleg Zhurakousky wrote:
>
>> *> **This seems problematic*
>> Is the concern about having too many Promises which may not complete in
>> reasonable time or fail all together? If so are you look
*> **This seems problematic*
Is the concern about having too many Promises which may not complete in
reasonable time or fail all together? If so are you looking for some type
of non-blocking throttling which would allow you to control the amount of
unfulfilled Promises?
Cheers
Oleg
On Tue, Feb
Here is the working prototype of what I believe Roland was referring to. I
think you can easily apply the same principles with FSM
trait AbstractState {
type Next
}
trait LegalTransitionFromStarting extends AbstractState
class IdleState extends AbstractState {
type Next = Star
Its 'retry-gate-closed-for'
You can see more here
http://doc.akka.io/docs/akka/snapshot/scala/remoting.html
Cheers
Oleg
On Tue, Feb 4, 2014 at 10:28 AM, Shing wrote:
> Hi,
>
> I have an ActorSystem that looks up a remote actor on startup. If the
> remote Actor system is not running, I get an
nows).
Cheers
Oleg
On Mon, Feb 3, 2014 at 2:13 AM, Patrik Nordwall
wrote:
>
>
>
> On Sun, Feb 2, 2014 at 10:33 PM, Oleg Zhurakousky <
> oleg.zhurakou...@gmail.com> wrote:
>
>> I have to admit, this is a pretty cool way of throttling in the
>> completely asy
reply or absence of reply from
>>> Consumer as a trigger for throttling.
>>> Thus I'm interested whether it's safe to use it.
>>>
>>
>> It is possible to use it as you describe.
>> /Patrik
>>
>>
>>>
>>> On 2 February 2
t overfill
> consumer's mailbox if it's slow, to avoid OutOfMemory
>
>
> On Sunday, 2 February 2014 15:27:50 UTC+2, Oleg Zhurakousky wrote:
>
>> So, what you are saying is that you want to batch up and process N amount
>> of messages before the next batch. Is that cor
So, what you are saying is that you want to batch up and process N amount
of messages before the next batch. Is that correct?
Cheers
Oleg
On Sun, Feb 2, 2014 at 7:56 AM, Yaroslav Klymko wrote:
> Hi guys,
>
> I'm wondering are there any drawback on using Identify and ActorIndentity
> reply for
I think your question is more about general integration with Storm.
Storm is easily integratable with third-party systems (including Akka) via
'spouts', and there are quite a few queue-based already part of Storm
distribution (AMQP, JMS, Kafka etc.).
However, giving the fact that Storm and Akka cro
FWIW, I do prefer the "ditch the AS" approach as well. The world did change
quite a bit and IMHO the entire JEE model is flawed, but I don't wan to
wake up the trolls ;), so I would suggest to actually look at the reasons
(aside form Akka/Scala and everything else) as to why do you think you need
A
I see. . .
So, your FSM actor in question is a JMS listener.
Side question. If you are using JMS, why not just rely on its own
persistence/transaction mechanism. This way unprocessed (uncommitted)
messages will remain on its queue, so you can avoid Persistence all
together.
Having said that I am go
While this would work for your use case, it may present more confusion when
you look at it in more general perspective.
The Processor and Recovery mechanism is based on a well known pattern
MessageStore - http://www.eaipatterns.com/MessageStore.html ( i think its
the 4th time I bring it up in the l
Vadim
I was thinking about it some more, so let me share some thoughts
Processor type actor designed for recovery-first use case where a Message
that didn't get a chance to process at the time of actor termination (e.g.,
system crash) would need to be recovered, processed and only then all other
m
Hmm, now since Roland pointed out I switched to 2.2.3 and all is fine. I
can see the three create(..) methods
May be the refresh/rebuild your project and see.
On Thu, Jan 30, 2014 at 7:59 AM, Roland Kuhn wrote:
> Even though the “real” compiler will compile it just fine, it is still
> interest
I am assuming you are using Java API.
The create() method was simply delegating to the factory apply() method, so
you can just use:
actor = system.actorOf(Props.apply(ActorHandler.class, actorPath),
"actorHandler")
On Thu, Jan 30, 2014 at 6:25 AM, Kaizah Kaiser wrote:
> Hi,
>
> I am using Akka 2
Using Processor actor implies that there may be some initial state, so its
preStart() method sends a Recover message to facilitate the recovery before
anything else happens.
The important part is that until the Recovery message is received by
Processor everything else sent to the Processor actor wi
Can you share some code. I just tried to reproduce it based on your
explanation and it all works for me (see code below), but may be I am
missing something.
Cheers
Oleg
=
import akka.actor.Actor
import akka.actor.ActorSystem
import akka.actor.FSM
import akka.actor.FSM.SubscribeTransiti
Vladislav Kuzemchik
wrote:
> Is Bar — router?
>
> понедельник, 27 января 2014 г., 23:16:46 UTC-5 пользователь Oleg
> Zhurakousky написал:
>>
>> Actually i think you are missing one more ../. I just built a hierarchy
>> that looks like yours and it works just fine
Actually i think you are missing one more ../. I just built a hierarchy
that looks like yours and it works just fine:
//akka/user
| \
Jane John
|
Foo
|
Bar
|
Baz
from Baz I can reach John
val john = context.actorSelection("../../../../John")
Here is what's going on:
>From Baz:
'../B
I think your question also falls into the category of the Complex Event
Processing (CEP) where amongst all the things described by Endre you may
also need to worry about the state of your steps and data they operate on
and how they will be affected in the event of a system crash. One of the
nature
According to javadoc for the tell(..) method
* Java API: Sends the specified message to the sender, i.e. fire-and-forget
* semantics, including the sender reference if possible (pass `null` if
* there is nobody to reply to).
So you can pass 'null' or use 'ActorRef.noSender' construct whic
There may be a better way, but this may be all you need
def isAlive(host:String, port:Int) = try {
val s = new Socket(host, port)
s.close()
true
} catch {
case e: Exception => false
}
On Fri, Jan 24, 2014 at 4:23 PM, Allan Brighton wrote:
> Hi,
>
> If I create an akka
What you're asking falls into the definition of a Message Filter pattern -
http://www.eaipatterns.com/Filter.html
If you really don't care then its essentially the same as sending
to /dev/null. But as Ryan pointed out during the development you may want
to turn the DEBUG option on, just so you can
Bryan
While I understand the general reason why we still have fat jars in this
world, it usually points to a problem (e.g., the target runtime
environment is less then adequate to manage the application's classpath
amongst other things). If its your own runtime (e.g., standalone akka app)
then I
Could you please clarify what do you mean here:
Thread.sleep(2000 + scala.util.Random.nextInt(1000)) //
system.scheduler.scheduleOnce could be used too, but worker Actor can block
The 'worker Actor' won't block in terms of thread block. It will simply be
delayed by the scheduler while
Well, my name may not be Victor, but let me give it a shot ;), since I
actually had to work on similar thing on the unrelated product.
Akka is a framework and a programming model. This means it could be used as
part of any of your existing application (Web, Console etc.) or your new
application cou
The pattern itself is called MessageStore -
http://www.eaipatterns.com/MessageStore.html and essentially describes how
message durability can be achieved in messaging systems where messages
could accumulate before they are processed.
The default mailbox in Akka is backed by an in-memory queue -
Con
I would say it goes back to the core of the disruptor technology which
essentially provides a different realization of a queue concept trough a
ring buffer which is array based (not java Queue implementations). I am
assuming mailboxes in Akka are Queue based and for high throughput cases
Queues do
46 matches
Mail list logo
