60","","","18"
"akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinTask)
ForkJoinPool.java:1339","","","19"
"akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool$WorkQueue)
ForkJoinPool.java:1979"
specifically (which shows up when there’s nothing to do, so it spins looking
> for work).
>
>
> —
> Konrad `kto.so` Malawski
> Akka @ Lightbend
>
> On 10 October 2017 at 18:47:37, Sam Halliday (sam.halli...@gmail.com) wrote:
>
> Hi all,
>
> Yourkit's CPU pr
Hi all,
Yourkit's CPU profiler has the ability to hide classes / symbols.
There is typically a lot of CPU noise when profiling an akka application
(Thread.sleep, ForkJoinPool, etc etc), does anybody have a good "ignore
list" of methods that shouldn't matter?
Best regards,
Sam
--
>>
Hi all,
Is it possible to override / bypass the time dilation introduced by the
akka.test.timefactor for some tests? I do some expectNoMsg tests in loops
which is fine without dilation, but when running on a really slow CI
machine it introduces a lot of waiting with very little value... I
Great! We already have a branch in ENSIME to expose our JSON protocol
(JERKY) over akka-http REST and WebSockets:
https://github.com/fommil/ensime-server/blob/websocket/server/src/main/scala/org/ensime/server/WebSocketBoilerplate.scala
On Wednesday, 15 July 2015 13:40:25 UTC+1, Konrad Malawski
Hi all,
I'm trying to migrate from Spray to Akka-HTTP and I'm failing to be able to
compile this most basic of examples:
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC4/scala/http/routing-dsl/index.html
The API for bindAndHandle must have changed because I have a `Route`
Hi all,
I often find myself wanting to read the scaladocs for Akka using the
built-in ENSIME documentation browser (e.g. show me docs of the symbol at
point). But the doc artefact that comes with Akka, via the standard sbt
`updateClassifiers` call, seems to be the Javadocs, not the Scaladocs.
Dear all,
I had a few questions for this list last week regarding an unrecoverable
error condition that I was seeing in Wandoulabs WebSockets.
I have now isolated the problem to standard Scala 2.11.7 / Akka 2.3.11
Tcp.Write with the minimal example at the bottom of this email.
It seems that
Aha! Think I got it.
I need to send ResumeWriting and listen for a WritingResumed, to recover
from such a situation.
On Monday, 6 July 2015 11:01:23 UTC+1, Sam Halliday wrote:
I should say, that in every example I have tried... with payloads up to
30MB for the initial un-acked message
*be used to implement NACK-based write backpressure.
this implies that if useResumeWriting=false then further writes after a
CommandFailed *will* be successful when the backlog is cleared. Is this
correct?
On Monday, 6 July 2015 11:18:13 UTC+1, Sam Halliday wrote:
Aha! Think I got
+1, Sam Halliday wrote:
Dear all,
I had a few questions for this list last week regarding an unrecoverable
error condition that I was seeing in Wandoulabs WebSockets.
I have now isolated the problem to standard Scala 2.11.7 / Akka 2.3.11
Tcp.Write with the minimal example at the bottom
This is the fuller example: you need to edit the hostname and port:
https://github.com/fommil/simple-spray-websockets/blob/master/src/test/scala/testing/Buggy.scala#L78
On Friday, 3 July 2015 14:25:42 UTC+1, Sam Halliday wrote:
I should point out that this example is just a way that I can
responses without asking for Acks, but they are nowhere near as large as
these messages.
On Friday, 3 July 2015 14:18:11 UTC+1, Sam Halliday wrote:
Hi all,
I'm using akka-io (and spray-io) with wandoulabs WebSockets to send
messages across a network.
If I send a message of this size, without
Hi all,
I'm using akka-io (and spray-io) with wandoulabs WebSockets to send
messages across a network.
If I send a message of this size, without expecting an Ack:
connection ! Tcp.Write(FrameRender(TextFrame(A * 36040033)))
and then send a message (any size), expecting an Ack:
is an explicit goal in our infrastructure.
Regards,
Roland
22 jun 2015 kl. 11:02 skrev Viktor Klang viktor...@gmail.com
javascript::
Doing the filtering pre-substitution seems like a bug.
--
Cheers,
√
On 22 Jun 2015 01:54, Sam Halliday sam.ha...@gmail.com javascript:
wrote:
Patrik
, event) {
val logger = Logger(logClass, logSource)
if (logger.isDebugEnabled()) {
logger.debug(message.toString)
}
}
case InitializeLogger(_) =
sender() ! LoggerInitialized
}
}
On Monday, 22 June 2015 10:33:20 UTC+1, Sam Halliday wrote
materialize it to a string at call site.
/Patrik
On Mon, Jun 22, 2015 at 12:40 PM, Sam Halliday sam.ha...@gmail.com
javascript: wrote:
On Monday, 22 June 2015 11:30:30 UTC+1, √ wrote:
Why deduplicate non-logged events at all?
Doing the substitution but not incurring the IO cost must be worth
if the loglevel is DEBUG.
if (context.system.eventStream.logLevel = Logging.DebugLevel) {
/Patrik
On Thu, Jun 18, 2015 at 11:01 PM, Sam Halliday sam.ha...@gmail.com
javascript: wrote:
Hi all,
I'm seeing something very weird.
When I enable the logback turboFilter
://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Patrik Nordwall patrik.nordw...@gmail.com writes:
On Sun, Jun 21, 2015 at 4:04 PM, Sam Halliday sam.halli...@gmail.com
wrote:
Everything is DEBUG, and this is akka 2.3.11.
ok
We log these (and all other things
Hi all,
I'm seeing something very weird.
When I enable the logback turboFilter DuplicateMessageFilter:
http://logback.qos.ch/manual/filters.html#DuplicateMessageFilter
A Future is definitely mutable (it will hopefully complete), but you cannot
mutate it.
You'd be best caching the result of the Future, rather than the future
itself.
On Wednesday, 27 May 2015 21:48:52 UTC+1, Moiz Raja wrote:
I have a piece of code where I make a request to an actor using ask
Hi Roland,
On Wednesday, 27 May 2015 08:18:09 UTC+1, rkuhn wrote:
For this venture you need no HTTP documentation
Actually I'd like to go futher than akka-http and see documentation that
allows me to use WebSockets with akka-io directly, bypassing the
Streaming API.
The historic limitation has
On Wednesday, 27 May 2015 14:01:46 UTC+1, rkuhn wrote:
Maybe I misunderstand you still, but ConnectionManager is not something
that we have in Akka HTTP
I am referring to the `manager` field in an implementation of
`akka.io.IO.Extension`. The limitation that I'm referring to lies with
be better to explain the ends and not
the means in order to get help.
Regards,
Roland
23 maj 2015 kl. 12:38 skrev Sam Halliday sam.halli...@gmail.com:
Hi all,
I'm very excited that akka-io now has WebSocket support.
In ENSIME, we're planning on using this wrapper over wandoulab's
that are expected
to go to deadLetters by adding the marker `DeadLetterSuppression` to such
messages. It would be great if you (and other users) can open pull requests
(and issues) when you find such messages.
Thanks,
Patrik
On Fri, May 22, 2015 at 6:37 PM, Sam Halliday sam.ha...@gmail.com
PR it is
https://github.com/akka/akka/pull/17571
Note that your scalariform version is old and hence conflicts with anything
using a more recent version (including ensime-sbt).
On Tuesday, 26 May 2015 10:59:57 UTC+1, Patrik Nordwall wrote:
On Tue, May 26, 2015 at 11:31 AM, Sam Halliday
re-raised as a ticket, because of the CLA
https://github.com/akka/akka/issues/17572
On Tuesday, 26 May 2015 11:32:39 UTC+1, Sam Halliday wrote:
PR it is
https://github.com/akka/akka/pull/17571
Note that your scalariform version is old and hence conflicts with
anything using a more recent
Hi all,
I need to interface an Actor with an API that requires a Flow.
The actor can receive a sealed trait family of inputs and will only send (a
different) sealed family of outputs to upstream, so I suspect that will
help matters.
Looking in FlowOps, it looks like I can create a Flow from a
...
although I am not sure how yet. That's the second problem once I can
actually get everything hooked up.
On Tuesday, 26 May 2015 13:57:43 UTC+1, √ wrote:
Not knowing what your actor is trying to do, what about Flow.mapAsync +
ask?
--
Cheers,
√
On 26 May 2015 14:54, Sam Halliday
PM UTC+2, Sam Halliday wrote:
Hi all,
I'm very excited that akka-io now has WebSocket support.
In ENSIME, we're planning on using this wrapper over wandoulab's
websockets
https://github.com/smootoo/simple-spray-websockets
to easily create a REST/WebSockets endpoint with JSON
Hi all,
I have another thread about retrofitting wandoulabs websockets to use
akka-io, which is proving painful, but I wanted to separate out this aspect
of the questioning.
Before I invest any more time into it, I'd like to know if the new
websockets implementation actually implements
+1, Sam Halliday wrote:
Re: asyncyMap. I don't think that is going to work, there is no implied
single response to each query (which I gather is what you're suggesting)?
And I need some way of receiving new messages from upstream.
The existing Actor is both a sink (i.e. it consumes messages
Hi all,
I'm very excited that akka-io now has WebSocket support.
In ENSIME, we're planning on using this wrapper over wandoulab's websockets
https://github.com/smootoo/simple-spray-websockets
to easily create a REST/WebSockets endpoint with JSON marshalling for a
sealed family, with
Hi all,
Some messages that arrive in dead letters are of no concern at all, such as
`Tcp.Close` (which happens a lot when using Akka IO).
Is there any way to filter out the logging of these particular dead letter
messages so that they don't clutter up the log?
Best regards,
Sam
--
occurring again.
Best regards,
Sam
On Wednesday, 25 March 2015 13:02:31 UTC, Patrik Nordwall wrote:
On Thu, Mar 19, 2015 at 12:42 PM, Sam Halliday sam.ha...@gmail.com
javascript: wrote:
Hi all,
We are using Spray IO (with the wandoulabs WebSockets layer) on really
old RHEL5 boxes in our
Hi all,
In Spray IO, the ConnectionHandler.baseCommandPipeline is extremely chatty
when using backpressure.
//# final-stages
def baseCommandPipeline(tcpConnection: ActorRef): Pipeline[Command] = {
case x @ (_: Tcp.WriteCommand | _: Tcp.CloseCommand) ⇒ tcpConnection ! x
case
Grr, so it seems that TestActorRef really is incompatible with Stash.
http://stackoverflow.com/questions/18335127
This is a real shame.
On Monday, 2 March 2015 12:35:22 UTC, Sam Halliday wrote:
Wow, I think I figured this out... and it's quite scary.
Stash needs an unbounded mailbox. I
lines off by using
SupervisorStrategy.stoppingStrategy.
Regards,
Roland
27 feb 2015 kl. 11:37 skrev Sam Halliday sam.ha...@gmail.com
javascript::
My hack:
/**
* `TestActorRef`s are restarted by default on exceptions, but this
* just stops them.
*
* https://groups.google.com/forum
Hi,
I am testing an Actor and mocking out one of its dependencies. When the
test fails, e.g. an unexpected call to the mock (which causes an exception)
the Actor is restarted and all I end up with is several GB of logging
because it gets into an infinite restart loop.
Is there any *simple*
] but I really hope websockets will be part
of akka-streams/http 1.1+ as I suspect it'll be implemented somewhat
differently :-)
[5] https://github.com/wandoulabs/spray-websocket/issues/68
Best regards,
Sam
On Friday, 20 February 2015 17:09:53 UTC, Sam Halliday wrote:
Hi all,
I am trying
Hi all,
I am trying to enable ACK-based backpressure on a websocket server.
The Akka IO backpressure is really fantastic and easy to understand[1].
The Spray Can docs mention something about automatic backpressure[2], but I
can't find any more information about what this means. I presume this
Hi all,
I read
here
http://spray.io/documentation/1.1-SNAPSHOT/spray-can/http-server/#ssl-support
that there is an implicit ServerSSLEngineProvider on Http.Bind
but the latest HTTP docs
http://doc.akka.io/docs/akka-stream-and-http-experimental/current/scala/http/https.html
say is not yet
can find a simple example demonstrating that. And there is a documentation
http://doc.akka.io/docs/akka/2.3.9/scala/logging.html#Loggers section
explaining this.
On Mon, Jan 19, 2015 at 11:02 AM, Sam Halliday sam.ha...@gmail.com
javascript: wrote:
Is this something that would
On Wednesday, 21 January 2015 08:21:15 UTC, drewhk wrote:
I believe it may be possible to use the current 1.0-M2 to address
my bugbear by using the Actor integration to write an actor that
has N instances behind a router, but it feels hacky to have to
use an Actor at all. What is really
,
you can use custom event listener to display the log messages that you are
interested in.
Here you can find a simple example demonstrating that. And there is a
documentation section explaining this.
On Mon, Jan 19, 2015 at 11:02 AM, Sam Halliday sam.halli...@gmail.com
wrote
Err, Endre, yes. And when merging Seq[T] in a mapConcat we would all
benefit greatly from faster merging, Seq[Seq[T]] = Seq[T]
On 21 Jan 2015 08:03, Endre Varga endre.va...@typesafe.com wrote:
Hi Sam,
On Tue, Jan 20, 2015 at 9:56 PM, Sam Halliday sam.halli...@gmail.com
wrote:
One more
about the strategy that is used.
On 21 Jan 2015 09:09, Endre Varga endre.va...@typesafe.com wrote:
On Wed, Jan 21, 2015 at 10:06 AM, Sam Halliday sam.halli...@gmail.com
wrote:
There was some discussion about merging Seq in the docs.
If that is so, can you point to that part? We might need
Dear Akka Team,
In response to Bjorn's prompting[1], I have read all the Akka
Streams 1.0-M2 documentation[2].
I am very impressed, and excited! There has clearly been a lot of
thought put into this framework and I am looking forward to using
it in anger over the coming years.
Bjorn asked if I
/JulesGosnell/seqspert
The work is definitely portable to the Scala collection types, as they are
based on the Clojure implementations.
On Tuesday, 20 January 2015 19:04:45 UTC, Sam Halliday wrote:
Dear Akka Team,
In response to Bjorn's prompting[1], I have read all the Akka
Streams 1.0-M2
Is this something that would be suitable for an RFE?
More generally it would be good to have an option to only log userland
messages in remoting.
On Friday, 16 January 2015 17:41:55 UTC, Sam Halliday wrote:
Hi all,
I'm trying to debug a remoting issue and I need to look at the logs
Hi all,
I'm trying to debug a remoting issue and I need to look at the logs of the
messages that are sent.
However, the logs are completely filled up with the send/receive of
deathwatch messages.
Without turning off deathwatch, is there any way to exclude it from the
logs?
Latest akka
Hi all,
At the scalax talk on Monday, websocket support was noted to be the most
requested feature. I actually couldn't find a ticket for it... where should
I be `+1`ing?
e.g. for akka-io and akka-streams... but just for actor messages would also
be great.
Best regards, Sam
--
Read
Hi Patrick,
I'm guessing things have moved on since April when I first started this
thread.
Does the latest release of akka streams handle my example?
Best regards,
Sam
On Wednesday, 23 April 2014 10:01:30 UTC+1, Patrik Nordwall wrote:
On Tue, Apr 22, 2014 at 9:32 PM, Sam Halliday sam.ha
Thanks Patrik,
Well it sounds like everything is heading in the right direction, if
it is not already there yet. I'm very excited to see what will be in
the next milestone :-D
On 22 April 2014 12:08, Patrik Nordwall patrik.nordw...@gmail.com wrote:
On Mon, Apr 21, 2014 at 3:59 PM, Sam
Hi all,
I am very excited by akka streams -- it aims to solve a problem that I see
time and time again. Every time I post to this list it feels like the
solution is always wait until Akka Streams is released Finally, it is
here!
I intend to read the documentation fully, but I was a little
On Monday, 21 April 2014 12:32:57 UTC+1, Patrik Nordwall wrote:
I intend to read the documentation fully, but I was a little disappointed
that the activator examples did not have a simple example with an
(effectively) infinite data source that can only be polled in serial, with
parallel
Hi all,
Is there any concept of mutually exclusive actor paths?
What I mean by this is that
/user/exclusive/A
/user/exclusive/B
are mutually exclusive (where A may be a round robin router of many As)
between A and B.
This would enable concepts such as read/write actors where e.g. A could
On Friday, 21 February 2014 14:28:44 UTC, Patrik Nordwall wrote:
On Fri, Feb 21, 2014 at 2:50 PM, Sam Halliday
sam.ha...@gmail.comjavascript:
wrote:
Hi all,
Is there any concept of mutually exclusive actor paths?
No
You could build it within the exclusive actor, if you send all
On Friday, 21 February 2014 15:10:38 UTC, Patrik Nordwall wrote:
No locks. It would buffer incoming messages until they can be delegated.
/Patrik
21 feb 2014 kl. 15:47 skrev Sam Halliday sam.ha...@gmail.comjavascript:
:
Sorry, how to know when the children have finished is not the right
2014 kl. 15:47 skrev Sam Halliday sam.ha...@gmail.comjavascript:
:
Sorry, how to know when the children have finished is not the right
question. What I really mean is how can the exclusivity be enforced without
introducing a lock in the delegating actor in order to allow waiting until
.
On Friday, 21 February 2014 15:20:57 UTC, Alec Zorab wrote:
Surely it's just standard application logic? The parent enforces the
exclusivity just like any other application logic. What's the difficulty?
On 21 February 2014 14:47, Sam Halliday sam.ha...@gmail.com javascript:
wrote:
Sorry, how
without the need for lots
of messages going back and forth.
On Friday, 21 February 2014 15:48:32 UTC, Patrik Nordwall wrote:
On Fri, Feb 21, 2014 at 4:38 PM, Sam Halliday
sam.ha...@gmail.comjavascript:
wrote:
It's not difficult in the way that it has been proposed. But I would like
Hi all,
I'm constrained to Scala 2.9.2 and Akka 2.0.5 on my project and I am
confused how unhandled messages are intended to be logged.
It seems that in order to get any form of logging, the receive method must
use the LoggingReceive wrapper. This then shows handled and unhandled
messages in
63 matches
Mail list logo