Re: [akka-user][deprecated] [Akka 2.5.x][Remoting] - Recovering from guaranteed nodes

[Konrad “ktoso” Malawski]

Could I ask you to move the question to discuss.akka.io?
Thanks!

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On May 17, 2018 at 18:26:11, gutzeit (gutz...@gmail.com) wrote:

Dear list members,

My company runs a large scale deployment (hundreds of JVMs) based on Akka,
deployed in different regions globally, while some of the services are
communicating using Akka Remoting (TCP, not artery).
As it goes, global cloud deployments suffer from occasional disconnections
between different regions, total disconnections or severe packet loss. We
expect things to be shaky while network disruption happens, but we also
expect everything to go back to normal, when storm passes.

Observing the logs we see many instances of the following:

*Tried to associate with unreachable remote address
[akka.tcp://systemName b@192.168.236.12:2558
]. Address is now gated for 5000 ms, all
messages to this address will be delivered to dead letters. Reason:
[The remote system has quarantined this system. No further associations to
the remote system are possible until this system is restarted.]*

*AssociationError [akka.tcp://com-company-resource-sip@192.168.222.36:2558
] ->
[akka.tcp://systemName@192.168.236.11:2558
]: Error [Invalid address:
akka.tcp://M systemName@192.168.236.11:2558 ] [
akka.remote.InvalidAssociation: Invalid address:
akka.tcp://systemName@192.168.236.11:2558 
Caused by:
akka.remote.transport.Transport$InvalidAssociationException: The
remote system has quarantined this system.
No further associations to the remote system are possible until this system
is restarted. ]*

Reading Akka Remoting documentation, those errors mean that the two remote
actor system in question would never be able to communicate with each
other, unless the systems are restarted.

What is a proper expected way of recovering from those situations? It does
not sound logical to me that I need to restart all nodes of the system
every time network disconnection occurs, what am I missing here?

Thanks in advance for your replies.

Regards,
Dima Gutzeit

--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will soon be put into read-only mode, and replaced by
discuss.akka.io
** More details:
https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>>
>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user][deprecated] Caused by: com.typesafe.config.ConfigException$Missing: No configuration setting found for key 'enabled'

[Konrad “ktoso” Malawski]

It is likely related to your build or code, please share that.

Can we continue this on discuss.akka.io please though?
You have a better chance to get answers quickly there.


As noted in the header of this mailing list:
We announced
 a new
discussion forum, located here: https://discuss.akka.io
Please ask your new questions on the new forum, as we move over discussions
to it entirely.
We hope you'll enjoy the new forums, which will serve the same purpose as
akka-user has served so far.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On May 17, 2018 at 12:04:47, Saggie (sagarpati...@gmail.com) wrote:

I am trying get my cluster up and running on my localhost with below
configuration (application.conf).
But I am getting follwing error.

Caused by: com.typesafe.config.ConfigException$Missing: No configuration
setting found for key 'enabled'

I am pretty sure it finds the application.conffile as I confirmed that any
changes to file will cause to take effect in next run.
I keep wondering where is this 'enabled' config that I am missing in


application.conf:

Master {

akka {


  actor {
provider = "cluster"
  }
  remote {
maximum-payload-bytes = 3000 bytes
log-remote-lifecycle-events = off
netty.tcp {
  hostname = "127.0.0.1"
  port = 0
  message-frame-size =  3000b
  send-buffer-size =  3000b
  receive-buffer-size =  3000b
  maximum-frame-size = 3000b
}
  }


  cluster {
roles = ["Master"]
seed-nodes = [
  "akka.tcp://GyanClusterSystem@127.0.0.1:2556"]



# auto downing is NOT safe for production deployments.
# you may want to use it during development, read more about it in the
docs.
#
#auto-down-unreachable-after = 10s
  }
}
}


Worker {
akka {
  actor {
provider = "cluster"
  }
  remote {
maximum-payload-bytes = 3000 bytes
log-remote-lifecycle-events = off
netty.tcp {
  hostname = "127.0.0.1"
  port = 0
  message-frame-size =  3000b
  send-buffer-size =  3000b
  receive-buffer-size =  3000b
  maximum-frame-size = 3000b
}
  }


  cluster {
roles = ["Worker"]
seed-nodes = [
  "akka.tcp://GyanClusterSystem@127.0.0.1:2556"]



# auto downing is NOT safe for production deployments.
# you may want to use it during development, read more about it in the
docs.
#
   # auto-down-unreachable-after = 10s
  }
}
}



--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will soon be put into read-only mode, and replaced by
discuss.akka.io
** More details:
https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>>
>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user][deprecated] Akka Streams Resuming Materializer does not log exceptions

[Konrad “ktoso” Malawski]

Use the .log() operator.

Same as exceptions thrown in a Future do not automatically get logged.

There has been discussion about enabling this always, however you’d then be
swamped with errors which are recovered and actually “fine and nothing to
worry about”.

If you want logging, put a log() there.

PS: New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon. :-)

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On May 17, 2018 at 1:55:24, dol...@thoughtworks.com (dol...@thoughtworks.com)
wrote:

Hello all,

When I provide a resuming materializer to the stream, the exceptions that
occurred in the stream do not get logged. Is there any way to log these
exceptions ?

import akka.actor.ActorSystem
import akka.stream.scaladsl.Source
import akka.stream.{ActorMaterializer, ActorMaterializerSettings,
Materializer, Supervision}

import scala.concurrent.duration.DurationInt

object Demo extends App {

  private implicit val actorSystem: ActorSystem = ActorSystem()

  lazy val settings: ActorMaterializerSettings =

ActorMaterializerSettings(actorSystem).withSupervisionStrategy(Supervision.getResumingDecider)

  implicit lazy val resumingMat: Materializer = ActorMaterializer(settings)

  var counter = 0
  def eventGenerator(): Int = {
counter += 1
if (counter > 5) throw new RuntimeException("Could not create an event")
else 1
  }

  Source.tick(0.millis, 10.millis, ()).map(_ ⇒
eventGenerator()).runForeach(println)
}

--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will soon be put into read-only mode, and replaced by
discuss.akka.io
** More details:
https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>>
>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user][deprecated] How to generate the javadoc for offline use?

[Konrad “ktoso” Malawski]

Hi there,

It’s `sbt Dakka.genjavadoc.enabled=true doc` if I remember correctly.

I suggest you ask questions on the https://discuss.akka.io forum as that
one we monitor more actively nowadays (as mentioned in the footer and
header of the mailing list)

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On May 16, 2018 at 7:31:37, Thai (lgoptimusv...@gmail.com) wrote:

Hi All,

I check out the code from github and run the unidoc task in sbt, but it
creates the scala API. How can I create the java api?

Regards.
--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will soon be put into read-only mode, and replaced by
discuss.akka.io
** More details:
https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>>
>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user][deprecated] Akka streams doesnt run when integer range is large

[Konrad “ktoso” Malawski]

This was already answered on stackoverflow;
https://stackoverflow.com/questions/50264569/akka-streams-doesnt-run-when-integer-range-is-large

You likely terminate the app before the stream has time to print all things
— you have to wait for that to happen as mentioned on SO,
this is done by using the materialized CompletionStage

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On May 10, 2018 at 7:17:27, Jeffrey Phillips Freeman (fre...@gmail.com)
wrote:

I have some code and it works fine when i specify an integer range that is
about a 1000 integers wide but silently fails when is specify a range that
is 10,000 wide. Here is a SO link that describes the problem in detail:
https://stackoverflow.com/questions/50264569/akka-streams-doesnt-run-when-integer-range-is-large
--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will soon be put into read-only mode, and replaced by
discuss.akka.io
** More details:
https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>>
>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user][deprecated] Cluster state shows node status up even though node is down & unreachable

[Konrad “ktoso” Malawski]

No idea, I’d guess you have more insights into your envs than we here so
you should be able to dig into it more.
I also don’t quite get what “not works” means in this context.

PS: Consider moving to discuss.akka.io

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On April 23, 2018 at 10:00:11, Darshan Shah (dee@gmail.com) wrote:

I am using Cluster.get(context().system()).state() to get the state of the
cluster and it works perfectly in all environments except one.
On all environments where it works, nodes that are down show up in the
state.getUnreachable() set and not in state.getMembers().
However only in one environment where this doesn't work, nodes that are
down show up both in the state.getUnreachable() set and also in
state.getMembers().

Any pointers on what could be different in that one particular environment
causing this are highly appreciated.

Thanks.

--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will soon be put into read-only mode, and replaced by
discuss.akka.io
** More details:
https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>>
>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user][deprecated] Akka HTTP for microservice orchestration?

[Konrad “ktoso” Malawski]

Just to confirm

> Thanks for your confirmation. I thought that I read somewhere that Akka
Http was only intended for internal communication within actor-systems and
it should not be used directly...but obviously I was mistaken.

Perhaps it was talking about Akka *actor* messaging — which yes indeed, is
meant for “within a service” communication.
Akka HTTP absolutely is built for talking to other services or even
publicly exposing endpoints.



-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On April 13, 2018 at 13:54:21, Alan Burlison (alan.burli...@gmail.com)
wrote:

On 13/04/18 12:28, Marc Schlegel wrote:

> Thanks for your confirmation. I thought that I read somewhere that Akka
> Http was only intended for internal communication within actor-systems
and
> it should not be used directly...but obviously I was mistaken.

I don't believe so, I've used it to implement a fully-blown REST
endpoint for an application.

-- 
Alan Burlison
-- 

-- 
*

** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will soon be put into read-only mode, and replaced by
discuss.akka.io
** More details:
https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*

>>
>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user][deprecated] Re: Supervision: optimal use for retry logic and understanding logged error

[Konrad “ktoso” Malawski]

Thanks, let’s follow up there then :)

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On April 4, 2018 at 21:19:10, daz...@gmail.com (daz...@gmail.com) wrote:

have moved to the lightbend forum.

On Wednesday, 4 April 2018 12:39:22 UTC+1, daz...@gmail.com wrote:
>
> Hi,
>
> I am playing around with supervision in Java Akka 2.5.8 / 2.12.
>
> I would like to have the ability to decorate any old actor's behaviour
> with retry logic.
>
> I have the following:
> https://pastebin.com/3qV8kDfz
>
> A number of questions:
>
> 1) The exception thrown by the SupervisedActor is logged as an error:
>
> 11:43:00.542 [TestActorSystem-akka.actor.default-dispatcher-3] ERROR
> OneForOneStrategy - 
> nullcom.tesco.payments.async.TestSupervisionDocs$RestartMe:
> null
> at com.tesco.payments.async.TestSupervisionDocs$PrinterActor.lambda$
> createReceive$0(TestSupervisionDocs.java:66)
>
> It's not clear to me that I've done things correctly - what's the 'null'
> for?
>
> Also, is there a way to not have this logged as an error?
>
> 2) I had to use Backoff.onStop(...) rather than what seemed more intuitive
> Backoff.onFailure(...). Are there any issues I should be aware off with
> this?
>
> 3) In the SupervisedActor, I have overridden preRestart, which after a
> restart, sends the parent (supervisor) the failed message again, with the
> original sender.
>
> sending to self rather than supervisor didn't work, don't understand why?
>
> In any case is there a way to have the supervisor send the message again?
> Then the supervised actor would not need to be aware of its supervision nor
> know its parent is something special, nor contain part of the retry logic.
>
> One way I can think off is to have the thrown exception contain the
> message, supervised actor and original sender, and then have supervisor
> send it to itself:
>
> DeciderBuilder
> .match(RestartMe.class, e -> {
> System.out.println("RETRY caught--");
> e.self.tell(e.msg, e.sender);
> return restart();
> })
>
>
> However this still requires the SupervisedActor having some involvement in
> the process (throwing an exception with information specific to retry), and
> seems a bit ugly.
>
> Help / thoughts much appreciated!
> daz
>
--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will soon be put into read-only mode, and replaced by
discuss.akka.io
** More details:
https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>>
>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user][deprecated] Akka Http and consuming a response of "application/stream+json" type

[Konrad “ktoso” Malawski]

Hi Michael,
I assume your question is about how to get a Source[MyType] from such
streamed incoming entity?
The streaming and backpressure itself is “always on”, so the missing bit is
the marshalling — you are right we didn’t document it very well,
so I went ahead and added the docs:
https://github.com/akka/akka-http/pull/1964

Hope this helps! Let me know if I missed the point of the question; Please
feel free to review the above PR with docs as well of course.
Happy hakking

PS: New discussion forum is located at https://discuss.akka.io/ replacing
akka-user google-group soon, recommend asking over there next time.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On March 27, 2018 at 5:18:37, Michael Kohout (mwkoh...@gmail.com) wrote:

Hi All-

I'm writing an application that must consume from a HTTP endpoint that
publishes a streaming response(the source app is using project
reactor/spring webflux).

I don't see any docs in the Akka-HTTP project that seem to map to my use
case.  Does anyone know if it's possible to use akka http's Http class to
handle this response?

thanks
Mike
--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will soon be put into read-only mode, and replaced by
discuss.akka.io
** More details:
https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>>
>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user][deprecated] Akka remoting via kafka

[Konrad “ktoso” Malawski]

This has been cross-posted to
https://discuss.lightbend.com/t/akka-remoting-via-kafka/415/5 (and has
discussion there)

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On March 22, 2018 at 3:45:49, Vadim Bobrov (vadimbob...@gmail.com) wrote:

Hello,

I wonder if this question has already been asked (I couldn't find a direct
answer) - but would it be possible to use Kafka as a transport for akka
remoting? I mean is akka open for implementing alternative transports for
remoting and whether it makes sense in general

thanks
Vadim
--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will soon be put into read-only mode, and replaced by
discuss.akka.io
** More details:
https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>>
>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user][deprecated] Microservice Architecture in Akka

[Konrad “ktoso” Malawski]

Hi there,

May I suggest asking the question in the new https://discuss.akka.io
forums, as this mailing list is going to move into read-only mode soon?
(as documented in it’s header, email footers, and on
https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced)


> In case of write service this read Db need to be populated by event
streaming. So there will be multiple microservice , and they can
communicate between themselves (domain service) using json/protobuf -grpc .

We’ll soon be releasing an akka-grpc module which would help with this,
It’s not yet announced, but thought I’ll share this as a preview
information.

> Definitely it needs to be fault tolerant, As well I want to deploy in
kubernetes and will use kubernetes out box support for service discovery &
registry,load balancing ,autoscaling features .

That’s what the Akka Cluster does at it’s best.

But your question is really somewhat too generic to answer specifically
what to use where.
Usually a combination of those tools is used — so both.



PS: It is written Akka, not AKKA, please :-)



-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On March 16, 2018 at 4:01:27, Anish Kuti (anish.k...@gmail.com) wrote:

 I want to create microservice using akka (not using lagom framework) .
What is the best way to do ?


Requirement is as below

I want my channel layer to consume the API (REST using Json) . And these
API will call some legacy system to fetch the data . There can be multiple
layer of API like as “Digital experience microservice” will be calling
“process microservice” . “Digital experience microservice” will be
responsible for providing channel specific data . This process microservice
will be able to do some orchestration/choreography for fulling the process
by calling “Domain Microservice”. These Domain microservice Should be able
to fetch the data from Read/cache DB .
In case of write service this read Db need to be populated by event
streaming. So there will be multiple microservice , and they can
communicate between themselves (domain service) using json/protobuf -grpc .
Definitely it needs to be fault tolerant, As well I want to deploy in
kubernetes and will use kubernetes out box support for service discovery &
registry,load balancing ,autoscaling features .


Hope I am able to give clear picture on the requirement . Would appreciate
if you can suggest whether AKKA http or AKKA Cluster or AKKA HTTP+Cluster
is the better option in the given scenario ?
--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will soon be put into read-only mode, and replaced by
discuss.akka.io
** More details:
https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>>
>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user][deprecated] Akka persistence and internally stateless actors

[Konrad “ktoso” Malawski]

Hi Mark,

Notice: This mailing list is going to be made read-only shortly, please ask
new questions on the: https://discuss.akka.io forum (see footer of every
email in this group for details).

Akka Persistence is specifically designed for event-sourcing, and
persisting Actor state.
If you don’t do that, don’t use Akka Persistence, and simply perform your
database operations inside normal actors.

As for delivery guarantees — very sure that durable mailboxes only “seem
like” they would solve your problem, they would in fact cause more trouble
than help — which is why we deprecated and removed them years ago.

Instead the
https://doc.akka.io/docs/akka/current/persistence.html#at-least-once-delivery
at
least once delivery is what you would use to achieve at-least once or even
exactly once (if de-duplication is implemented on the receiving end). It
does use persistence to store the queue of pending messages to survive
crashes.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On March 15, 2018 at 2:03:01, Mark Kaberman (mkaber...@gmail.com) wrote:

I am adding Akka persistence to my existing application.  My actors are
stateless: actor's implementations have no properties. An actor receives
the message, analyzes it and either forwards it to another actor or
persists some data (in MongoDB or RDF store). Since actors have no state
there is nothing to persist. What I really need is durable mailboxes, but
they are deprecated in favor of persistent actors. I am wondering how
persistent actor pattern cold be applied to and actor implementation which
is essentially a dispatcher and the only goal is not to lose the messages
in case of actor system, JVM or host crash.


--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will soon be put into read-only mode, and replaced by
discuss.akka.io
** More details:
https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>>
>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>> 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Announcing discuss.akka.io!

[Konrad 'ktoso'; Malawski]

Dear hakkers,


We’re pleased to announce a new way to communicate with the core team and 
communities around the Akka projects (including Akka HTTP, Alpakka the 
various persistence plugins and all other community projects), as well as 
downstream projects such as Play and Lagom: discuss.akka.io 

The “Discuss Akka” forum is co-hosted under the discuss.lightbend.com 
domain, along with discuss.playframework.com and 
discuss.lagomframework.com, and aims to help those communities be closer to 
one another. Each of the discuss.* domains, directs you to the category 
that the domain mentions, so you can go directly to discuss Akka things by 
using the *discuss.akka.io * domain, without 
having to navigate the “big” forum.

This is something we’ve been working towards since many years, moving the 
Play Framework’s backend to Akka HTTP, and collaborating more and more 
closely between the teams and communities. We hope that this move will 
further help connect those communities, and see those tools as colleagues 
with different use cases, as in fact they’ve always been positioned as -- 
Akka being a low level toolkit, and Play and Lagom providing high level 
building blocks for websites, or microservices with more guidance.

To further explain what’s going to happen next to the other communication 
channels, and what their intended use is:

What about the gitter channels?

The gitter channels (akka/akka  for discussing 
“using Akka”, and akka/dev  for “developing 
Akka”) remain as-is. As do the various other chats about technologies 
around Akka. We find those chats tremendously valuable in connecting with 
the community in a more “chatty” and real-time fashion.

Over the years of using Gitter however, we noticed that its ease-of-use 
(especially for beginners, new to the community) is a double edged-sword: 
we noticed many multiple-paragraph questions with code snippets be pasted 
into the gitter chats, and if no answer was received, the same question 
would be posted again and again. Other questions which require more 
in-depth writeups and thinking also “get lost in the chat”, and thus such 
users did not get the best experience, which they could have gotten on the 
mailing list -- if only they got there.

To help remedy this issue, we want to increase accessibility to a proper 
discussion forum, where long questions as well as design debates have 
enough place to breathe, and not get lost in other chatter. Thus, 
introducing the new discussion forums at discuss.akka.io 

What happens to the akka-user mailing list?

The mailing list, whom people following Akka since it’s early days surely 
have learnt to love, even with its numerous flaws, will be transitioned 
into a read-only mode. This will not happen immediately, however we’ll try 
to direct all new questions to the new forum, and eventually flip the 
switch to mark akka-user as an read-only archive.

We took this decision after much thought, debate and considering the 
various up and down sides of handling it very seriously. We know that a 
mailing list work-flow is very precious for people used to working with 
them (plenty of us including), however in order to grow the community as a 
whole, and also help making the discussions on such forum more searchable 
and accessible, we decided that this move will be beneficial for everyone 
involved. 

If you enjoy working with mailing-lists, and would like to continue to do 
so with the new forums, please have a look at the hints in the Discuss Meta 
 topics, where we prepared hints on 
how to set up the notifications to work as-if a mailing list 

.

Forums are complementary to StackOverflow

Since the question about "why not 'just' move to stack overflow?" is likely 
to come up every now and then, we'd like to address it right away, as we 
make our move from the mailing list to the new forums:

We greatly value the StackOverflow community and think it's a great place 
for what it's been designed for – Q/A style questions. Often times however, 
questions about Akka tend to require some more discussion and understanding 
the architecture where the person asking is applying the technology. This 
discussion style is able to yield more useful advice, even if the opening 
question is vague or perhaps by itself is not really a question but 
discussion topic to begin with. Such discussions do not fit the 
StackOverflow model very well, which is why we see the discuss forums 
*complementary* to the StackOverflow questions, which also have their own 
tremendous value.

Please keep using the #akka  tag and 
answering questions on stack overflow as you always have been, thank you!

What if I want ASAP 24h/7d responses?

Nothing changes in this aspect. The public communication chann

Re: [akka-user] Akka-Streams and Android

[Konrad “ktoso” Malawski]

Sorry, it’s been years since I’ve done Android development…
Maybe someone else on the list will have insights or ideas where better to
ask

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On March 8, 2018 at 1:58:29, 'Matt' via Akka User List (
akka-user@googlegroups.com) wrote:

Ah, thanks. That's good to know, too bad.

I was thinking about playing around with reactive streams and MVI
(Modell-View-Intent). I tried RxScala with RxJava2 and RxAndroid before but
I wasn't very successful. So, I thought I give akka-streams a try. Any
ideas on how to do MVI with Scala on Android?



Am Mittwoch, 7. März 2018 17:48:02 UTC+1 schrieb Konrad Malawski:
>
> Akka requires JDK8, which Android is not AFAIR… they support Java8 syntax
> nowadays but not JDK8 bytecode right?
>
> You could use ancient versions of Akka which would run on JDK6 bytecode,
> but that’s strongly discouraged.
>
> --
> Cheers,
> Konrad 'ktoso ' Malawski
> Akka  @ Lightbend 
>
> On March 8, 2018 at 1:29:05, 'Matt' via Akka User List (
> akka...@googlegroups.com) wrote:
>
> Hi there,
>
> I wonder if akka-streams are working on Android. I tried to get it working
> but there are tons of warnings and notes on the proguard step. I also did
> some proguard rules but still the estimated method count is >64K (81864);
> Akka-Streams 23684 alone. Is there a chance to make it work or do I just
> wasting my time? Does anyone tried it?
>
> Cheers,
> Matt
> --
> >> 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 https://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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] import context.dispatcher nullpointerexception

[Konrad “ktoso” Malawski]

Yes it is nulled using unsafe.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On March 8, 2018 at 7:32:56, Heiko Seeberger (loe...@posteo.de) wrote:

`import context.dispatcher` is what „everybody“ is doing, not? I’m using it
all over the place, because I have learned that one can import from stable
identifiers (e.g. vals) in Scala. Hence I don’t think changing the docs has
the necessary effect.

How can a final val be „nulled"? Unsafe? Reflection?

Cheers
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de
Twitter: @hseeberger
Public key: keybase.io/hseeberger




Am 07.03.2018 um 19:23 schrieb Patrik Nordwall :

Thanks!

On Wed, Mar 7, 2018 at 6:16 PM, Jeff  wrote:

> An example of documentation for using import context.dispatcher is here
> https://doc.akka.io/docs/akka/2.5/futures.html#within-actors
>
> I can create some PR to update the documentation
>
> On Wednesday, March 7, 2018 at 6:09:24 AM UTC-8, Patrik Nordwall wrote:
>>
>> It's because when the actor is stopped some of the fields are cleared
>> (yeah, even though they are vals) to "help" the GC in case something (e.g.
>> an local ActorRef) is still referencing the actor instance.
>>
>> implicit val ec = context.dispatcher
>>
>> would solve it here.
>>
>> Where in the documentation is the import recommended? We should probably
>> update that. Would you be able creating a PR fixing it? Thanks.
>>
>> /Patrik
>>
>> On Tue, Mar 6, 2018 at 10:44 PM, Jeff  wrote:
>>
>>> I suspected as much. So what would you suggest as for handling use cases
>>> where you could have chained flatmaps on futures that at the end will
>>> pipeTo a message back to the actor. Should we set the ExecutionContext to a
>>> val?
>>>
>>> On Tuesday, March 6, 2018 at 12:09:22 PM UTC-8, √ wrote:

 Context is bound to the lifecycle of the actor.

 On Tue, Mar 6, 2018 at 8:37 PM, Jeff  wrote:

> I have noticed an issue where if a future maps/flatmaps after actor
> shutdown, a NullPointerException is thrown. I've narrowed it down to
> the import context.dispatcher, which I technically understand since
> that is closing over actor state. If I change that to implicit val ec
> = context.dispatcher, everything works fine.
>
> I'd like to understand what is the best practice in this case, since
> the documentation for context.dispatcher indicates that it is
> threadsafe and looking at the actor trait, context is a val. Most
> documentation seems to indicate that import context.dispatcher is
> preferred.
>
> Thanks
> Jeff
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



 --
 Cheers,
 √

>>>
>>> --
>>> >> 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 https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>>
>> Patrik Nordwall
>> Akka Tech Lead
>> Lightbend  -  Reactive apps on the JVM
>> Twitter: @patriknw
>>
>>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



--

Patrik Nordwall
Akka Tech Lead
Lightbend  -  Reactive apps on the JVM
Twitter: @patriknw


--
>> Read

Re: [akka-user] Akka-Streams and Android

[Konrad “ktoso” Malawski]

Akka requires JDK8, which Android is not AFAIR… they support Java8 syntax
nowadays but not JDK8 bytecode right?

You could use ancient versions of Akka which would run on JDK6 bytecode,
but that’s strongly discouraged.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On March 8, 2018 at 1:29:05, 'Matt' via Akka User List (
akka-user@googlegroups.com) wrote:

Hi there,

I wonder if akka-streams are working on Android. I tried to get it working
but there are tons of warnings and notes on the proguard step. I also did
some proguard rules but still the estimated method count is >64K (81864);
Akka-Streams 23684 alone. Is there a chance to make it work or do I just
wasting my time? Does anyone tried it?

Cheers,
Matt
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Getting the HTTP server's bound port seems to be impossible?

[Konrad “ktoso” Malawski]

Could I ask you to open a ticket requesting that on
https://github.com/akka/akka ?
Thanks

-- 
Cheers,
Konrad 'ktoso <http://kto.so>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On March 8, 2018 at 0:21:58, Alan Burlison (alan.burli...@gmail.com) wrote:

On 07/03/18 01:11, Konrad “ktoso” Malawski wrote:

> The difference is in the binding call you can do, there’s a few styles,
yet
> each gives back a binding, which contains an address:
>
> val bindingFuture = Http().bindAndHandle(routes, interface =
> "0.0.0.0", port = 8080)
> bindingFuture.foreach { binding ⇒
> println(s"Server online at ${binding.localAddress}")
> }

Ahah, that's what I was looking for, thanks - I wasn't clear how to go
from the value returned from bindAndHandle to the bind port - I'd
assumed doing something like the above would block on the future. Adding
that to the docs would be useful...

On a related note, I found a very helpful code snippet which shows how
to provide an Akka-HTTP marshaller to go from/to protobuf in the routing
DSL. As protobuf is commonly used with Akka it would be useful if the
code in the bug report could be added to the Akka docks as a marshalling
example.

https://github.com/scalapb/ScalaPB/issues/247

-- 
Alan Burlison
--

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Getting the HTTP server's bound port seems to be impossible?

[Konrad “ktoso” Malawski]

What do you mean?
Binding is not any different if you use high / low level DSLs (that’s the
routing DSL vs. just matching incoming objects).

The difference is in the binding call you can do, there’s a few styles, yet
each gives back a binding, which contains an address:

val bindingFuture = Http().bindAndHandle(routes, interface =
"0.0.0.0", port = 8080)
bindingFuture.foreach { binding ⇒
  println(s"Server online at ${binding.localAddress}")
}


val source = Http().bind(interface = "0.0.0.0", port = 8080)
val bindingFuture2 = source.to(Sink.foreach {
  conn ⇒ conn.handleWith(routes)
}).run()
bindingFuture2.foreach { binding ⇒
  println(s"Server online at ${binding.localAddress}")
}


-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On March 7, 2018 at 4:20:39, Alan Burlison (alan.burli...@gmail.com) wrote:

The Akka HTTP documentation [1] says:

"The Http.ServerBinding also provides a way to get a hold of the actual
local address of the bound socket, which is useful for example when
binding to port zero (and thus letting the OS pick an available port)."

The scenario is I'm using a localhost http service which needs to be on
a system-assigned localhost port to communicate with subprocesses and I
need to find out which port the server is bound to. Despite what the
documentation says I can find no way of doing this before starting to
accept incoming connections, and no way of doing it using the high-level
routing DSL.

[1]
https://doc.akka.io/docs/akka-http/current/server-side/low-level-api.html#starting-and-stopping

-- 
Alan Burlison
-- 

-- 
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: Aw: [akka-user] Akka 2.5.11 - materialization of Flow.lazyInit

[Konrad “ktoso” Malawski]

To reply about:

> I think the two methods Source.lazily and Flow.lazyInit should be
alligned (in their name and in their materialized values)

No, those are different things and should not be name-aligned. The lazyInit
wording is used to talk about “on first element”,
while we use the lazily to mean like Scala’s lazy “on first touching it”.
Hope this clarifies that difference.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On March 5, 2018 at 21:31:59, Stefan Wachter (stefan.wach...@gmx.de) wrote:

I just saw that Source.lazily implements a similar concept:

def lazily[T, M](create: () ⇒ Source[T , M]): Source[T, Future[M]]

Here a the materialized value is a Future that is failed if there was no
demand before the source gets never created.

I think the two methods Source.lazily and Flow.lazyInit should be alligned
(in their name and in their materialized values)

*Gesendet:* Montag, 05. März 2018 um 13:13 Uhr
*Von:* "Stefan Wachter" 
*An:* akka-user@googlegroups.com
*Betreff:* [akka-user] Akka 2.5.11 - materialization of Flow.lazyInit

Hi,

studying the newly Flow constructor Flow.lazyInit



def lazyInit[I, O, M](flowFactory: I ⇒ Future[Flow[I, O, M]],
fallback: () ⇒ M): Flow[I, O, M]



(cf. https://doc.akka.io/api/akka/2.5.11/akka/stream/scaladsl/Flow$.html) I
wondered how (citation from ScalaDoc)



The materialized value of the `Flow` will be the materializedvalue of
the created internal flow.



could be? Materialization happens before the flow is run. Therefore the
materialized value cannot depend on whether their will be some input or not.

To fix the issue, the materialzed value of Flow.lazyInit should be a
Future[M] or even better a Future[Option[M]]. In case that no internal flow
is materialized it would be a Future[None].

--Stefan


--
>> 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 https://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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: Aw: [akka-user] Akka 2.5.11 - materialization of Flow.lazyInit

[Konrad “ktoso” Malawski]

Whoa (!), thanks for the great catch.

You are absolutely right that the Flow.lazyInit is incorrect.
It is not possible to get the M strictly from the Future[M] after all.

I skimmed tests and they seem to not verify this;
The Sink version is fine, so at least that.

Could you log a bug about this in https://github.com/akka/akka ?
If you want you can also try fixing it, it should materialize a Future[M].


Thanks again, great catch

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On March 5, 2018 at 21:31:59, Stefan Wachter (stefan.wach...@gmx.de) wrote:

I just saw that Source.lazily implements a similar concept:

def lazily[T, M](create: () ⇒ Source[T , M]): Source[T, Future[M]]

Here a the materialized value is a Future that is failed if there was no
demand before the source gets never created.

I think the two methods Source.lazily and Flow.lazyInit should be alligned
(in their name and in their materialized values)

*Gesendet:* Montag, 05. März 2018 um 13:13 Uhr
*Von:* "Stefan Wachter" 
*An:* akka-user@googlegroups.com
*Betreff:* [akka-user] Akka 2.5.11 - materialization of Flow.lazyInit

Hi,

studying the newly Flow constructor Flow.lazyInit



def lazyInit[I, O, M](flowFactory: I ⇒ Future[Flow[I, O, M]],
fallback: () ⇒ M): Flow[I, O, M]



(cf. https://doc.akka.io/api/akka/2.5.11/akka/stream/scaladsl/Flow$.html) I
wondered how (citation from ScalaDoc)



The materialized value of the `Flow` will be the materializedvalue of
the created internal flow.



could be? Materialization happens before the flow is run. Therefore the
materialized value cannot depend on whether their will be some input or not.

To fix the issue, the materialzed value of Flow.lazyInit should be a
Future[M] or even better a Future[Option[M]]. In case that no internal flow
is materialized it would be a Future[None].

--Stefan


--
>> 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 https://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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Artery remoting seems to be endian-dependent

[Konrad “ktoso” Malawski]

Ping in one place is enough, reopened :-)

-- 
Cheers,
Konrad 'ktoso <http://kto.so>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On March 1, 2018 at 19:54:20, Alan Burlison (alan.burli...@gmail.com) wrote:

On 01/03/18 10:44, Konrad “ktoso” Malawski wrote:

> Thanks, I’ll close the one I had opened then

Umm, no - there are two separate issues here, the alignment bug in the
FlightRecorder (24639) AND the bug in Aeron (24636). Can you reopen
24636 please?

-- 
Alan Burlison
--

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Artery remoting seems to be endian-dependent

[Konrad “ktoso” Malawski]

Thanks, I’ll close the one I had opened then

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On March 1, 2018 at 19:43:23, Alan Burlison (alan.burli...@gmail.com) wrote:

Submitted as https://github.com/akka/akka/issues/24639

-- 
Alan Burlison
--

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Artery remoting seems to be endian-dependent

[Konrad “ktoso” Malawski]

Here’s the ticket: https://github.com/akka/akka/issues/24636

I did not find your github handle, please comment or sub the issue if you
want to track it there.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On March 1, 2018 at 3:37:06, Alan Burlison (alan.burli...@gmail.com) wrote:


OK, here's the story. With artery.transport = tcp, the app works, with
it set to aeron-udp it doesn't. Even with debugging enabled, there is
very little information output because the failure happens very early on:

[INFO] [02/28/2018 18:18:20.218 ] [main]
[akka.remote.artery.aeron.ArteryAeronUdpTransport(akka://Remoting)]
Started embedded media driver in directory
[/var/tmp/aeron-alanbur-Remoting-01f9e630-bc42-441c-a90b-ab0300afaa7c]
[DEBUG] [02/28/2018 18:18:20.256 ]
[Remoting-akka.actor.default-dispatcher-6] [akka://Remoting/system] now
supervising Actor[akka://Remoting/system/StreamSupervisor-0#1924858877]
[DEBUG] [02/28/2018 18:18:20.257 ]
[Remoting-akka.remote.default-remote-dispatcher-7]
[akka://Remoting/system/StreamSupervisor-0] started
(akka.stream.impl.StreamSupervisor@4485c04a)
[DEBUG] [02/28/2018 18:18:20.257 ]
[Remoting-akka.actor.default-dispatcher-6] [akka://Remoting/system] now
supervising Actor[akka://Remoting/system/StreamSupervisor-1#-1116171559]
[DEBUG] [02/28/2018 18:18:20.257 ]
[Remoting-akka.remote.default-remote-dispatcher-7]
[akka://Remoting/system/StreamSupervisor-1] started
(akka.stream.impl.StreamSupervisor@3bb60524)
Failed to parse config file No response from MediaDriver within
(ns):200 
[DEBUG] [02/28/2018 18:18:40.357 ]
[Remoting-akka.actor.default-dispatcher-3] [akka://Remoting/user] stopped

Most likely cause is endian and/or alignment bugs in the code that
accesses the shared memory segment between the Aeron client code and the
Media Driver:

https://github.com/real-logic/aeron/wiki/Media-Driver-Operation

"The mediadriver and the API/stack communicate via a set of shared
memory buffers."

https://github.com/real-logic/aeron/wiki/Protocol-Specification

"Byte ordering of fields of length 16-bits and larger use Little Endian.
This is for pure efficiency on performance sensitive platforms."

Looking at the Aeron source there are lots of mentions of endianness in
there, but also things like this:

// TODO: need to byte order to LITTLE_ENDIAN

which suggests that the code isn't properly endian-independent yet. My
suspicion therefore is that the bug is in Aeron rather than Artery, so
I'd appreciate some guidance on how to progress the 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Artery remoting seems to be endian-dependent

[Konrad “ktoso” Malawski]

Thanks for the detective work Alan!
Seems quite likely you’re right then.

I’ll copy your findings to a gihub issue and point Aeron fellows towards it
if they’re aware of it.

Thanks again, hope the TCP one will be fine for you for now in any case?

-- 
Cheers,
Konrad 'ktoso <http://kto.so>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On March 1, 2018 at 3:37:06, Alan Burlison (alan.burli...@gmail.com) wrote:

On 27/02/18 09:43, Konrad “ktoso” Malawski wrote:

> Thanks Alan,
> please do report back here or as a ticket on github.com/akka/akka :)
> Thanks for helping harden artery!

OK, here's the story. With artery.transport = tcp, the app works, with
it set to aeron-udp it doesn't. Even with debugging enabled, there is
very little information output because the failure happens very early on:

[INFO] [02/28/2018 18:18:20.218] [main]
[akka.remote.artery.aeron.ArteryAeronUdpTransport(akka://Remoting)]
Started embedded media driver in directory
[/var/tmp/aeron-alanbur-Remoting-01f9e630-bc42-441c-a90b-ab0300afaa7c]
[DEBUG] [02/28/2018 18:18:20.256]
[Remoting-akka.actor.default-dispatcher-6] [akka://Remoting/system] now
supervising Actor[akka://Remoting/system/StreamSupervisor-0#1924858877]
[DEBUG] [02/28/2018 18:18:20.257]
[Remoting-akka.remote.default-remote-dispatcher-7]
[akka://Remoting/system/StreamSupervisor-0] started
(akka.stream.impl.StreamSupervisor@4485c04a)
[DEBUG] [02/28/2018 18:18:20.257]
[Remoting-akka.actor.default-dispatcher-6] [akka://Remoting/system] now
supervising Actor[akka://Remoting/system/StreamSupervisor-1#-1116171559]
[DEBUG] [02/28/2018 18:18:20.257]
[Remoting-akka.remote.default-remote-dispatcher-7]
[akka://Remoting/system/StreamSupervisor-1] started
(akka.stream.impl.StreamSupervisor@3bb60524)
Failed to parse config file No response from MediaDriver within
(ns):200
[DEBUG] [02/28/2018 18:18:40.357]
[Remoting-akka.actor.default-dispatcher-3] [akka://Remoting/user] stopped

Most likely cause is endian and/or alignment bugs in the code that
accesses the shared memory segment between the Aeron client code and the
Media Driver:

https://github.com/real-logic/aeron/wiki/Media-Driver-Operation

"The mediadriver and the API/stack communicate via a set of shared
memory buffers."

https://github.com/real-logic/aeron/wiki/Protocol-Specification

"Byte ordering of fields of length 16-bits and larger use Little Endian.
This is for pure efficiency on performance sensitive platforms."

Looking at the Aeron source there are lots of mentions of endianness in
there, but also things like this:

// TODO: need to byte order to LITTLE_ENDIAN

which suggests that the code isn't properly endian-independent yet. My
suspicion therefore is that the bug is in Aeron rather than Artery, so
I'd appreciate some guidance on how to progress the issue.

Thanks,

-- 
Alan Burlison
--

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Artery remoting seems to be endian-dependent

[Konrad “ktoso” Malawski]

Thanks Alan,
please do report back here or as a ticket on github.com/akka/akka :)
Thanks for helping harden artery!



-- 
Cheers,
Konrad 'ktoso <http://kto.so>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On February 27, 2018 at 18:40:57, Alan Burlison (alan.burli...@gmail.com)
wrote:

On 27/02/18 06:32, Konrad “ktoso” Malawski wrote:

> I’d expect some failures to be logged if your guess is correct, nothing
in
> the logs?

There's a message about the connect to the other node timing out, but no
other detail - hence the question :-)

> Thanks for reporting, it could be a bug somewhere.

I'll try with the debug options you suggest and see if it sheds any more
light - thanks for the pointers.

-- 
Alan Burlison
--

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Artery remoting seems to be endian-dependent

[Konrad “ktoso” Malawski]

I’d expect some failures to be logged if your guess is correct, nothing in
the logs?

You can start with setting akka.loglevel = DEBUG

There’s more things like making sure
akka.remote.log-remote-lifecycle-events = on
but debug should really contain all we need (esp since expecting warnings
or failures).

There’s also

# If this is "on", Akka will log all inbound messages at DEBUG level,
# if off then they are not logged
akka.remote.log-received-messages = off

# If this is "on", Akka will log all outbound messages at DEBUG level,
# if off then they are not logged
akka.remote.log-sent-messages = off


To see if messages are indeed sent or arrive as expected.

Thanks for reporting, it could be a bug somewhere.


-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 27, 2018 at 3:02:56, Alan Burlison (alan.burli...@gmail.com)
wrote:

I'm running an Akka remoting 'hello world' app using Artery remoting,
it works fine on both Linux and Solaris x86 but doesn't work at all on
Solaris SPARC, my best guess is that either Artery or Aeron contains
some endian-dependent code. I'll log a bug but I'd like to confirm
where the problem lies first - are there any HOWTOs of how to debug
Artery?

Thanks,

-- 
Alan Burlison
-- 

-- 
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka actoreRef with macWire DI, actoreRef is not set

[Konrad “ktoso” Malawski]

This is not a 24h/7d support channel, wait a bit ;-)
Thanks.

-- 
Cheers,
Konrad 'ktoso <http://kto.so>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On February 23, 2018 at 17:34:30, Kanwaljeet Singh (ksachd...@gmail.com)
wrote:

Any pointers Konrad?

On Thu, Feb 22, 2018, 11:59 PM Kanwaljeet Singh  wrote:

> In my current code u feel that it is cyclic dependency because you see
> actor1 having access to failedService bean and actor2. But in reality, I
> can just remove actor2 being injected into actor1 if I can get away by
> using failedservice bean. Even if I do that, things remain the same. I have
> my Actor1 as below now(and I think no cyclic depenency now). I still hit
> the issue
>
> class Actor1(failedService: FailedService) extends Actor{
>
>
>   override def receive: Receive = {
> case TriggerActor1() =>
>   println("Actor1 triggered from REST controller. Send msg to actor 2")
>   failedService.testSend()
>   //actor2 ! Msg1()
> case Msg2() => println("got msg2 from actor 1")
>   }
>
>
> On Thu, Feb 22, 2018 at 11:57 PM Konrad “ktoso” Malawski <
> konrad.malaw...@lightbend.com> wrote:
>
>> It is a macwire thing ;-)
>> It hides you made a cyclic dependency.
>>
>> how would you make this work, plain java/scala:
>>
>> val a = new A(requires B!)
>> val b = new B(a /*requires A*/)
>> Hm, A has an issue...
>>
>> val b = new B(requires B)
>> val a = new A(b /*requires B!*/)
>> Hmm, B can’t get A…
>>
>> As simple as that.
>> Don’t do cyclic dependencies like that.
>>
>> you can create both and do a `a ! HelloIAm(b)` or something similar.
>>
>> --
>> Cheers,
>> Konrad 'ktoso <http://kto.so>' Malawski
>> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>>
>> On February 23, 2018 at 16:51:48, Kanwaljeet Singh (ksachd...@gmail.com)
>> wrote:
>>
>> here is my code
>>
>> class Actor1(failedService: FailedService, actor2: ActorRef @@ Actor2) 
>> extends Actor{
>>   override def receive: Receive = {
>> case TriggerActor1() =>
>>   println("Actor1 triggered from REST controller. Send msg to actor 2")
>>   failedService.testSend()
>>   //actor2 ! Msg1()
>> case Msg2() => println("got msg2 from actor 1")
>>   }
>>
>>
>>
>> class Actor2 extends Actor {
>>   override def receive: Receive = {
>> case Msg1() => {
>>   println("send without future")
>>   val origsender = sender()
>>   origsender ! Msg2()
>> }
>>   }
>>
>>
>> class FailedService(actor2: ActorRef@@Actor2) {
>>   def testSend() = {
>> actor2 ! Msg1()
>>   }
>> }
>>
>>
>> With my current code as shared above, Actor1 is able to send Msg1 to Actor2
>>
>> and actor2 responds with Msg2 but Msg2 goes to deadletter. I get the below 
>> error
>>
>> akka.actor.DeadLetterActorRef - Message [backup.failedakka.Msg2] from 
>> Actor[akka://application/user/actor2#-662746578] to 
>> Actor[akka://application/deadLetters] was not delivered. [1] dead letters 
>> encountered.
>>
>>
>> However, if insted of using the line "failedService.testSend()" in my 
>> Actor1, I uncomment the line below it
>>
>> and use that to communicate, things work fine.
>>
>> Is the Q clear now? I am injecting dependencies with MacWire
>>
>> On Thu, Feb 22, 2018 at 11:07 PM Kanwaljeet Singh 
>> wrote:
>>
>>> this is nto a macwire question I think.
>>>
>>> On Thu, Feb 22, 2018 at 11:06 PM Konrad “ktoso” Malawski <
>>> konrad.malaw...@lightbend.com> wrote:
>>>
>>>> I don’t understand what’s going where or how ;-)
>>>> Could you share code?
>>>>
>>>> Also, isn’t this a macwire question? Better to ask on
>>>> https://github.com/adamw/macwire/issues ?
>>>>
>>>> --
>>>> Cheers,
>>>> Konrad 'ktoso <http://kto.so>' Malawski
>>>> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>>>>
>>>> On February 23, 2018 at 16:05:22, ksachd...@gmail.com (
>>>> ksachd...@gmail.com) wrote:
>>>>
>>>>
>>>>1.
>>>>
>>>>Scenario 1 - Working scenario
>>>>- Actor1 -->MyMsg1-->Actor2
>>>>   - Actor2 MyMsgHandler - Processe

Re: [akka-user] Akka actoreRef with macWire DI, actoreRef is not set

[Konrad “ktoso” Malawski]

It is a macwire thing ;-)
It hides you made a cyclic dependency.

how would you make this work, plain java/scala:

val a = new A(requires B!)
val b = new B(a /*requires A*/)
Hm, A has an issue...

val b = new B(requires B)
val a = new A(b /*requires B!*/)
Hmm, B can’t get A…

As simple as that.
Don’t do cyclic dependencies like that.

you can create both and do a `a ! HelloIAm(b)` or something similar.

-- 
Cheers,
Konrad 'ktoso <http://kto.so>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On February 23, 2018 at 16:51:48, Kanwaljeet Singh (ksachd...@gmail.com)
wrote:

here is my code

class Actor1(failedService: FailedService, actor2: ActorRef @@ Actor2)
extends Actor{
  override def receive: Receive = {
case TriggerActor1() =>
  println("Actor1 triggered from REST controller. Send msg to actor 2")
  failedService.testSend()
  //actor2 ! Msg1()
case Msg2() => println("got msg2 from actor 1")
  }



class Actor2 extends Actor {
  override def receive: Receive = {
case Msg1() => {
  println("send without future")
  val origsender = sender()
  origsender ! Msg2()
}
  }


class FailedService(actor2: ActorRef@@Actor2) {
  def testSend() = {
actor2 ! Msg1()
  }
}


With my current code as shared above, Actor1 is able to send Msg1 to Actor2

and actor2 responds with Msg2 but Msg2 goes to deadletter. I get the below error

akka.actor.DeadLetterActorRef - Message [backup.failedakka.Msg2] from
Actor[akka://application/user/actor2#-662746578] to
Actor[akka://application/deadLetters] was not delivered. [1] dead
letters encountered.


However, if insted of using the line "failedService.testSend()" in my
Actor1, I uncomment the line below it

and use that to communicate, things work fine.

Is the Q clear now? I am injecting dependencies with MacWire

On Thu, Feb 22, 2018 at 11:07 PM Kanwaljeet Singh 
wrote:

> this is nto a macwire question I think.
>
> On Thu, Feb 22, 2018 at 11:06 PM Konrad “ktoso” Malawski <
> konrad.malaw...@lightbend.com> wrote:
>
>> I don’t understand what’s going where or how ;-)
>> Could you share code?
>>
>> Also, isn’t this a macwire question? Better to ask on
>> https://github.com/adamw/macwire/issues ?
>>
>> --
>> Cheers,
>> Konrad 'ktoso <http://kto.so>' Malawski
>> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>>
>> On February 23, 2018 at 16:05:22, ksachd...@gmail.com (
>> ksachd...@gmail.com) wrote:
>>
>>
>>1.
>>
>>Scenario 1 - Working scenario
>>- Actor1 -->MyMsg1-->Actor2
>>   - Actor2 MyMsgHandler - Processes message(with Future), does
>>   pipeTo to sender with MyMsg2. Works fine, Actor1 recvs MyMsg2
>>
>>
>>
>>1.
>>
>>Scenario2 - Failing scenario
>>- Actor1 has a bean injected via MacWire - myBean.
>>   - myBean has Actor2 injected as a bean and sends MyMsg1 to Actor2
>>   - Actor2 MyMsgHandler processes message(with Future), does pipeTo
>>   to sender and tries sending MyMsg2 - Goes to deadLetter. The actor
>>   Ref for sender is never set.
>>
>> How do I fix scenario2?
>>
>> --
>> >>>>>>>>>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka actoreRef with macWire DI, actoreRef is not set

[Konrad “ktoso” Malawski]

The other questions still stand, please make yourself understandable if you
need help :)

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 23, 2018 at 16:05:22, ksachd...@gmail.com (ksachd...@gmail.com)
wrote:


   1.

   Scenario 1 - Working scenario
   - Actor1 -->MyMsg1-->Actor2
  - Actor2 MyMsgHandler - Processes message(with Future), does pipeTo
  to sender with MyMsg2. Works fine, Actor1 recvs MyMsg2



   1.

   Scenario2 - Failing scenario
   - Actor1 has a bean injected via MacWire - myBean.
  - myBean has Actor2 injected as a bean and sends MyMsg1 to Actor2
  - Actor2 MyMsgHandler processes message(with Future), does pipeTo to
  sender and tries sending MyMsg2 - Goes to deadLetter. The actor Ref
  for sender is never set.

How do I fix scenario2?
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka actoreRef with macWire DI, actoreRef is not set

[Konrad “ktoso” Malawski]

I don’t understand what’s going where or how ;-)
Could you share code?

Also, isn’t this a macwire question? Better to ask on
https://github.com/adamw/macwire/issues ?

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 23, 2018 at 16:05:22, ksachd...@gmail.com (ksachd...@gmail.com)
wrote:


   1.

   Scenario 1 - Working scenario
   - Actor1 -->MyMsg1-->Actor2
  - Actor2 MyMsgHandler - Processes message(with Future), does pipeTo
  to sender with MyMsg2. Works fine, Actor1 recvs MyMsg2



   1.

   Scenario2 - Failing scenario
   - Actor1 has a bean injected via MacWire - myBean.
  - myBean has Actor2 injected as a bean and sends MyMsg1 to Actor2
  - Actor2 MyMsgHandler processes message(with Future), does pipeTo to
  sender and tries sending MyMsg2 - Goes to deadLetter. The actor Ref
  for sender is never set.

How do I fix scenario2?
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Flow.mapAsync and downstream demand

[Konrad “ktoso” Malawski]

In general relying on exact timing of pulls is rather seen as an anti
pattern…
Even if you do a custom stage, it’s very brittle, as any element put before
your stage could cause pulls, simply because that’s how things work.
The same can be said about simply changed buffer sizes between stages —
introducing an async boundary anywhere in the pipeline can lead
to more buffer space being allocated, and thus, more pulls being issued.

In other words — due to the fact that backpressure is connected through an
entire pipeline (and has to, otherwise it would not do what it should),
you can not rely on exact timing of pulls, because changes in the pipeline
may affect this.

In your very specific case perhaps it’s doable to make a stage or pipeline
that’ll do the right thing, with enforcing it with zips and loops,
but that’ll be specific and take some work and very precise wording of what
you want to achieve (sample code?)

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 23, 2018 at 7:05:18, Jeff (jknight12...@gmail.com) wrote:

Currently, Flow.mapAsync and Flow.mapAsyncUnordered always pull upstream
even if there is no demand from downstream and then buffer. However, there
are situations where one might want to way for explicit downstream demand
before pulling. For example, let's say that the next upstream item depends
on the results of the previous item and that you need to feed that back
into the upstream before pulling again. In its current form, Flow.mapAsync
will pull before that feedback loop has been completed.

Is there any way to work around that other than writing a custom
GraphStage?

Thanks
Jeff
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] allow-java-serialization = off breaks remoting

[Konrad “ktoso” Malawski]

You’re attempting to send a function.

remote ! Identify  <<< Identify here is wrong

Note that it is a case class, that takes a parameter:

final case class Identify(messageId: Any)


remote ! Identify(“hello”)

should work just fine.



-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 22, 2018 at 0:45:56, Alan Burlison (alan.burli...@gmail.com)
wrote:

I'm using protobuf serialization for my application messages and as
recommended in the docs I also have "allow-java-serialization = false":

https://doc.akka.io/docs/akka/2.5/serialization.html#enable-additional-bindings

"A few types in Akka are, for backwards-compatibility reasons, still
serialized by using Java serializer by default. You can switch them to
using protocol buffers instead by adding the following bindings or set
akka.actor.allow-java-serialization=off, which will make them serialized
using protocol buffers instead."

However if I do the following to get a remote ActorRef:

--
val remote: ActorSelection ...
:
remote ! Identify
--

I get the following fatal failure:

[WARN] [SECURITY][02/21/2018 15:44:45.815]
[RITA-akka.remote.default-remote-dispatcher-8]
[DisabledJavaSerializer(akka://RITA)] Outgoing message attempted to use
Java Serialization even though `akka.actor.allow-java-serialization =
off` was set! Message type was: [class akka.actor.ActorSelection$$anon$1]
[ERROR] [02/21/2018 15:44:45.818]
[RITA-akka.remote.default-remote-dispatcher-8] [Encoder(akka://RITA)]
Failed to serialize message [akka.actor.Identify].
(akka.serialization.DisabledJavaSerializer$JavaSerializationException:
Attempted to serialize message using Java serialization while
`akka.actor.allow-java-serialization` was disabled. Check WARNING logs
for more details.)

I'm clearly missing something obvious because what is documented simply
isn't working for me, but I can't figure out what.

Thanks,

-- 
Alan Burlison
-- 

-- 
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Swakka - a new extension to akka-http for Swagger/OpenApi

[Konrad “ktoso” Malawski]

Awesome, and +1 for the move to github (starred, watched) :-)

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 21, 2018 at 18:03:10, Jeremy Townson (jeremy.town...@gmail.com)
wrote:

Thanks, Patrik. I have raised https://github.com/akka/akka-http/issues/1874.

One thing to note is that I have moved Swakka to github. The bitbucket link
earlier in this thread is now broken and correct link is
https://github.com/jtownson/swakka (also in the ticket).

I can make the documentation change if you provide a pointer to the right
section.

Regards,
Jeremy

On Friday, 16 February 2018 19:06:44 UTC, Patrik Nordwall wrote:
>
> Thanks for the update Jeremey. Is the availability of this already
> mentioned in akka-http documentation? Otherwise I think it would be worth
> adding that somewhere. Please open an issue and we can work out the details.
>
> regards,
> Patrik
> ons 31 jan. 2018 kl. 20:32 skrev Philippe Derome :
>
>> never mind, it's not needed, I had communication with Spark in mind and
>> that does not require to be in same process.
>>
>>
>> On Wednesday, January 31, 2018 at 12:45:53 PM UTC-5, Philippe Derome
>> wrote:
>>>
>>> Jeremy,
>>>
>>> do you have any intent to make this project available with Scala 2.11?
>>>
>>> Phil
>>>
>>>
>>> On Tuesday, January 30, 2018 at 5:21:52 PM UTC-5, Jeremy Townson wrote:

 Thanks for reporting this, Philippe. For anybody who experienced this
 problem, fixed in https://bitbucket.org/jtownson/swakka/commits/
 0f5cb77196ea83135f9ca7913f1f111f6b39f369. Please pull from master.

 Actually I am planning a move to github soon, because of their really
 good usage stats.

 On Tuesday, 30 January 2018 19:56:26 UTC, Philippe Derome wrote:
>
>
> I had issues with credentials w.r. sonatype and removed all references
> thereof in build.sbt and plugins.sbt and this temporarily resolved my
> issues. I am not interested in publishing artifacts to an external site 
> but
> perhaps you are.
>
>
> On Tuesday, January 30, 2018 at 10:08:06 AM UTC-5, Philippe Derome
> wrote:
>>
>> Would you consider migrating the project to github since you find it
>> more stable now? I am unable to make use of it from bitbucket due to some
>> sonatype_credentials file issue, which looks mysterious to me and would
>> like to give this a dev try today.
>>
>> Thanks,
>>
>> Phil
>>
>>
>> On Wednesday, January 24, 2018 at 5:18:59 PM UTC-5, Jeremy Townson
>> wrote:
>>>
>>> Hi Akka users,
>>>
>>> This is an update about Swakka, an addon for generating
>>> OpenApi/Swagger docs with Akka-Http. I introduced Swakka in August last
>>> year. Back then it was new, unstable and I recommended people not to 
>>> use it.
>>>
>>> Yesterday, I cut a v0.5 release. Whilst the library does not cover
>>> Swagger 100%, it does cover everything in the Swagger’s famous 
>>> PetstoreV2
>>> sample. Therefore it should document many real world APIs.
>>>
>>> If you are creating Akka-Http endpoints and have a need to document
>>> them, I recommend you check out the project at
>>> https://bitbucket.org/jtownson/swakka/. I hope it would help your
>>> project and I would be really interested to hear your feedback.
>>>
>>> Beyond toughening up the library for a 1.0 release, I am also
>>> starting to consider where to go next with the project. Thoughts in my 
>>> mind
>>> right now are
>>> — do something completely different
>>> — support for other documentation formats like Api Blueprint or RAML.
>>> — having a close look at Akka-Http’s routing DSL, to see if there is
>>> a refactor that would yield an AST. Now that Swakka can do doc 
>>> generation
>>> from its OpenApi case class, if it _were_ possible to generate an AST 
>>> from
>>> a Route structure, it might also be possible to map over that to 
>>> produce an
>>> instance of OpenApi. Akka-Http users would then have the choice of 
>>> either
>>> coding an OpenApi instance and getting Swakka to generate Routes, or 
>>> coding
>>> Routes and generating OpenApi. I’m not convinced this is any more than a
>>> dream and I do not feel I have either the knowledge or authority to go
>>> tinkering with one of the core abstractions in Akka-Http. But if this
>>> interests you, you are familiar with the Akka-Http codebase and want to
>>> take a punt as a pair, I’m game.
>>>
>>> All the best,
>>> Jeremy
>>>
>>> On Monday, 21 August 2017 10:54:44 UTC+1, Jeremy Townson wrote:

 Hi Akka Users,

 I would like to introduce *Swakka*, a library for adding
 Swagger/OpenApi doc generation to akka-http. https://bitbucket.
 org/jtownson/swakka.

 Like many people I was frust

Re: [akka-user] Futures, Promises and Actors

[Konrad “ktoso” Malawski]

Hi Alan,
the reason is basically that a Future represents some computation that is
“running” (same as a Thread),
so serializing it does not make much sense. (Yes, there’s trickery and
magic we could do, but we avoid such magic tricks).

Rather, use the `future pipeTo someActor` pattern to deal with futures and
actors, as documened here:
https://doc.akka.io/docs/akka/2.5/futures.html#use-with-actors

Happy hakking

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 21, 2018 at 9:34:27, Alan Burlison (alan.burli...@gmail.com)
wrote:

I was browsing through "Effective Akka" and I noticed the following
somewhat cryptic warning:

--
Warning
Futures should never be passed between actors because you cannot
serialize a thread.
--

along with a bit above it about why Actor-to-Actor completion can't be
signalled using a Promise/Future:

"You cannot return a future value from a promise - they cannot be sent
to an actor, which may or may not be remote."

Why? Is this an implementation detail perhaps?

Thanks,

-- 
Alan Burlison
-- 

-- 
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [Akka Streams] Difference between KillSwitch and Materializer.shutdown()

[Konrad “ktoso” Malawski]

First warning sign: Why would you have one stream per materializer?

shutting down the materializer while things are running is very brutal.
It’s like forcefully pulling the carpet from under someone’s feet,
and the laughing as they spill their coffee upon themselves — don’t do this
as the go-to solution.
It’s better than leaving resource leaks, but don’t do this as the “clean”
shutdown.


KillSwitches actually signal termination properly using streams signals —
cancelation and completion/error.
Use them when you want to externally stop things.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 19, 2018 at 21:31:58, dol...@thoughtworks.com (
dol...@thoughtworks.com) wrote:

I came across 2 ways to terminate a stream

   1. KillSwitch
   2. Materializer.shutdown()

I see one difference which is

   - Materializer.shutdown() is used to kill all streams materialized by
   that materializer whereas KillSwitch can be used to terminate one
   particular stream.


In a scenario where I have one materializer per stream, is there any
difference between KillSwitch and Materializer.shutdow()? Which one should
be used? And When?
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Actor usage in Apache Spark and Apache Flink

[Konrad “ktoso” Malawski]

Best to ask on a Flink forum ;-)

-- 
Cheers,
Konrad 'ktoso <http://kto.so>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On February 19, 2018 at 14:32:15, Unmesh Joshi (unmeshjo...@gmail.com)
wrote:

Thanks Konrad.
What I was interested in was what use cases both Spark and Flink used
Actors for specifically. Are there any notes/docs around those that anyone
knows of?



On Monday, 19 February 2018 07:33:43 UTC+5:30, Konrad Malawski wrote:
>
> Hi there,
> There's been some confusion about how Spark used Akka, so let's clear that
> up first:
> It wasn't really core to any of the operations or core of Spark, and was
> used only to orchestrate some things,
> it was using raw Akka Remoting (which is discouraged, use Cluster instead
> due to the resilience benefits it gives).
>
> Users would sometimes want to combine Akka based things with their Spark
> jobs, but since Spark did not have Akka as a focus-on
> thing, but merely a small piece of code they tagged along, and they had
> internal mechanisms to do similar things as they used Akka for (just a few
> simple rpc-style calls),
> it was better for everyone to remove the dependency -- as Spark was using
> a rather old version, and people wanted to use recent versions of Akka --
> the usual dependency mess you get with big projects in other words.
>
> Thus Akka was removed from Spark, allowing users to bring their own Akka
> based libraries into Spark apps at-will, which is better for both projects
> and users as well.
> Shedding dependencies is generally a good thing, and I think Spark did the
> right thing there. You'll also notice how Akka tries to avoid any kind of
> external dependency that we're able to avoid -- for the same reasons,
> avoiding dependency hell for end users.
>
> Hope this helps,
>
> On Sun, Feb 18, 2018 at 8:58 PM, Unmesh Joshi  wrote:
>
>> Hi,
>>
>> Apache Spark used to use Akka Actors (which is replaced by Netty now) and
>> Apache Flink uses Actors. I am trying to understand the use case of Actor
>> usage in both these frameworks. Any pointers for help?
>>
>> Thanks,
>> Unmesh
>> --
>> >>>>>>>>>> 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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Cheers,
> Konrad 'ktoso' Malawski
> Akka <http://akka.io/> @ Typesafe <http://typesafe.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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Source.queue with java sample

[Konrad “ktoso” Malawski]

If you’re talking about doing akka streams / reactive streams over the
network (seems you imply that by mentioning ‘on other system’),
then the queue is not going to give you what you want.

That pattern is however trivial with a new feature that we’re about to
release in the upcoming release of Akka 2.5.10, which are stream refs:
Here’s a preview of the docs:
https://doc.akka.io/docs/akka/snapshot/stream/stream-refs.html



-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 13, 2018 at 15:07:51, 薛永飞 (siren...@gmail.com) wrote:

many thanks !
 But I think I hadn't  described clearly.
what I mean is that ,I want to receive the source from akka remote(which is
located in another system)

app1 send data to app2 which is a akka stream system



On Tuesday, 13 February 2018 20:55:37 UTC+8, Konrad Malawski wrote:
>
> Browse the docs :-)
>
> https://doc.akka.io/japi/akka/current/akka/stream/javadsl/
> Source.html#queue-int-akka.stream.OverflowStrategy-
>
>
> --
> Cheers,
> Konrad 'ktoso ' Malawski
> Akka  @ Lightbend 
>
> On February 13, 2018 at 13:48:41, 薛永飞 (sire...@gmail.com) wrote:
>
> I cannot find a Source.queue with  java sample,does anyone has? please!
> --
> >> 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 https://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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Source.queue with java sample

[Konrad “ktoso” Malawski]

Browse the docs :-)

https://doc.akka.io/japi/akka/current/akka/stream/javadsl/Source.html#queue-int-akka.stream.OverflowStrategy-



-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 13, 2018 at 13:48:41, 薛永飞 (siren...@gmail.com) wrote:

I cannot find a Source.queue with  java sample,does anyone has? please!
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Cluster Http Management Setup

[Konrad “ktoso” Malawski]

Happy hakking~!

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 12, 2018 at 11:04:28, Kilic Ali-Firat (kilic.alifi...@gmail.com)
wrote:

Hi Konrad,

It was the first time that I was using akka management, reading the
documentation I was missing a start() and a stop() in my code :)

Thank you !

Le lundi 12 février 2018 10:49:58 UTC+1, Konrad Malawski a écrit :
>
> You did not say which versions of libs you’re on, please say that always
> in such threads :)
>
> Assuming latest versions.
>
> The 2551 port is NOT the port that any HTTP is on; it’s where Akka
> remoting is bound to, HTTPing onto that one is not right :)
>
> How did you start the management endpoint? You’d know then which port you
> bound it to, see docs:
> https://developer.lightbend.com/docs/akka-management/
> current/akka-management.html#basic-usage
> (see port docs below)
>
> --
> Cheers,
> Konrad 'ktoso ' Malawski
> Akka  @ Lightbend 
>
> On February 12, 2018 at 10:43:50, Kilic Ali-Firat (kilic.a...@gmail.com)
> wrote:
>
> Hi guys,
>
> I'm started to play with Akka Cluster HTTP management. I have a project of
> an Akka Cluster in which I added dependencies (latest) to have informations
> about my cluster members.
>
> I have two seed nodes : one starting on port 2551 and other one 2552. The
> seed nodes are joining the cluster without any problems.
>
> Then I'm making a GET  request on the first seed node to get cluster
> members on the first node
> http://localhost:2551/cluster/members
>
> But I didn't get a response and I see following debug messages :
>
> info] [WARN] [02/12/2018 10:40:37.382] [New I/O worker #4]
> [NettyTransport(akka://FGS)] Remote connection to [/0:0:0:0:0:0:0:1:50510]
> failed with org.jboss.netty.handler.codec.frame.TooLongFrameException:
> Adjusted frame length exceeds 128000: 1195725860 - discarded
> [info] [DEBUG] [02/12/2018 10:40:37.383] [New I/O worker #4]
> [NettyTransport(akka://FGS)] Remote connection to [/0:0:0:0:0:0:0:1:50510]
> was disconnected because of [id: 0x70bfc85b, /0:0:0:0:0:0:0:1:50510 :>
> /0:0:0:0:0:0:0:1:2551] DISCONNECTED
> [info] [DEBUG] [02/12/2018 10:40:37.384] [FGS-akka.remote.default-remote-
> dispatcher-4] [akka.tcp://FGS@localhost:2551/system/transports/
> akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2FFGS%
> 400%3A0%3A0%3A0%3A0%3A0%3A0%3A1%3A50510-2] Association between local
> [tcp://FGS@localhost:2551] and remote [tcp://FGS@0:0:0:0:0:0:0:1:50510]
> was disassociated because the ProtocolStateActor failed: Unknown
> [info] [WARN] [02/12/2018 10:40:50.586] [New I/O worker #5]
> [NettyTransport(akka://FGS)] Remote connection to [/0:0:0:0:0:0:0:1:50538]
> failed with org.jboss.netty.handler.codec.frame.TooLongFrameException:
> Adjusted frame length exceeds 128000: 1195725860 - discarded
> [info] [DEBUG] [02/12/2018 10:40:50.587] [FGS-akka.remote.default-remote-
> dispatcher-13] [akka.tcp://FGS@localhost:2551/system/transports/
> akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2FFGS%
> 400%3A0%3A0%3A0%3A0%3A0%3A0%3A1%3A50538-3] Association between local
> [tcp://FGS@localhost:2551] and remote [tcp://FGS@0:0:0:0:0:0:0:1:50538]
> was disassociated because the ProtocolStateActor failed: Unknown
> [info] [DEBUG] [02/12/2018 10:40:50.587] [New I/O worker #5]
> [NettyTransport(akka://FGS)] Remote connection to [/0:0:0:0:0:0:0:1:50538]
> was disconnected because of [id: 0x3ebbc530, /0:0:0:0:0:0:0:1:50538 :>
> /0:0:0:0:0:0:0:1:2551] DISCONNECTED
>
> Did I need to update configuration of my akka Cluster or I'm missing
> something else ?
> --
> >> 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 https://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 https://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: 
>>>

Re: [akka-user] Akka Cluster Http Management Setup

[Konrad “ktoso” Malawski]

You did not say which versions of libs you’re on, please say that always in
such threads :)

Assuming latest versions.

The 2551 port is NOT the port that any HTTP is on; it’s where Akka remoting
is bound to, HTTPing onto that one is not right :)

How did you start the management endpoint? You’d know then which port you
bound it to, see docs:
https://developer.lightbend.com/docs/akka-management/current/akka-management.html#basic-usage

(see port docs below)

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 12, 2018 at 10:43:50, Kilic Ali-Firat (kilic.alifi...@gmail.com)
wrote:

Hi guys,

I'm started to play with Akka Cluster HTTP management. I have a project of
an Akka Cluster in which I added dependencies (latest) to have informations
about my cluster members.

I have two seed nodes : one starting on port 2551 and other one 2552. The
seed nodes are joining the cluster without any problems.

Then I'm making a GET  request on the first seed node to get cluster
members on the first node
http://localhost:2551/cluster/members

But I didn't get a response and I see following debug messages :

info] [WARN] [02/12/2018 10:40:37.382] [New I/O worker #4]
[NettyTransport(akka://FGS)] Remote connection to [/0:0:0:0:0:0:0:1:50510]
failed with org.jboss.netty.handler.codec.frame.TooLongFrameException:
Adjusted frame length exceeds 128000: 1195725860 - discarded
[info] [DEBUG] [02/12/2018 10:40:37.383] [New I/O worker #4]
[NettyTransport(akka://FGS)] Remote connection to [/0:0:0:0:0:0:0:1:50510]
was disconnected because of [id: 0x70bfc85b, /0:0:0:0:0:0:0:1:50510 :>
/0:0:0:0:0:0:0:1:2551] DISCONNECTED
[info] [DEBUG] [02/12/2018 10:40:37.384] [FGS-akka.remote.default-remote-
dispatcher-4] 
[akka.tcp://FGS@localhost:2551/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2FFGS%400%3A0%3A0%3A0%3A0%3A0%3A0%3A1%3A50510-2]
Association between local [tcp://FGS@localhost:2551] and remote
[tcp://FGS@0:0:0:0:0:0:0:1:50510]
was disassociated because the ProtocolStateActor failed: Unknown
[info] [WARN] [02/12/2018 10:40:50.586] [New I/O worker #5]
[NettyTransport(akka://FGS)] Remote connection to [/0:0:0:0:0:0:0:1:50538]
failed with org.jboss.netty.handler.codec.frame.TooLongFrameException:
Adjusted frame length exceeds 128000: 1195725860 - discarded
[info] [DEBUG] [02/12/2018 10:40:50.587] [FGS-akka.remote.default-remote-
dispatcher-13] 
[akka.tcp://FGS@localhost:2551/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2FFGS%400%3A0%3A0%3A0%3A0%3A0%3A0%3A1%3A50538-3]
Association between local [tcp://FGS@localhost:2551] and remote
[tcp://FGS@0:0:0:0:0:0:0:1:50538]
was disassociated because the ProtocolStateActor failed: Unknown
[info] [DEBUG] [02/12/2018 10:40:50.587] [New I/O worker #5]
[NettyTransport(akka://FGS)] Remote connection to [/0:0:0:0:0:0:0:1:50538]
was disconnected because of [id: 0x3ebbc530, /0:0:0:0:0:0:0:1:50538 :>
/0:0:0:0:0:0:0:1:2551] DISCONNECTED

Did I need to update configuration of my akka Cluster or I'm missing
something else ?
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka Concurrency - Trying to call actors in parallel from an actor

[Konrad “ktoso” Malawski]

Hi Rob,
ask is not the problem. The Await’s shown in the above code are.
Ask is not blocking, and sometimes perfectly fine.

Using Await is an anti pattern in general, but in Actors and other reactive
things is where it’s really bad.

Please read this section of the docs that shows what blocking causes:
https://doc.akka.io/docs/akka/2.5/dispatchers.html#blocking-needs-careful-management




-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 9, 2018 at 15:57:50, Rob Crawford (rob5...@gmail.com) wrote:

Don't use ask() -- you're blocking for no reason. Just tell() the other two
actors, and finish what you can with the information you have. Then, when
the responses from those two actors come in, do what you can with that
information.

Jonas and Viktor wrote an article for O'Reilly where they said this:

Reactive programming... is a subset of asynchronous programming and a
> paradigm where *the availability of new information drives the logic
> forward rather than having control flow driven by a thread-of-execution*.


Emphasis is mine. Rather than depending on ask() to try to force everything
into a single thread, accept that the information will come in sometime
after you ask for it -- maybe not in the order you asked for it -- and
finish the task after the answers come in.

On Friday, February 9, 2018 at 2:21:52 AM UTC-5, Tanmoy Bandyopadhyay
wrote:
>
> Hello,
>
> I am new to Akka. I am a bit confused with parallel Akka calls from an
> Akka actor. What I was trying to do is to make parallel-concurrent calls to
> two other actors using ask and awaiting for future to get resolved.
>
> public class Actor1 extends UntypedActor {
>
> public void onReceive(Object message) throws Throwable {
> Future searchFuture1 = ask(actor2, requestMessage,
> FUTURE_ACTOR_TIMEOUT);
> ResponseMessage responseMessage1 = (ResponseMessage)
> Await.result(searchFuture1, Duration.create(FUTURE_ACTOR_TIMEOUT,
> TimeUnit.MILLISECONDS));
>
> Future searchFuture2 = ask(actor3, requestMessage,
> FUTURE_ACTOR_TIMEOUT);
> ResponseMessage responseMessage2 = (ResponseMessage)
> Await.result(searchFuture2, Duration.create(FUTURE_ACTOR_TIMEOUT,
> TimeUnit.MILLISECONDS));
>
> //logic to merge both the response messages
> }
> }
>
> It looks sequential while making the calls to the separate actors. I want
> the calls(ask) to the actors in parallel. How can I achieve it.?Please help
> me to understand.
>
> Thanks in Advance.
> Tanmoy
>
> --
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Cluster Sharding in Chat room app

[Konrad “ktoso” Malawski]

No.
I mean that the sharded actor would extend PersistentActor, which gives you
that recovery

-- 
Cheers,
Konrad 'ktoso <http://kto.so>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On February 9, 2018 at 14:21:06, Konrad “ktoso” Malawski (
konrad.malaw...@lightbend.com) wrote:

Hi there,
sharding is the thing that “starts things on the other node”.
The thing that “recovers state” is akka persistence:
https://doc.akka.io/docs/akka/snapshot/persistence.html?language=scala

One often uses those two together, gaining the capability you just hinted
at.

Happy hakking

-- 
Cheers,
Konrad 'ktoso <http://kto.so>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On February 9, 2018 at 13:56:35, Vladyslav Petrov (petrovv...@gmail.com)
wrote:

Hello,

I'm investigating the Akka Clustering to scale my project.
Now, I have Chat room application based on web-sockets and Akka framework.
Each user has own stateful Actor which handle and process messages from
friends in chat room.
Actor stores the following data:

   - loggedUser - current user
   - Map - map of friends
   - Set - map of requested friends

During the investigation I found the topic in the documentation - Cluster
Sharding.

Cluster sharding is typically used when you have many stateful actors that
> together consume more resources (e.g. memory) than fit on one machine.


As I understand this approach will help me to restore user Actor on
neighbor node after node downing.
The persistenceId value - loggedUser.memberId
However I'm not fully understand how to recover the list of friends and
requested friends.
Could you help me to figure out how to store and recover user data? Should
I use the Distributed Data?

Thanks,
Vladyslav
--
>>>>>>>>>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Cluster Sharding in Chat room app

[Konrad “ktoso” Malawski]

Hi there,
sharding is the thing that “starts things on the other node”.
The thing that “recovers state” is akka persistence:
https://doc.akka.io/docs/akka/snapshot/persistence.html?language=scala

One often uses those two together, gaining the capability you just hinted
at.

Happy hakking

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 9, 2018 at 13:56:35, Vladyslav Petrov (petrovv...@gmail.com)
wrote:

Hello,

I'm investigating the Akka Clustering to scale my project.
Now, I have Chat room application based on web-sockets and Akka framework.
Each user has own stateful Actor which handle and process messages from
friends in chat room.
Actor stores the following data:

   - loggedUser - current user
   - Map - map of friends
   - Set - map of requested friends

During the investigation I found the topic in the documentation - Cluster
Sharding.

Cluster sharding is typically used when you have many stateful actors that
> together consume more resources (e.g. memory) than fit on one machine.


As I understand this approach will help me to restore user Actor on
neighbor node after node downing.
The persistenceId value - loggedUser.memberId
However I'm not fully understand how to recover the list of friends and
requested friends.
Could you help me to figure out how to store and recover user data? Should
I use the Distributed Data?

Thanks,
Vladyslav
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka, Akka Typed and dead code elimination

[Konrad “ktoso” Malawski]

Really Christopher… we’re not heavy on reflection, check other libraries in
the Java ecosystem ;-)

The single reflection things we have is classOf style actor creation, and
initial startup things, that’s it.

-- 
Cheers,
Konrad 'ktoso <http://kto.so>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On February 3, 2018 at 14:04:07, Christopher Hunt (hunt...@gmail.com) wrote:

Thanks for the reply Konrad.

Although my use-case is somewhat forced by working with constrained device
memory and enterprise security, I think that there’s a broader concern. My
understanding is that the JVM is embracing ahead of time compilation and
the potential for dead code elimination during the linking phase. I would
think that most forms of reflection would be at odds to that. Shouldn’t
Akka therefore be re-considering its position on its use of reflection, and
might Akka Typed be a way forward in that regard?

Cheers,
-C

On 3 Feb 2018, at 3:43 pm, Konrad “ktoso” Malawski <
konrad.malaw...@lightbend.com> wrote:

Hi Christopher,
I’ve worked in the past on an Scala on Android project, so have had the
“pleasure” of battling proguard for similar reasons.
In general I guess the “core stuff” needs to be kept, which would mostly be
the akka.actor and dungeon things.

AFAIR proguard is ale to understand references via “classOf” etc, so user
land actors should be fine. Typed actors also should be nicer to proguard.
The only things we’d need to specifically exclude from removal is things
that have classnames defined in configuration,
that’ll mostly e mailoxes, perhaps the remoting infra etc.

I guess it can be useful to have a config that is “known to work”, but I
don’t think it is realistic to fully know that “this will work for
everyone”, after all, you’re removing code.
If you want to provide the core set of excludes, that sounds useful. We in
the time are unlikely to have the time to maintain or help much with this
though.

-- 
Cheers,
Konrad 'ktoso <http://kto.so/>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On February 3, 2018 at 13:31:35, Christopher Hunt (hunt...@gmail.com) wrote:

Hi everyone,

I’ve got a requirement to run services on machines with limited resources,
memory in particular, but also disk (disk == memory for my use case!) In
addition, I wish to reduce the attack surface area of a service by
eliminating code that isn’t used.

I’d therefore like to take a unikernal-style of approach to my services
which, of course, use Akka. Using Proguard on my service very quickly
revealed problems relating to Akka. From looking through past posts, it
seems that the use of Proguard has been a discussion relating to Android
(which also hasn’t helped me around the issues I’ve been having).

Would there be any interest in seeing Akka become more suitable for dead
code elimination, particularly with the advent of Akka Typed? (reflection
and dead code elimination are at odds with each other)

Having an official project declaration of what classes should be kept for
dead code elimination, and an integration build verifying this to a degree
is what I’m thinking. I’d be happy contribute a PR with a little help.

Cheers
C

--
>>>>>>>>>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka, Akka Typed and dead code elimination

[Konrad “ktoso” Malawski]

Hi Christopher,
I’ve worked in the past on an Scala on Android project, so have had the
“pleasure” of battling proguard for similar reasons.
In general I guess the “core stuff” needs to be kept, which would mostly be
the akka.actor and dungeon things.

AFAIR proguard is ale to understand references via “classOf” etc, so user
land actors should be fine. Typed actors also should be nicer to proguard.
The only things we’d need to specifically exclude from removal is things
that have classnames defined in configuration,
that’ll mostly e mailoxes, perhaps the remoting infra etc.

I guess it can be useful to have a config that is “known to work”, but I
don’t think it is realistic to fully know that “this will work for
everyone”, after all, you’re removing code.
If you want to provide the core set of excludes, that sounds useful. We in
the time are unlikely to have the time to maintain or help much with this
though.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 3, 2018 at 13:31:35, Christopher Hunt (hunt...@gmail.com) wrote:

Hi everyone,

I’ve got a requirement to run services on machines with limited resources,
memory in particular, but also disk (disk == memory for my use case!) In
addition, I wish to reduce the attack surface area of a service by
eliminating code that isn’t used.

I’d therefore like to take a unikernal-style of approach to my services
which, of course, use Akka. Using Proguard on my service very quickly
revealed problems relating to Akka. From looking through past posts, it
seems that the use of Proguard has been a discussion relating to Android
(which also hasn’t helped me around the issues I’ve been having).

Would there be any interest in seeing Akka become more suitable for dead
code elimination, particularly with the advent of Akka Typed? (reflection
and dead code elimination are at odds with each other)

Having an official project declaration of what classes should be kept for
dead code elimination, and an integration build verifying this to a degree
is what I’m thinking. I’d be happy contribute a PR with a little help.

Cheers
C

-- 
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Cancel Actor job

[Konrad “ktoso” Malawski]

Have a look at "cluster sharding”, it’s smarter than just routers.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 2, 2018 at 11:09:19, Richard Gong (gong...@gmail.com) wrote:

That works in a single machine. Now take a step forward to have the workers
in a cluster. The master needs to dispatch jobs to workers. I'm looking at
the document of router,
https://doc.akka.io/docs/akka/current/cluster-usage.html?language=scala#router-with-pool-of-remote-deployed-routees.
My thought is worker code can be dynamically deployed and join the cluster
when needed. Let's say I have these 2 components running in different
nodes.

   - Master: accepts jobs and dispatches them to WorkerAdvisor.
   - WorkerAdvisor: creates an actual worker to run the job.

Now how the Master knows dispatches a job to a WorkerAdvisor which is free.
Broadcasting job to all WorkerAdvisors doesn't seem to be a good way
because we don't want a job to run in multiple places. Maintaining state of
WorkerAdvisor in Master seems odd to me as well.
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to shut down ActorSystem after all Actors have stopped?

[Konrad “ktoso” Malawski]

There is no reliable way to know what “everything is done” means.
This is because operations are asynchronous, and if you were to observe
“oh! nothing is in any mailbox!” the next millisecond something may
actually be in the mailbox, because it was just being asynchonously added.

Shutting down the system, must be an explicit decision.
It’s not like in sychronous programming world where things just “surely
have ended”.

You have to call system.terminate to do this.

There also is the reaper pattern:
http://letitcrash.com/post/30165507578/shutdown-patterns-in-akka-2
The pattern is pretty old, but still applies.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 1, 2018 at 7:23:21, santarupa...@gmail.com (
santarupa...@gmail.com) wrote:

Hi, Akka newbie here, I try the sample on Akka web site and notice the
ActorSystem still runs after the Actors have finished, and I have to hit
Enter to quit. Is there a way to shut down ActorSystem object once
everything is done? I already tried the suggestion to override the
reference.conf file with "akka.actor.guardian-supervisor-strategy = \"
akka.actor.StoppingSupervisorStrategy\"\n" but still no luck. I also
checked with folks on the other Akka chat room and they suggest using Akka
Streams instead of Akka Actors?? Any insight is greatly appreciated!

My public static void main()code:
=

Config myConfig =
ConfigFactory.parseString("akka.actor.guardian-supervisor-strategy =
\"akka.actor.StoppingSupervisorStrategy\"\n");
// load the normal config stack (system props, then application.conf,
then reference.conf)
Config regularConfig = ConfigFactory.load();
// override regular stack with myConfig
Config combined = myConfig.withFallback(regularConfig);
// put the result in between the overrides (system props) and defaults again
Config complete = ConfigFactory.load(combined);
// create ActorSystem
ActorSystem system = ActorSystem.create("actorSystem", complete);

final ActorRef taskManagerActor = system
.actorOf(TaskManager.props(taskListList.size(),
new FiniteDuration(3, TimeUnit.MILLISECONDS)));
for (List taskList : taskListList) {
  taskManagerActor.tell(new TaskActor.RunTaskMsg(taskList),
ActorRef.noSender());
}//end for


My TaskManager Actor has a match() to shut itself down and the system down:

===

...

.match(TaskManager.TaskCompletedMsg.class, o -> {
  if (taskCounter == totalNumTasks) {
System.out.println("\nAll child Actors have been stopped. Shutting
down TaskManager Actor...");
getContext().stop(getSelf());
System.out.println("\nAnd shutting down ActorSystem...");
getContext().getSystem().terminate();
  }//end if
})

...

--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Default Dispatcher creating 9000+ Worker Threads!!

[Konrad “ktoso” Malawski]

Please read the docs about this effect here:
https://doc.akka.io/docs/akka/current/dispatchers.html#blocking-needs-careful-management

It’s the Fork Join Pools (JDK) reaction to doing “bad things”™ (blocking)
to it.

The solution is as Johan explained.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On January 30, 2018 at 18:56:53, Akka Team (akka.offic...@gmail.com) wrote:

If you use Await.result, Await.ready or surround logic
with scala.concurrent#blocking and use a FJP dispatcher, that will fork
unbounded amounts of threads for those blocks, so that could perhaps
explain why you are seing so many thread. Looking at stack dumps should
show you what those threads are doing. If this is the problem the solution
would be to not block or to run such things on a separate thread pool based
dispatcher.

--
Johan
Akka Team

On Tue, Jan 16, 2018 at 8:37 PM,  wrote:

> Hey Folks,
>
> I've been working on a service thats built on Scala + Play (2.5.3), which
> also makes some use of Akka actors (with no remote-ing). Recently i've
> noticed that the service intermittently goes down due to OOM. Looked up the
> .hprof dump files (set to be created on OOM failures) and it appears that
> 9000+ (!) worker threads 
> (akka.dispatch.MonitorableThreadFactory$AkkaForkJoinWorkerThread)
> were created named 'application-akka.actor.default-dispatcher-'.
> Additionally, all these worker threads have no stack trace or a history of
> any task assigned to them.
>
> Refer attached .csv of Eclipse Memory Analyzer's thread summary.
>
> Note :
> 1) I haven't defined any custom Dispatcher / Execution Context / Thread
> Pool.
> 2) As per Play's docs, i've ensured that ActorSystems are only injected
> and never created, hence only play's default actor system is used.
>
> I assumed that a max of 64 threads would be created since only the default
> actor system was used, but these many threads is very strange.
>
> Any help with analysing this issue would be great, more specifically any
> advice on how to ascertain how/why these 'ghost' workers threads are
> created would be super useful. Any tools to monitor creation of worker
> threads by Akka Dispatcher?
>
> -- Abhilash
> --
> >> 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 https://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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Cancel Actor job

[Konrad “ktoso” Malawski]

Actors may not be that cheap.

They are ~400 bytes for an Actor; plus whatever you put inside one of
course, but that’s your state, not the Actor’s fault ;)

I tried to create a worker actor every time the master actor received a
start job message and found out that it created a new thread to run it.
Seems to me that the default dispatcher is an unbounded thread pool. It
doesn't look good to me -- it falls back to the thread per request model???

That’s not true. Actors share a thread-pool, the pool may decide more
threads would be a good idea ;-)

if you are doing blocking operations, please follow the advice which I
already posted in the previous email, read about managing blocking:

https://doc.akka.io/docs/akka/current/dispatchers.html#blocking-needs-careful-management

Since the jobs are CPU intensive, I have to control the number of
concurrent jobs.

Sure, which is why I suggested the master actor who can control how many
workers are active at any given time.

Number of threads you can limit by following the docs above, in dispatchers.

Here's an update of the code. It works to me. Just want to clarify if this
a right way to do.

// When master actor receive startJob message, creates a new worker actor
with a predefined dispatcher with a fixed thread pool to control the number
of concurrent jobs.
ActorRef worker =
getContext().actorOf(Props.create(Worker.class).withDispatcher("my-blocking-dispatcher"));
worker.tell(job, self());


Yes, that’s the bigger part of it, read above docs to understand why.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] akka-http remote to akka cluster or join the cluster?

[Konrad “ktoso” Malawski]

Using the cluster client is not recommended (as of it’s current
implementation at least, in early 2018 ;-)).

You can absolutely join your HTTP app into the same cluster and then most
apps make use of Cluster Sharding to distribute the load across the cluster.
Read up about it here;
https://doc.akka.io/docs/akka/current/scala/cluster-sharding.html

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On January 22, 2018 at 4:18:43, Troy Self (troy.s...@gmail.com) wrote:

Hello,

I'm writing a REST API using akka-http that I want to be backed by a
cluster of Actors. This way I can increase workers (Actors) backing the API
without necessarily standing up a second HTTP server. Some resources
suggest that I use the ClusterClientReceptionist in the cluster and then a
ClusterClient in my akka-http project. However, it also appears that I
could just have the akka-http project join the same Akka cluster as the
workers. Is there a preferred approach? It seems to me that the
'receptionist' could be in the akka-http project and when it joins the
cluster, all of the workers register themselves with that receptionist.
Then the akka-http routes can just use that receptionist actor to send
messages to the workers.

Thanks for any help. I've googled this a hundred ways and can't seem to
find consistent answers.

-- tBs
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: decorate actor events / events processing as a way to implement open tracing capabilities

[Konrad 'ktoso'; Malawski]

Hi there Daz,
I would strongly recommend using a proven implementation of tracing, i.e. 
the Lightbend Monitoring stack and it's Open Tracing support: 
https://developer.lightbend.com/docs/monitoring/latest/extensions/opentracing.html

Implementing it manually may seem like doable or at first, but there's a 
ton of things to consider and cover. 
You'd soon notice that you need the same context over HTTP calls, as well 
as Futures, and also carry it over Remoting, where just wrapping things 
will not only be heavy but also not work and possibly break sharding and 
other things,
as they apply extractors to messages -- so you'd need to modify these too. 
Not even mentioning the effort of implementing the same mechanisms for 
Futures etc etc.

In other words -- it seems like it's simple to add, but it really isn't, so 
give our implementation a look: 
https://developer.lightbend.com/docs/monitoring/latest/extensions/opentracing.html

It is commercial though but AFAIR you can try it out in non prod settings.
Follow the docs and enjoy a full-blown impl :)


-- 
Konrad

On Monday, January 22, 2018 at 4:18:46 AM UTC+9, daz...@gmail.com wrote:
>
> Hi, 
>
> I am using Akka in Java (and quite new to it). I want to decorate my actor 
> events and event processing so that I can achieve things like traceability. 
>
> One thought I had on doing this involves having all sent actor events 
> contain a context, which is always passed around with any subsequent 
> events, and enriched (immutably) with data useful for implementing 
> opentracing concepts such as timings, etc.. 
>
> This would be handled transparently somehow by extending the framework. 
> For example, when an event is handled, the actor's current ctx would be set 
> to the event's ctx, and any subsequent outbound event would be 
> automatically decorated with the ctx. I could also use this to set MDC with 
> the ctx values which would let me log with things like traceId / requestId.
>
> Assuming this is a reasonable thing to do, I was trying to understand what 
> would be needed to achieve this. An approach might be to extend 
> AbstractActor, and have things like receiveBuilder return a decorated 
> RecieveBuilder, which would in turn decorate the match handlers. However, 
> receiveBuilder is final so cannot do that. (What's the reason for it?). I 
> imagine it might also require decorating other things like ActorRef to 
> decorate the events with context... 
>
> Any thoughts on how to achieve this? Am entirely open to other avenues I 
> may be blind or naive to! 
>
> One constraint is that I am tied to using the Java api with Akka, but can 
> pull in open source Scala libraries so long as I can use them in Java 
> without the need to use Scala.
>
> Thanks,
> daz
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] expectNoMessage keeps unexpected message in the queue

[Konrad “ktoso” Malawski]

I see! Thanks for digging that up.
I think that was an un-intended change so I’ll fix that right away.

Issue here https://github.com/akka/akka/issues/24270 PR soon.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On January 8, 2018 at 19:22:08, Christophe Pache (chpa...@gmail.com) wrote:

Hello Conrad, thanks for answering!

I was speaking about the internal queue of the TestActor.

I upgraded from 2.5.3 to 2.5.8, in 2.5.3, the behavior was not the same:



private def expectNoMsg_internal(max: FiniteDuration) {
   val o = receiveOne(max)
   assert(o eq null, s"received unexpected message $")
   lastWasNoMsg = true
 }



Le lundi 8 janvier 2018 11:14:17 UTC+1, Konrad Malawski a écrit :
>
> What do you mean?
> What queue?
>
> They are both implemented using the exact same internal method:
>
> @deprecated(message = "Use expectNoMessage instead", since = "2.5.5")
> def expectNoMsg(max: FiniteDuration) {
>   expectNoMsg_internal(max.dilated)
> }
>
> /**
>  * Assert that no message is received for the specified time.
>  * Supplied value is not dilated.
>  */
> def expectNoMessage(max: FiniteDuration) = {
>   expectNoMsg_internal(max)
> }
>
>
>
> Do you mean some other API? If yes, which one?
>
> --
> Cheers,
> Konrad 'ktoso ' Malawski
> Akka  @ Lightbend 
>
> On January 8, 2018 at 19:11:30, Christophe Pache (chp...@gmail.com) wrote:
>
> Hello everyone,
>
> I would be interested to understand why `expectNoMessage`, in case there
> is unexpected message, keeps it on the queue (compared to expectNoMsg).
> It's all fine but from API point of view, my feelings would not expect such
> behavior (maybe because of other API). Maybe more doc on that would be an
> idea.
>
> Thanks and have a nice day.
>
> Christophe
> --
> >> 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 https://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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Processing `If-None-Match`

[Konrad “ktoso” Malawski]

You can deconstruct the data structure on your own like this:

val tag = EntityTag("kappa", weak = true)
val ifNoneMatch = `If-None-Match`(tag)

ifNoneMatch.m match {
  case EntityTagRange.Default(tags) if tags.nonEmpty ⇒ tags.head.tag
  case EntityTagRange.Default(tags) ⇒ ""
  case EntityTagRange.`*` ⇒ ""
}


ifNoneMatch match {
  case `If-None-Match`(EntityTagRange.Default(tags)) if tags.nonEmpty
⇒ tags.head.tag
  case `If-None-Match`(EntityTagRange.Default(tags)) ⇒ ""
  case `If-None-Match`(EntityTagRange.`*`) ⇒ ""
}


Happy hakking
-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On January 9, 2018 at 2:04:33, Colin Bester (bester.co...@gmail.com) wrote:

On server side using scala, akka-http (10.x) I am using
*optionalHeaderValueByType[`If-None-Match`]()
{ reqETag => ... }* to extract `If-None-Match` header where reqETag is of
type *Option[If-None-Match].*

On client side, the If-None-Match is created using

  val entityTag = EntityTag(SomeSecurishString, weak = true)
  val ifNone = `If-None-Match`(entityTag)

On the server side I am looking to extract SomeSecureString, ie. the tag
value minus the prepended W/. I realize this can be done by
parsing/splitting value string but this feels real cumbersome and was
expecting an unapply function to come to the rescue.


*`If-None-Match`.unapply* returns EntityTagRange which doesn't help me much.

Any suggestions on how to extract the EntityTag's tag string from
`If-None-Match`

Much appreciated
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] alpakka version of "Producer" or "Consumer" object?

[Konrad “ktoso” Malawski]

1. alpakka kinesis connector works well with KPL as well as KCL

It uses import com.amazonaws.services.kinesis.AmazonKinesisAsync

KPL seems to be the “kinesis data streams” api? That seems to use the same
PutRecord etc logic as we do though.


2. KinesisSources and KinesisSinks both work as "Producer" and "Consumer"
in the kafka sense.

Yes, pretty much.

— Konrad

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] expectNoMessage keeps unexpected message in the queue

[Konrad “ktoso” Malawski]

What do you mean?
What queue?

They are both implemented using the exact same internal method:

@deprecated(message = "Use expectNoMessage instead", since = "2.5.5")
def expectNoMsg(max: FiniteDuration) {
  expectNoMsg_internal(max.dilated)
}

/**
 * Assert that no message is received for the specified time.
 * Supplied value is not dilated.
 */
def expectNoMessage(max: FiniteDuration) = {
  expectNoMsg_internal(max)
}



Do you mean some other API? If yes, which one?

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On January 8, 2018 at 19:11:30, Christophe Pache (chpa...@gmail.com) wrote:

Hello everyone,

I would be interested to understand why `expectNoMessage`, in case there is
unexpected message, keeps it on the queue (compared to expectNoMsg). It's
all fine but from API point of view, my feelings would not expect such
behavior (maybe because of other API). Maybe more doc on that would be an
idea.

Thanks and have a nice day.

Christophe
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka 2.5.8 (Java Edition) Error initializing: java.lang.IllegalStateException: not yet initialized

[Konrad “ktoso” Malawski]

Are you not accidentally mixing Akka versions?
What does your dependency file look like with regards to Akka dependencies.

Akka Streams and Actor etc should all be on the same version.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On January 7, 2018 at 20:28:58, Eduardo Fernandes (edu...@gmail.com) wrote:

Hi all.

First of all: have all a happy new year.

I just jumped out from Akka 2.5.6 to 2.5.8. From that I'm getting the
following error when starting Akka:

java.lang.IllegalStateException: not yet initialized: only setHandler is
allowed in GraphStageLogic constructor
at akka.stream.stage.GraphStageLogic.interpreter(GraphStage.scala:295)
at akka.stream.stage.GraphStageLogic$$anon$1.invoke(GraphStage.scala:960)
at
akka.remote.artery.InboundControlJunction$$anon$2.attach(Control.scala:129)
at
akka.remote.artery.ArteryTransport.runInboundControlStream(ArteryTransport.scala:704)
at
akka.remote.artery.ArteryTransport.runInboundStreams(ArteryTransport.scala:686)
at akka.remote.artery.ArteryTransport.start(ArteryTransport.scala:455)
at akka.remote.RemoteActorRefProvider.init(RemoteActorRefProvider.scala:212)
at
akka.cluster.ClusterActorRefProvider.init(ClusterActorRefProvider.scala:31)
at akka.actor.ActorSystemImpl.liftedTree2$1(ActorSystem.scala:797)
at akka.actor.ActorSystemImpl._start$lzycompute(ActorSystem.scala:794)
at akka.actor.ActorSystemImpl._start(ActorSystem.scala:794)
at akka.actor.ActorSystemImpl.start(ActorSystem.scala:810)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:244)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:287)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:262)
at akka.actor.ActorSystem$.create(ActorSystem.scala:190)
at akka.actor.ActorSystem.create(ActorSystem.scala)


If I switch back to 2.5.6 or 2.5.5 and the error disappears.  I've tried
with 2.5.7 and the error is still there. Looks like some new behavior in
2.5.7.

I'm using Artery:

  remote {
log-remote-lifecycle-events = off
artery {
  enabled = on
  canonical.hostname = 127.0.0.1
  canonical.port = 0
}
  }

Many thanks in advance for your help!







--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] alpakka version of "Producer" or "Consumer" object?

[Konrad “ktoso” Malawski]

Hi Soichi,
“Producer” and “Consumer” are words used in Kafka, as such Alpakka’s Kafka
integration uses them as well.
(Note that Akka-Steam-Kafka is part of Alpakka, even if in an separate
repository)

The prime idea in all Alpakka things is that there are Sources (i.e. the
Consumer (consumes from kafka)) and Sinks.
These are types from Akka Streams, and mean sources and sinks of data.

If you think about them in those terms, it’s easier to map what you need to
the apropriate API.

For example in Kinesis, there’s KinesisSource and KinesisSink:
https://developer.lightbend.com/docs/alpakka/current/kinesis.html

Hope this helps!
// And happy holidays (today) ;-)

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On January 7, 2018 at 13:57:29, Soichi Ishida (soujiro0...@gmail.com) wrote:

I am new to alpakka, trying to shift from kafka to aws kinesis.

When using akka stream kafka, there was an object, Producer,
https://doc.akka.io/docs/akka-stream-kafka/current/producer.html (or
similarly "Consumer")
alpakka kinesis connector design philosophy is totally different from that
of "akka stream kafka"?, since there is no equivalent.


--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] File based durable mailboxes for akka actors

[Konrad “ktoso” Malawski]

Seems Durable (filebased) mailboxes weren’t even in 2.3, but 2.2… So even
more ancient ;-)
A question regarding them, made me assume you’re using those ancient
version of Akka.

Please give Persistence a try. There’s nothing durable mailboxes did better
(or even as good as) Persistence does nowadays.
The LevelDB is basically a file on the local host of the box using it
anyway, if you just want such guarantee.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On January 4, 2018 at 18:11:34, mandeep gandhi (welcomemand...@gmail.com)
wrote:

I was never using 2.3, I wrote 2.5.3, probably you misread the figures.
Also, I was looking at Akka persistence as there were some other
discussions in the forum regarding Durable mailbox vs Akka Persistence.

I was looking for the recommended practices only.


On Wednesday, January 3, 2018 at 2:32:52 PM UTC+5:30, Konrad Malawski
wrote:
>
> Firstly, Akka 2.3 is not supported anymore… Since 2015.
> Please upgrade to an actively maintained version, such as Akka 2.5.
> Akka 2.4 will be EOL shortly as well. 2.4 and 2.5 are binary compatible so
> there’s no reason whatsoever to remain on 2.4 (not mentioning 2.3).
>
> Akka 2.3 was enver released for Scala 2.12, and never will, thus, the
> filebased mailboxes don’t exist for 2.12.
> Because the filebased mailboxes module was deprecated in 2.3 and removed
> ever since.
> You can not mix Akka 2.3’s mailboxes with Akka 2.4 or 2.5; Akka 2.4/2.5+
> are compatible with eachother, 2.3 is not.
> https://doc.akka.io/docs/akka/current/common/binary-
> compatibility-rules.html
>
> They were also a very bad idea to begin with; you should be using Akka
> Persistence which is a replacement for them.
> Use this: https://doc.akka.io/docs/akka/2.5/scala/persistence.html
> 
>
> If you insist on using filebased mailboxes, you can copy their sources
> into your codebase and use them like that, the license allows for that.
>
> --
> Cheers,
> Konrad 'ktoso ' Malawski
> Akka  @ Lightbend 
>
> On January 3, 2018 at 9:06:59, mandeep gandhi (welcome...@gmail.com)
> wrote:
>
> Hi,
> I wanted to know the current support if durable mailboxes with Akka. I am
> using Akka version 2.5.3 and Scala 2.12.3 and I want to use
> akka-mailbox-common for durable mailbox ( file system backed).
> Unfortunately, akka-mailbox-common is not available for scala 2.12.
> I tried something in build.sbt in library dependency "com.typesafe.akka" %
> "akka-mailboxes-common_2.11" % “2.3.16” but it won’t work
> giving me errors - "Modules were resolved with conflicting cross-version
> suffixes” for akka-actor & akka-testkit dependency.
>
>
>
> So my question is -
> a. Do I need to use some other library to get durable mailbox?
> b. If not then can anyone suggest any workaround?
>
>
>
> Exact error -
>
> [error] Modules were resolved with conflicting cross-version suffixes in
> {file:/}root:
>
> [error]com.typesafe.akka:akka-testkit _2.12, _2.11
>
> [error]com.typesafe.akka:akka-actor _2.12, _2.11
>
> [trace] Stack trace suppressed: run last *:update for the full output.
>
> [error] (*:update) Conflicting cross-version suffixes in:
> com.typesafe.akka:akka-testkit, com.typesafe.akka:akka-actor
>
> >
> --
> >> 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 https://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 https://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

Re: [akka-user] File based durable mailboxes for akka actors

[Konrad “ktoso” Malawski]

Firstly, Akka 2.3 is not supported anymore… Since 2015.
Please upgrade to an actively maintained version, such as Akka 2.5.
Akka 2.4 will be EOL shortly as well. 2.4 and 2.5 are binary compatible so
there’s no reason whatsoever to remain on 2.4 (not mentioning 2.3).

Akka 2.3 was enver released for Scala 2.12, and never will, thus, the
filebased mailboxes don’t exist for 2.12.
Because the filebased mailboxes module was deprecated in 2.3 and removed
ever since.
You can not mix Akka 2.3’s mailboxes with Akka 2.4 or 2.5; Akka 2.4/2.5+
are compatible with eachother, 2.3 is not.
https://doc.akka.io/docs/akka/current/common/binary-compatibility-rules.html


They were also a very bad idea to begin with; you should be using Akka
Persistence which is a replacement for them.
Use this: https://doc.akka.io/docs/akka/2.5/scala/persistence.html


If you insist on using filebased mailboxes, you can copy their sources into
your codebase and use them like that, the license allows for that.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On January 3, 2018 at 9:06:59, mandeep gandhi (welcomemand...@gmail.com)
wrote:

Hi,
I wanted to know the current support if durable mailboxes with Akka. I am
using Akka version 2.5.3 and Scala 2.12.3 and I want to use
akka-mailbox-common for durable mailbox ( file system backed).
Unfortunately, akka-mailbox-common is not available for scala 2.12.
I tried something in build.sbt in library dependency "com.typesafe.akka" %
"akka-mailboxes-common_2.11" % “2.3.16” but it won’t work
giving me errors - "Modules were resolved with conflicting cross-version
suffixes” for akka-actor & akka-testkit dependency.



So my question is -
a. Do I need to use some other library to get durable mailbox?
b. If not then can anyone suggest any workaround?



Exact error -

[error] Modules were resolved with conflicting cross-version suffixes in
{file:/}root:

[error]com.typesafe.akka:akka-testkit _2.12, _2.11

[error]com.typesafe.akka:akka-actor _2.12, _2.11

[trace] Stack trace suppressed: run last *:update for the full output.

[error] (*:update) Conflicting cross-version suffixes in:
com.typesafe.akka:akka-testkit, com.typesafe.akka:akka-actor

>
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: akka-http is there an example of showing how to integrate with servlet container?

[Konrad “ktoso” Malawski]

Matt is correct, Akka HTTP is a complete server implementation, all the way
down the sockets, through parsing and rendering headers, lifecycle
management etc etc.
It does so in a fully streaming manner as well, which is it’s strong point.

Embedding Akka HTTP inside a servlet container sells it short on what it
can do the best basically.
It would be possible, but we have not received enough commercial interest
to fund such development…
If you’re interested, let us know.

On the other hand; we know of organizations using servlet containers as the
deployment medium and not using their HTTP features at all,
but simply calling Akka HTTP’s bind() etc inside them. This would work, and
“bypass” the servlet stack.

Please note as well that even if not using Akka HTTP, you still may find
Akka Streams, Actors or Alpakka connectors tremendously useful,
so it’s not a binary decision really. If you have to stick to a servlet
container for HTTP you could do that, and still use all other Akka modules.

Hope this helps

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On January 2, 2018 at 19:37:40, Matt Edge (mattedg...@gmail.com) wrote:

If I am not mistaken Akka HTTP has its own HTTP server layer that it uses
(when you do Http().bind(..)). You can find more details in the Core Server
API section of the docs. It discusses in some detail what's going on under
the hood and how Akka's HTTP layer is, in my view, essentially a
replacement of the Servlet container.

If you absolutely must use a Servlet Container - I personally don't think
Akka HTTP is a good fit for you

On Tuesday, January 2, 2018 at 9:19:55 AM UTC-5, gdalessio wrote:
>
> Hi all,
>
> Regarding this topic, are there more details about this, or more then just
> "*completely negates all the benefits that Akka HTTP*" ?
> thanks!
>
> On Tuesday, 14 April 2015 15:49:19 UTC+2, Jas wrote:
>>
>> is there an example showing how to integrate servlet container with
>> akka-http? i'm currently using spray with serlvet with
>> https://github.com/spray/spray/blob/master/spray-
>> servlet/src/main/scala/spray/servlet/Servlet30ConnectorServlet.scala and
>> was hoping to find an example showing how to perform this with akka-http..
>>
>> thanks
>>
> --
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] access to http response databytes stream materialized value

[Konrad “ktoso” Malawski]

data= data.mapMaterializedValue(mat => doThings(mat))

Is how you can achieve it.
Yes, it’s the current best practice in those situations.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On December 30, 2017 at 18:45:07, Kyrylo Stokoz (k.sto...@gmail.com) wrote:

Hi All,

It is possible with akka-http to complete http route like this:


complete {

  HttpResponse(
entity =
  HttpEntity(
contentType = ...,
data= data
  )
  )

}


where data is Source[ByteString, _]


As user is not responsible to connect this source with sink it is not
possible to get materialized value of this source.

Similarly data.alsoTo or data.watchTermination do not expose result of
running this source.

it is though possible to receive notification that stream is finished
with Future[Done].


Is it possible / make sense to expose Future[Any] or (ideally) typed
result of source which is materialized by akka-http?


Regards,

Kyrylo



--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Why does Akka Http AuthenticationDirective use Tuple1?

[Konrad “ktoso” Malawski]

Just out of curiosity, why is the AuthenticationDirective using a Tuple1[T]
instead of just T?
Is this because of forward compatibility or has this some other reason?

It’s because we have infrastructure for combining directives of arbitrary
arity touples into other “combined” directives, where the type is simply
the sum of the TupleN and TupleM becomes a Tuple(N+M) with the values
combined. Having a special case for 1 would involve more conversions and
possibly not even work then, thus expressing it as Tuple1. Same with
directives that don’t provide values — they are Tuple0.

trait AuthenticationDirective[T] extends Directive1[T]

type Directive1[T] = Directive[Tuple1[T]]


Also it seems that the doc
https://doc.akka.io/docs/akka-http/current/routing-dsl/directives/security-directives/authenticateBasicAsync.html?language=scala
is out of date because it does not reflect this in the example and it also
contains a reference to a not existing class HttpAuthenticator.

I would like to fix the doc (provide a PR) but I think I am not experienced
enough.

Thanks for reporting — could you open a ticket about this?
http://github.com/akka/akka-http/issues so we don’t miss it?

You can pretty easily fix things even in the web UI, so I’d recommend you
give it a shot :-) Would be very nice of you, thanks!

Here’s the file of the page:
https://github.com/akka/akka-http/blob/master/docs/src/main/paradox/routing-dsl/directives/security-directives/authenticateBasicAsync.md
(this
is linked to on the page itself, as “The source code for this page can be
found here”).


Thanks!

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Streams for synchronous request processing

[Konrad “ktoso” Malawski]

In short I want to execute Akka graph from my API with out materializing
every time.

What’s your reason for this? Just so we’re on the same page and not
imagining reasons for doing this :)

Problem that I am facing:
How to pass request object to source node of graph.

That’s as simple as using a Source that allows inserting elements from
outside the stream, like Source.queue or Source.actorRef

Read the docs about those.


How to get corresponding response from sink node.

Why “corresponding”? That sounds like you’re not stream processing really
but request response thingy.

You can pass around the “which request this originated from" to correlate
once the sink gets it.


— Konrad

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Streams for synchronous request processing

[Konrad “ktoso” Malawski]

Sure it’d just work… What specifically do you have in mind?
What do you mean by “We should be able to plug-in out partial graphs to the
flow.” (specifically, what’s the use case).

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On December 20, 2017 at 15:12:30, Harit Chandra (chandra.ha...@gmail.com)
wrote:

Hi All,

We are evaluating Akka as simple graph executor. For our use case we need
to create REST API's and we wish to use Akka streams at core to process the
requests. We cannot use Akka HTTP due to some constraints. The requirement
is to materialize the graph once and synchronously process REST requests.
Please provide some pointers/snippets for this use case. We should be able
to plug-in out partial graphs to the flow.

Thanks,
Harit
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] cachingProhibited causes 404 not found to be returned by the server

[Konrad “ktoso” Malawski]

Could you provide a small reproducer showcasing the issue as repo?

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On December 20, 2017 at 9:14:41, Nicolae Marasoiu (
nicolae.maras...@gmail.com) wrote:

Hi,
I have js files and a getFromResourceDirectory. Since Chrome is caching
them and takes from cache without checking with the server (say via a
request with If-Modified-Since, or etag checking), I am trying with
cachingProhibited directive to check if when Expires, no-cache and/or
max-age headers are responded with the js files initially, if Chrome will
send the requests in a way that allows the server to return 304 not
modified.
However just wrapping the getFromResourceDirectory with cachingProhibited
(it is true that other directives are wrapping in between, chaining etc),
results in 404 not found being returned upon requesting the js files.
Please help me understand this,
Thank you,
Nicu Marasoiu
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: How to measure performance of Actor Message from one actor reaching to another actor

[Konrad “ktoso” Malawski]

Since you’d be measuring remoting there, on the boundary between nodes,
I highly recommend making use of its “new” (has been out there quite a few
months)
implemenation: Artery, see docs here:
https://doc.akka.io/docs/akka/2.4/scala/remoting-artery.html

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On December 16, 2017 at 17:05:37, kpri...@thoughtworks.com (
kpri...@thoughtworks.com) wrote:

I am interested in throughput (msg/s) and latency (us).
As shown in this diagram, Actors will be running in different JVM's on
different machines.
Messages will be remote and serialization/deserialization will be included.
In this diagram, Actor B acts as supervisor and one of the role it plays as
to validate (domain specific validations) all the messages it receives and
forwards it to Actor C.

Currently my benchmark looks like this CommandServiceBenchmark.scala

which
waits for acknowledgment from Actor C to Actor A.
Eventually this benchmark will support running actors in different JVM's.

Ideally what I want is my timer clock should start at Actor A when it sends
message to Actor B and clock should stop when Actor C receives message.












On Saturday, December 16, 2017 at 1:09:42 PM UTC+5:30, √ wrote:
>
> Also, is serialization/deserialization included? At what point does the
> timer clock start, and when does it stop?
>
> --
> Cheers,
> √
>
> On Dec 15, 2017 20:31, "Patrik Nordwall"  wrote:
>
>> What are you interested in? Throughput (msg/s) or latency (us)? Remote or
>> local? What will the results of the benchmarks be used for?
>>
>> /Patrik
>> fre 15 dec. 2017 kl. 12:23 skrev Akka Team :
>>
>>> I think the floodPipe benchmark may do what you want, commented out but
>>> you could easily uncomment and run locally:
>>>
>>> https://github.com/akka/akka/blob/master/akka-bench-jmh/
>>> src/main/scala/akka/actor/ForkJoinActorBenchmark.scala#L92
>>>
>>> --
>>> Johan
>>> Akka Team
>>>
>>> On Fri, Dec 15, 2017 at 11:20 AM,  wrote:
>>>
 Ok, I just looked at TellOnlyBenchmark.scala
 
  closely and it just drops all the message and does not take into
 consideration of time taken by message to reach receiving actor.


 On Friday, December 15, 2017 at 2:54:55 PM UTC+5:30,
 kpr...@thoughtworks.com wrote:
>
> Hello,
>
> I want to measure a performance of following use case using jmh.
>
>
>
>
> 1.
> Actor A sends Msg A to Actor B
> 2. On receiving Msg A, Actor B sends Same Msg A to Actor C
>
> I just want to measure performance of Msg A from Actor A reaching to
> Actor C (Do not want to consider acknowledgment).
> Is there any way i can measure this performance?
>
> I was going through Akka jmh benchmarks and found this
> TellOnlyBenchmark.scala
> 
>
> But not sure it just measures the performance of sending messages or
> it considers time required to reach message to Echo Actor?
>
>
> Thanks
>
>
> --
 >> 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 https://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+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For m

Re: [akka-user] Is it easy to use akka-http to build ...?

[Konrad “ktoso” Malawski]

It’s pretty much as simple as using this directive:
https://doc.akka.io/docs/akka-http/current/scala/http/routing-dsl/directives/file-and-resource-directives/getFromDirectory.html

https://doc.akka.io/docs/akka-http/current/scala/http/routing-dsl/directives/file-and-resource-directives/getFromResource.html

or it’s similar versions (explore the docs).

For basics of building an app read:
http://developer.lightbend.com/guides/akka-http-quickstart-scala/

happy hakking!

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On December 8, 2017 at 12:15:30, Thai (lgoptimusv...@gmail.com) wrote:

Hi All,

Is it easy to use akka-http to build a web app that can serve static files
(only 1 html file but it has many 

Re: [akka-user] Last IntelliJ update (2017.3) breaks developing with Akka / Scala on Java

[Konrad “ktoso” Malawski]

Hi Tomer,
Thanks for reporting it to the IntelliJ team.
Could you post a working link to the issue? The one posted does not seem to
work.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On December 5, 2017 at 21:49:14, Tomer Rothschild (roto...@cloudshare.com)
wrote:

Hi all,

The last IntelliJ update (2017.3) introduced regression that brakes
developing with Akka / Scala on Java.

The regression is that IntelliJ shows false error highlighting in Java when
subclassing Scala classes that had traits mixed in (all AbstractActor
classes for example - AbstractActor,
AbstractPersistentActor, AbstractPersistentActorWithAtLeastOnceDelivery,
etc'..).
IntelliJ forces you to either declare the new sub class as abstract, or
implement all the methods of all the mixins.
Needless to say, the project compiles and runs perfectly.


















I opened the following ticket with Jetbrains - ticket 1166142
,
and created the following repository that reproduces the false errors -
intellij-mixin-issue .

Please consider weighing in to the discussion so that the issue gets proper
prioritization in JetBrains.

Regards,
Tomer R.
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Cluster Bootstrap ?

[Konrad “ktoso” Malawski]

What do you want to know, that’s a pretty generic question ;-)
We’re working on it. It works, it’s not done yet, will have to be
cleaned-up quite a bit and documented.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On December 4, 2017 at 10:32:55, Gytis G (gy...@fmu1.net) wrote:

Hi,

can someone shed a light on progress with "Akka Cluster Bootstrap" [1] and
this demo [2]  ? Looks really promising!

Thanks!

[1]
https://developer.lightbend.com/docs/akka-management/current/bootstrap.html
[2] https://github.com/akka/akka-management/tree/master/joining-demo

--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka persistence in production - recommended journals?

[Konrad “ktoso” Malawski]

LevelDB is not, in any case, intended for production systems.

Production ready journals would be:
- the cassandra one, maintained by the akka team, it is most mature and has
most features
- the jdbc one, community maintained but seems to work well
- we’ve heard of people using the mongo one, but I can’t say if that’s a
good idea, likely not?

Happy hakking

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On November 30, 2017 at 1:13:58, Dobrin Ivanov (dobrin.iva...@gmail.com)
wrote:

Hi,

I'm trying to investigate whether to use akka persistence in production
using java.

I've been looking at https://doc.akka.io/docs/akka/snapshot/persistence.html

And also tried this example :
https://github.com/akka/akka-samples/tree/2.5/akka-sample-persistence-java

The article refers to (native LevelDB)
https://github.com/fusesource/leveldbjni while the example refers to (some
java LevelDB port)  https://github.com/dain/leveldb ... not sure why?

Simply changing to use the native one in the example does not work:
java.lang.NoClassDefFoundError: org/iq80/leveldb/impl/Iq80DBFactory




Q1: So if I do not need a cluster/failover/replication (or i my want to do
it myself for example) then can I use LevelDB in production? And if yes - I
guess it should be the native one?


Q2: Then the article recommends replicated journals. So does anybody use
akka-persistence-jdbc OR okumin/akka-persistence-sql-async in production
for example?
Are there any recommendations?
I guess they can be used in java too and not only in scala but please
correct me if I'm wrong.

Thanks!
(inexperienced akka user)

--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Typed and stack safety

[Konrad “ktoso” Malawski]

That’d only be the case in completely synchronous execution. And the
behaviours body would actually execute on that line — but it doesn’t.
Here once you returned a new behaviour, control is given back to whoever is
invoking things (in great simplification, “the actor system”).

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On November 28, 2017 at 19:11:54, Julien R. (jul...@richard-foy.fr) wrote:

I’ve tried Akka Typed and so far it looks nice. I’m just wondering if there
might be issues with stack-safety and memory leaks. Consider for instance
the following behavior definition given in the documentation:

private def chatRoom(sessions: List[ActorRef[SessionEvent]]):
Behavior[Command] =
  Actor.immutable[Command] { (ctx, msg) ⇒
msg match {
  case GetSession(screenName, client) ⇒
val wrapper = ctx.spawnAdapter {
  p: PostMessage ⇒ PostSessionMessage(screenName, p.message)
}
client ! SessionGranted(wrapper)
chatRoom(client :: sessions)
  case PostSessionMessage(screenName, message) ⇒
val mp = MessagePosted(screenName, message)
sessions foreach (_ ! mp)
Actor.same
}
  }

The chatRoom function is not tail-recursive, therefore each time the
behavior receives a message it will create a new frame, right?

--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Overriding onUpstreamFinish behaviour for FlowOps

[Konrad “ktoso” Malawski]

What kind of Flow exactly. What does it do?
See this too
https://doc.akka.io/docs/akka/current/stream/stream-error.html?language=scala#delayed-restarts-with-a-backoff-stage
other
than supervision which isn’t generic.



-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On November 27, 2017 at 14:14:33, Christopher Hunt (hunt...@gmail.com)
wrote:

Hi there.

I've got a requirement for a flow to keep going when its upstream input
completes/fails. I could write a custom flow stage and override
onUpstreamFinish, but I was wondering if there were a means to express this
just using the FlowOps API. FlowOps.detach got me excited, but that isn't
quite what I expected. Also, buffer(0, OverflowStrategy.backpressure)
looked as though it could do the job, but the buffer size must be positive.

Thanks for any assistance.

Kind regards,
Christopher
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Parsing Configuration

[Konrad “ktoso” Malawski]

Hard to tell without knowing exactly what you’re doing there, but usually
an explicit resolve is not needed.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On November 27, 2017 at 13:02:41, Joseph Mansigian (
joseph.c.mansig...@gmail.com) wrote:

Hello All,

I am working with some legacy Scala with Akka code.
The application.conf file makes use of substitutions.
Instead of receiving an automatic parse of the
application.conf file the code explicitly parses the file
and resolves the substitutions as thus:

val config_raw = ConfigFactory.parseFile(new File("application.conf"))
val config = config_raw.resolve

and subsequently uses config when creating an ActorSystem.

I understand that explicit parsing and resolving was necessary at one time
if there were substitutions in application.conf.  If this is no longer
necessary
I would like to drop the explicit parsing and resolving.  Can I ?

I am using Play Framework 2.6.6, Scala 2.12.2, Akka 2.5.4

Thank You
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Android client connecting to Akka cluster via sockets

[Konrad “ktoso” Malawski]

We’re working on an ClusterClient replacement that would use HTTP(2) or
GRPC as it’s transport,
this would be more or less what you’re after and also allow to keep the
convenience of Actor messaging.

I’d strongly discourage reverse engineering the protocol as such impl will
be rather brittle, and is bound to miss some intricacies in it.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On November 20, 2017 at 1:34:39, Roland Kuhn (goo...@rkuhn.info) wrote:

Hi Tom,

the core feature of Akka Cluster is location transparency: all Actors
within the cluster can seamlessly communicate via their ActorRefs.
Including something that is not really part of the cluster, or that can at
least not fully participate in the location transparent setting, will
likely lead to impedance mismatch down the road—and quite possibly some
pain and suffering.

Why don’t you communicate between your Android device and some cluster
members using an established protocol suite like HTTP? That way you will
not have trouble telling different kinds of ActorRefs apart regarding their
semantic limitations.

Regards,

Roland

Skickat från min iPad

15 nov. 2017 kl. 18:50 skrev Tomasz Ratajczak :

Hi,

how difficult would it be to develop socket based Android client for Akka
cluster without the Akka client libraries? I would like to have the
flexibility of Android network libraries and the power of Akka cluster
without going into the incompatibilities of Akka Java and Android Java. Do
not see a need for actors on Android device, only need for interaction with
the cluster actors.

This basically would involve reversing the Akka remote protocol and as such
may be a maintenance nightmare. Can this be done though?

It seems to me that frontending the Akka cluster with a custom, stateless
proxy that would act as a cluster client would be a much better alternative.

Thank you,
Tom
--
>> 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 https://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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Older version of Akka framework

[Konrad “ktoso” Malawski]

Hi Jani,
Use your dependency management tool such as sbt, maven or gradle to
download dependencies.
They’re all hosted on maven central.

No actively maintained version of Akka is compatible with JDK6.
You can use a not-maintained version of 2.3.x though — though we strongly
discourage that since it’s ancient (2015).

Akka is a toolkit, not a framework :-)

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On November 14, 2017 at 16:07:22, Jani Lillkåll (jlmailer2...@gmail.com)
wrote:

  Hi !

 Is there a place to download older version of Akka framework,  that would
compile with Java JDK 1.6 ?  Thanks for any info you can give. yours
Jani
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] FSMs and Akka Streams

[Konrad “ktoso” Malawski]

Hi John,
your problem description is a bit abstract so not quite sure what to advice
there,
however: please do bear in mind that Streams do not replace Actors.
They complement them. Streams are nice for linear things,
though Actors are nice for dynamic and distributed settings.

It depends on your exact problem.

Yes, if it’s a more-or-less static processing pipeline you can model it as
a stream (akka http is for example all streams).
You can take a look at building custom GraphStages (search the docs for
that keyword).

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On November 11, 2017 at 11:13:32, John Antypas (janty...@busygeeks.com)
wrote:

Good evening all

I'm learning my Akka, or rather learning to do it better.  I'm looking at
writing a lightweight protocol stack.  In the old Java world, I'd write a
rather large FSM that would handle all states and events.. but that was the
old days.  I assume today, I'd want to use Akka streams.  Assume I had
something like this:

FSM-Main:
 Handles main protocol states (Connected, Setup, Authentication,
Running)
Under each state, I have an FSM just for that state.  For example, under
the Auth state, I have a sub FSM that handles the various authentication
FSM.
I assume this is legal.

Now, in streams, where does this fit in with Akka streams -- I assume each
stream element would have its own FSM?
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Streaming proxy/tunel on top of akka-http

[Konrad “ktoso” Malawski]

Akka-HTTP does support completely streaming things, that’s pretty much it’s
main use case.
Please share code and or specifics about what does not work.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On November 8, 2017 at 12:05:15, Jozsef Zsido (zsjo...@gmail.com) wrote:

Hi,

I'm trying to write an akka-http based service which tunels some of the
requests through a given (ip,port).
The basics are working propely but I have problem when I try to download
large files. akka-http tries to load the complete response as Entity and
does not streams trully.
My expectation would be that the flow handler to read only the headers of
the response and to copy the content bytes in reactive way.
It should support large downloads, media streaming and chunked transfer.

Doeas have akka-http implementation support for these?
If yes, how should I set-up the flow?

Thanks,
Jozsef
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] ActorRef proxy - had somebody implemented?

[Konrad “ktoso” Malawski]

Normally you’d simple have an Actor do this, instead of hacking into the
internals as proposed in your snippet :-)
Have an actor who’d keep messages and forward to the target once it’s
received it.

Having that said, we have the concept of such “FutureRef” defined and
implemented in AkkaTyped,
it’s not ported over to Akka classic yet AFAIR.
https://github.com/akka/akka/blob/master/akka-typed/src/main/scala/akka/typed/ActorRef.scala#L69

Note that there is a akka.actor.pattern that someone contributed in Akka
but that’s not what this is.
I actually wonder if that one should remain or be removed hm…

You can investigate that semantics and if it is you can open a ticket about
porting it to classic Akka, I think we don’t have such ticket yet.
I opened a related ticket, in which we should perhaps remove or
disambiguate the current akka.pattern one, since it has same name but
different mechanics nowadays https://github.com/akka/akka/issues/23924


Hope this helps.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On November 6, 2017 at 6:30:50, Alexandr Sova (sovaalexa...@gmail.com)
wrote:

Hello, Akka community!

Sometimes there are situations when you don't have an ActorRef instance but
you know where to ask for it. It may be because actor is still haven't
being created and actor creation procedure requires some long-running tasks
to be completed for instance your application requires actor A that have a
dependency on component B which in turn depends on resource C that may not
be retrieved on application startup... or any other precondition where
actor could not exist...
But you have to give this ActorRef out of ActorSystem for example to Play!
controller or some different service (let's call it "client D"), whatever
but you don't want to show the implementation detail about actor still does
not exist, you just want to pass ActorRef as a constructor parameter. What
would you do?
In traditional systems I'd solve it with some kind of ProxyActorRef that'd
look something like that:


class ProxyActorRef(provider: () => Future[ActorRef]) extends ActorRef
with ScalaActorRef {
  private val futureRef = provider()
  override def path: ActorPath = ???

  override def !(message: Any)(implicit sender: ActorRef): Unit =
futureRef.onComplete({
case Success(ref) => ref.tell(message, sender)
case _ => // do nothing
  })
}


but with current akka implementation I just can't do it because
of ProxyActorRef does not confirm to InternalActorRef and InternalActorRef
is private[akka]
Usually akka have a way to solve most of problems that could happen - *do
anyone knows how to solve this kind of problem?*

And to have separate actor in front of actor A is not a solution because
actor A can be Router.fromConfig and nesting all the calls to distinct
actor:

   - makes all effort on building configurable proxy worthless
   - can have a performance impact
   



any way if performance could be sacrificed than simple router

with routing logic at actor rather than at actorRef would be much better
solution, but what if that is not a case and performance is significant?

And also to have componentB/resourceC acquire logic separate at actor A
also couldn't be an answer because that way you couldn't expect componentB
as a constructor dependency so actor starts at a state when it just can't
do the work which it supooses to so your actor A should become a FSM and
this approach is rather overhead/overcomplicated.

And to wrap expectation for ActorRef into another object which is not
instanceof ActorRef (couldn't be used with akka.patterns._ for example) is
also not a solution because you don't want to show your implementation
detail about that dependency may not ready when "clientC" gets created.

Do anyone have any idea around it? Or may be pull request to akka with such
functionality can be a good thing?
--
>> 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 https://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

Re: [akka-user] ActorSystem FatalError Handling

[Konrad “ktoso” Malawski]

When such errors are thrown all bets are off basically, in any app, not
just akka.

You can turn off the system automatically terminating — check
reference.conf, though as I said — all bets are off then anyway because
runtime is in potentially “bad state"

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On November 2, 2017 at 22:08:39, Mücahit Kantepe (mucahitkant...@gmail.com)
wrote:

If any Actor in ActorSystem throws a fatal error(StackOverFlowError,
OutOfMemoryError etc.) akka.actor.ActorSystemImpl shutdowns JVM or
shutdowns only ActorSystem. In configuration we can only change the
shutdown JVM behavior but I want to do some custom things before shutting
down the JVM, like pushing memory dump to somewhere when fatal error
occurs. As far as I see there is no option like onFatalErrorHook.

Configuring as not to shutdown JVM when fatal error occurs, only shutdowns
ActorSystem but since there is no flag for termination reason(I do shutdown
ActorSystem for some reasons), I could not found any way to trigger some
procedure after fatal error occurs.

Am I missing something?
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Timer of GroupedWithin (akka-stream-kafka) does not seem to be working

[Konrad “ktoso” Malawski]

Please report in one space at the same time.
This was already reported on the issue tracker by yourself.

This is to avoid wasting cycles and time. Thanks.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On October 27, 2017 at 17:34:02, MK G (gant...@gmail.com) wrote:

Timer of GroupedWithin does not seem to be working. In this example, I am
not getting any messages even after expiry of duration (10 seconds) even
though 7 items are available in Kafka. If I produce 3 more items, then I am
getting the entire desired batch (10 items). Please see the snippet below.


akka & akka streams Version = "2.4.19"

akka-stream-kafka Version = "0.17"


Am I missing anything? Thank you.


val consumerSettings: ConsumerSettings[Array[Byte], String] =
ConsumerSettings(ActorSystemContainer.system, new
ByteArrayDeserializer, new StringDeserializer)
  .withBootstrapServers(rsbProps.serverUrl)
  .withGroupId(rsbProps.groupId)
  .withProperty(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest")

Consumer.committableSource(consumerSettings, Subscriptions.topics("topic-1"))
  .groupedWithin(10, 10.seconds)
  .mapAsync(1) { group =>
val msgs =  group.toList.map(_.record.value())
saveToDB(msgs )
  }
  .map(group => group.foldLeft(CommittableOffsetBatch.empty) { (batch,
elem) =>
  batch.updated(elem.committableOffset)
  })
  .mapAsync(3)(_.commitScaladsl())

--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka TCP and Slow Start Restart

[Konrad “ktoso” Malawski]

You’re right, akka-remoting still isn’t designed to be exposed to public
internet.
It’s something we’ll keep thinking about our multi-datacenter support work
though.

-- 
Cheers,
Konrad 'ktoso <http://kto.so>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On October 26, 2017 at 4:36:55, Alan McSherry (alanmcshe...@gmail.com)
wrote:

HmmmI could handle the encrypting. But ...

https://stackoverflow.com/questions/22576020/akka-remote-over-the-internet

... I wonder if there are too many security holes or possible DDOS vectors
in Akka, it's not really designed to operate in a hostile
environment...(right ?)

An attacker could 'lookup' or try to create remote actors at a rate I can't
handle, and I want previously unknown nodes to be able to connect in order
to perform a handshake and if they fail I can close the connection. I have
a similar DDOS problem with Akka TCP but I know less about how friendly
Akka remoting is to attackers.

Ever come across someone using Akka remoting in an open internet type
service...?


On Wed, Oct 25, 2017 at 4:26 AM, Konrad “ktoso” Malawski <
konrad.malaw...@lightbend.com> wrote:

> What do you mean exactly?
> Switch to using Artery (the “new” remoting)? You could, sure.
>
> Just remember that it’s not encrypted so going over internet may be a bad
> idea if it has secure data.
> We’re working on a TLS-ed version of Artery, but it would likely be over
> TCP again.
>
> Though we know it should be faster than the previous implementation in any
> case.
>
> --
> Cheers,
> Konrad 'ktoso <http://kto.so>' Malawski
> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>
> On October 24, 2017 at 3:59:30, Alan McSherry (alanmcshe...@gmail.com)
> wrote:
>
> One of the building blocks of TCP is "slow start" and "slow start restart"
> 
>
> https://hpbn.co/building-blocks-of-tcp/#slow-start
>
> In particular for bursty applications "slow start restart" could be
> hampering the performance of an Akka app by not using the full bandwidth
> available at the time of the 'bursty' traffic.
>
> (I do not have any evidence that this is an issue for my scenario, it's
> still in the design stage.)
>
>
> 1. Anyone got links to case studies of this effect in their app? (Either
> related to Akka TCP or Akka in general)
>
> 2. Are there any settings or machinery in Akka under the hood that
> directly effect this "slow start restart"?
>
> I'm trying to determine is this a known handled thing or something we know
> about and accept or something we don't need to worry about because I've
> misunderstood it?
>
> Much thanks for reading!
>
> Alan.
>
>
>
>
> --
> >>>>>>>>>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka cluster or Kubernetes

[Konrad “ktoso” Malawski]

They’re completely different.

Kubernetes is where you run apps. It shedules entire apps onto a set of
nodes.
Akka cluster IS the app. It runs on a set of nodes, and leverages health
mechanisms to be able to smartly balance load and actors across them.

Akka cluster apps are the apps that kubernetes would schedule.
Akka cluster then does more fine-grained things internally. For k8s though,
it’s “an app”.

Please read our guide on the subject:
https://developer.lightbend.com/guides/akka-cluster-kubernetes-k8s-deploy/

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On October 26, 2017 at 4:10:52, Rum (droidit@gmail.com) wrote:

I am trying to understand when I have to use Akka cluster and it is
significance. Is it same as Kubernetes?
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka TCP and Slow Start Restart

[Konrad “ktoso” Malawski]

What do you mean exactly?
Switch to using Artery (the “new” remoting)? You could, sure.

Just remember that it’s not encrypted so going over internet may be a bad
idea if it has secure data.
We’re working on a TLS-ed version of Artery, but it would likely be over
TCP again.

Though we know it should be faster than the previous implementation in any
case.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On October 24, 2017 at 3:59:30, Alan McSherry (alanmcshe...@gmail.com)
wrote:

One of the building blocks of TCP is "slow start" and "slow start restart"


https://hpbn.co/building-blocks-of-tcp/#slow-start

In particular for bursty applications "slow start restart" could be
hampering the performance of an Akka app by not using the full bandwidth
available at the time of the 'bursty' traffic.

(I do not have any evidence that this is an issue for my scenario, it's
still in the design stage.)


1. Anyone got links to case studies of this effect in their app? (Either
related to Akka TCP or Akka in general)

2. Are there any settings or machinery in Akka under the hood that directly
effect this "slow start restart"?

I'm trying to determine is this a known handled thing or something we know
about and accept or something we don't need to worry about because I've
misunderstood it?

Much thanks for reading!

Alan.




--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka TCP and Slow Start Restart

[Konrad “ktoso” Malawski]

That’s one of the reasons the new remoting is Aeron (and thus UDP, with
TCP-like delivery semantics) based… :-)

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On October 24, 2017 at 3:59:30, Alan McSherry (alanmcshe...@gmail.com)
wrote:

One of the building blocks of TCP is "slow start" and "slow start restart"


https://hpbn.co/building-blocks-of-tcp/#slow-start

In particular for bursty applications "slow start restart" could be
hampering the performance of an Akka app by not using the full bandwidth
available at the time of the 'bursty' traffic.

(I do not have any evidence that this is an issue for my scenario, it's
still in the design stage.)


1. Anyone got links to case studies of this effect in their app? (Either
related to Akka TCP or Akka in general)

2. Are there any settings or machinery in Akka under the hood that directly
effect this "slow start restart"?

I'm trying to determine is this a known handled thing or something we know
about and accept or something we don't need to worry about because I've
misunderstood it?

Much thanks for reading!

Alan.




--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] No shutDown on Materializer

[Konrad “ktoso” Malawski]

Thanks Richard, sorry if I misread the phrasing you used, read it before
coffee time… :)
Hope the explanation helps though.

-- 
Cheers,
Konrad 'ktoso <http://kto.so>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On October 24, 2017 at 14:34:07, Richard Rodseth (rrods...@gmail.com) wrote:

Here you go

https://github.com/akka/akka/issues/23837



On Mon, Oct 23, 2017 at 10:22 PM, Konrad “ktoso” Malawski <
konrad.malaw...@lightbend.com> wrote:

> Adding the shutdown method to the interface you mean?
> I guess it could be considered, please open a ticket.
> Technically it would be breaking to do so, but materializers are somewhat
> special “internal” one might say.
>
> --
> Cheers,
> Konrad 'ktoso <http://kto.so>' Malawski
> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>
> On October 24, 2017 at 14:20:41, Richard Rodseth (rrods...@gmail.com)
> wrote:
>
> Hi Konrad. I don't believe I used that phrase, but thanks for elaborating.
> I will digest what you wrote and discuss it.
> Any thoughts on having a lifecycle method on Materializer vs
> ActorMaterializer?
>
> On Mon, Oct 23, 2017 at 7:39 PM, Konrad “ktoso” Malawski <
> konrad.malaw...@lightbend.com> wrote:
>
>> Hi Richard,
>> Saying that “using Materializer” will cause leaks is somewhat of a weird
>> phrasing, since that sounds just like “using ActorSystem can cause leaks” —
>> well sure, just like “using objects can cause leaks” :-)
>>
>> Let’s step back and analyse where your colleague’s statement came from,
>> and perhaps how/why the misinterpretation happened.
>>
>> I see someone really enjoyed Colin’s awesome talk about streams and
>> actors there :-)
>> // Likely the best talk about those two and how they fit together I’ve
>> seen by the way.
>> // You may want to read his blog http://blog.colinbreck.co
>> m/integrating-akka-streams-and-akka-actors-part-ii/
>> In his talk he explains the lifecycle differences between creating an
>> ActorMaterializer from an ActorSystem,
>> vs. creating an ActorMaterializer from an ActorContext. Note that both
>> are possible, since they are both ActorRefFactories.
>>
>> The ActorMaterializer’s lifecycle is bound to the ActorRefFactory that it
>> was created from.
>>
>> In other words:
>> 1) ActorMaterializer created from ActorSystem
>>   - will terminate all its streams if the ActorSystem terminates
>> 2) ActorMaterializer created from ActorContext
>>   - will terminate all its streams if THAT actor terminates
>>
>> It’s not that one is a leak and the other one isn’t.
>> It’s that the 1st case is good for long lived streams, and such that
>> should out-live an Actor if it was started in one.
>> Say, this is good for persistence query, or akka http, or some shared
>> stream many other parts of your system rely on.
>> The 2nd case is a good choice if the stream and actor are inherently
>> related to one another - say, the stream relates to some “user”, and the
>> actor that started that stream is also “the user”, so if the actor dies we
>> should also kill the stream.
>>
>> Hope this clarifies things.
>>
>> I also submitted a documentation improvement about it right now, so
>> please see here:
>> https://github.com/akka/akka/pull/23836
>>
>> --
>> Cheers,
>> Konrad 'ktoso <http://kto.so>' Malawski
>> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>>
>> On October 24, 2017 at 8:04:10, Richard Rodseth (rrods...@gmail.com)
>> wrote:
>>
>> I just heard from someone who attended a talk at Reactive Summit that you
>> can leak resources if you are restarting a stream within a host actor, and
>> not shutting down the materializer.
>>
>> I've written most of the stream creation logic and messages using
>> Materializer, not ActorMaterializer, and I see that the shutdown method is
>> only on ActorMaterializer.
>>
>> Easy enough to change my types, but I was curious if this was a
>> considered decision.
>> --
>> >>>>>>>>>> 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/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

Re: [akka-user] No shutDown on Materializer

[Konrad “ktoso” Malawski]

Adding the shutdown method to the interface you mean?
I guess it could be considered, please open a ticket.
Technically it would be breaking to do so, but materializers are somewhat
special “internal” one might say.

-- 
Cheers,
Konrad 'ktoso <http://kto.so>' Malawski
Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>

On October 24, 2017 at 14:20:41, Richard Rodseth (rrods...@gmail.com) wrote:

Hi Konrad. I don't believe I used that phrase, but thanks for elaborating.
I will digest what you wrote and discuss it.
Any thoughts on having a lifecycle method on Materializer vs
ActorMaterializer?

On Mon, Oct 23, 2017 at 7:39 PM, Konrad “ktoso” Malawski <
konrad.malaw...@lightbend.com> wrote:

> Hi Richard,
> Saying that “using Materializer” will cause leaks is somewhat of a weird
> phrasing, since that sounds just like “using ActorSystem can cause leaks” —
> well sure, just like “using objects can cause leaks” :-)
>
> Let’s step back and analyse where your colleague’s statement came from,
> and perhaps how/why the misinterpretation happened.
>
> I see someone really enjoyed Colin’s awesome talk about streams and actors
> there :-)
> // Likely the best talk about those two and how they fit together I’ve
> seen by the way.
> // You may want to read his blog http://blog.colinbreck.
> com/integrating-akka-streams-and-akka-actors-part-ii/
> In his talk he explains the lifecycle differences between creating an
> ActorMaterializer from an ActorSystem,
> vs. creating an ActorMaterializer from an ActorContext. Note that both are
> possible, since they are both ActorRefFactories.
>
> The ActorMaterializer’s lifecycle is bound to the ActorRefFactory that it
> was created from.
>
> In other words:
> 1) ActorMaterializer created from ActorSystem
>   - will terminate all its streams if the ActorSystem terminates
> 2) ActorMaterializer created from ActorContext
>   - will terminate all its streams if THAT actor terminates
>
> It’s not that one is a leak and the other one isn’t.
> It’s that the 1st case is good for long lived streams, and such that
> should out-live an Actor if it was started in one.
> Say, this is good for persistence query, or akka http, or some shared
> stream many other parts of your system rely on.
> The 2nd case is a good choice if the stream and actor are inherently
> related to one another - say, the stream relates to some “user”, and the
> actor that started that stream is also “the user”, so if the actor dies we
> should also kill the stream.
>
> Hope this clarifies things.
>
> I also submitted a documentation improvement about it right now, so please
> see here:
> https://github.com/akka/akka/pull/23836
>
> --
> Cheers,
> Konrad 'ktoso <http://kto.so>' Malawski
> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>
> On October 24, 2017 at 8:04:10, Richard Rodseth (rrods...@gmail.com)
> wrote:
>
> I just heard from someone who attended a talk at Reactive Summit that you
> can leak resources if you are restarting a stream within a host actor, and
> not shutting down the materializer.
>
> I've written most of the stream creation logic and messages using
> Materializer, not ActorMaterializer, and I see that the shutdown method is
> only on ActorMaterializer.
>
> Easy enough to change my types, but I was curious if this was a considered
> decision.
> --
> >>>>>>>>>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] No shutDown on Materializer

[Konrad “ktoso” Malawski]

Hi Richard,
Saying that “using Materializer” will cause leaks is somewhat of a weird
phrasing, since that sounds just like “using ActorSystem can cause leaks” —
well sure, just like “using objects can cause leaks” :-)

Let’s step back and analyse where your colleague’s statement came from, and
perhaps how/why the misinterpretation happened.

I see someone really enjoyed Colin’s awesome talk about streams and actors
there :-)
// Likely the best talk about those two and how they fit together I’ve seen
by the way.
// You may want to read his blog
http://blog.colinbreck.com/integrating-akka-streams-and-akka-actors-part-ii/

In his talk he explains the lifecycle differences between creating an
ActorMaterializer from an ActorSystem,
vs. creating an ActorMaterializer from an ActorContext. Note that both are
possible, since they are both ActorRefFactories.

The ActorMaterializer’s lifecycle is bound to the ActorRefFactory that it
was created from.

In other words:
1) ActorMaterializer created from ActorSystem
  - will terminate all its streams if the ActorSystem terminates
2) ActorMaterializer created from ActorContext
  - will terminate all its streams if THAT actor terminates

It’s not that one is a leak and the other one isn’t.
It’s that the 1st case is good for long lived streams, and such that should
out-live an Actor if it was started in one.
Say, this is good for persistence query, or akka http, or some shared
stream many other parts of your system rely on.
The 2nd case is a good choice if the stream and actor are inherently
related to one another - say, the stream relates to some “user”, and the
actor that started that stream is also “the user”, so if the actor dies we
should also kill the stream.

Hope this clarifies things.

I also submitted a documentation improvement about it right now, so please
see here:
https://github.com/akka/akka/pull/23836

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On October 24, 2017 at 8:04:10, Richard Rodseth (rrods...@gmail.com) wrote:

I just heard from someone who attended a talk at Reactive Summit that you
can leak resources if you are restarting a stream within a host actor, and
not shutting down the materializer.

I've written most of the stream creation logic and messages using
Materializer, not ActorMaterializer, and I see that the shutdown method is
only on ActorMaterializer.

Easy enough to change my types, but I was curious if this was a considered
decision.
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Complete generate a null value in akka-http

[Konrad “ktoso” Malawski]

Don’t return null in scala code, that’s very not-scala-style.
Instead you could return empty things, or best rather even to throw an
exception and make your handler
https://doc.akka.io/docs/akka-http/current/scala/http/routing-dsl/exception-handling.html
make
it into a not found response.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On October 20, 2017 at 15:15:42, Samuel Heredia (heredia.sam...@gmail.com)
wrote:

Hi! , I have a Route where if a function finds a data in the DB responds a
value of type Json,
when it does not find the value it responds with null and therefore the
complete responds null.
I want to validate this so that it does not respond null, but a String that
says: "Not found", this is my route, any help? Thanks

val route = pathPrefix("auth") {
  path("signIn") {
pathEndOrSingleSlash {
  post {
entity(as[LoginPassword]) { loginPassword =>
  val a = signIn(loginPassword.login,
loginPassword.password).map(_.asJson)
   if(signIn(loginPassword.login,
loginPassword.password).map(_.asJson) == null){
 complete(states.map(_.asJson))
   }else {
 def getObject : Option[Any] =
Option(signIn(loginPassword.login,
loginPassword.password).map(_.asJson))
 val ahh = signIn(loginPassword.login,
loginPassword.password).map(_.asJson)
 if(getObject.isEmpty || getObject == null){ ///NOT FOUND
   complete("Not Found")
 }else {
   complete(complete(signIn(loginPassword.login,
loginPassword.password).map(_.asJson))
 }
 //complete(signIn(loginPassword.login,
loginPassword.password).map(_.asJson))
   }
}
  }
}
  }


--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

[Konrad “ktoso” Malawski]

Step 1 – don’t panic ;-)
Step 2 – as I already asked for, please share actual details of the
benchmarks. It is not good to discuss benchmarks without any insight into
what / how exactly you’re measuring.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On October 12, 2017 at 15:31:19, Gary Malouf (malouf.g...@gmail.com) wrote:

We have a web service that we just finished migrating from spray 1.3 to
Akka-Http 10.0.9.  While in most cases it is performing well, we are seeing
terrible 99th percentile latencies 300-450ms range) starting from a very
low request rate (10/second) on an ec2 m3.large.

Our service does not do anything complicated - it does a few Map lookups
and returns a response to a request.  In spray, even 99th percentile
latencies were on the order of 1-3 ms, so we are definitely concerned.
Connections as with many pixel-type servers are short-lived -> we actually
pass the Connection: Close header intentionally in our responses.

Is there any obvious tuning that should be done on the server configuration
that others have found?
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

[Konrad “ktoso” Malawski]

Short lived connections are slightly more costly in Akka-HTTP than in
Spray, due to the streaming infrastructure.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On October 17, 2017 at 9:48:20, Gary Malouf (malouf.g...@gmail.com) wrote:

Hi Konrad,

Understand your point - not really possible to share code on a
closed-source project.  I'm more asking if akka-http does not handle
short-lived connections very well yet as opposed to how spray handled
them.  I will be profiling in the mean-time trying to get to the bottom of
the issue.

Gary

On Thursday, October 12, 2017 at 8:44:55 PM UTC-4, Konrad Malawski wrote:
>
> When asking about performance and benchmarks always include specific
> numbers, code, and benchmark methodology otherwise it’s just guessing and
> inventing numbers and reasons.
>
> Thanks
>
> --
> Konrad Malawski
>
> On October 13, 2017 at 5:36:06, Gary Malouf (malou...@gmail.com) wrote:
>
>> To be clear, 95th percentile and down are as low as before so wondering
>> if this is a new connection closing penalty being paid or if the actor
>> system needs to be tuned differently now...
>>
>> On Thursday, October 12, 2017 at 4:31:14 PM UTC-4, Gary Malouf wrote:
>>>
>>> We have a web service that we just finished migrating from spray 1.3 to
>>> Akka-Http 10.0.9.  While in most cases it is performing well, we are seeing
>>> terrible 99th percentile latencies 300-450ms range) starting from a very
>>> low request rate (10/second) on an ec2 m3.large.
>>>
>>> Our service does not do anything complicated - it does a few Map lookups
>>> and returns a response to a request.  In spray, even 99th percentile
>>> latencies were on the order of 1-3 ms, so we are definitely concerned.
>>> Connections as with many pixel-type servers are short-lived -> we actually
>>> pass the Connection: Close header intentionally in our responses.
>>>
>>> Is there any obvious tuning that should be done on the server
>>> configuration that others have found?
>>>
>> --
>> >> 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 https://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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Implements CRDTs conters more than 100 000

[Konrad “ktoso” Malawski]

It’s as the docs explain:

It is not intended for *Big Data*. The number of top level entries should
not exceed 10. When a new node is added to the cluster all these
entries are transferred (gossiped) to the new node. The entries are split
up in chunks and all existing nodes collaborate in the gossip, but it will
take a while (tens of seconds) to transfer all entries and this means that
you cannot have too many top level entries. The current recommended limit
is 10. We will be able to improve this if needed, but the design is
still not intended for billions of entries.
It depends on your data architecture though.
Are you sure it would be 1 million actual top level entries?

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On October 12, 2017 at 21:24:37, Hsnamed (hsna...@gmail.com) wrote:

Hello, how can i implement 1 million CRDTs counters to use akka without big
disadvantage ?

I have a big tree of business objects each of them contain counter and
threshold when threshold reach then object change its state.

Tree have more than 1 million objects. Does it possible to implements using
akka ?

Thanks for advices.

--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Uncaught error from thread - ContentType$WithMissingCharset

[Konrad “ktoso” Malawski]

Happy hakking, cheers :)

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 12 October 2017 at 00:27:11, bordec...@gmail.com (bordec...@gmail.com)
wrote:

Hi Konrad,

I think, the above VERSIONS resolved my issue. Thank you very much for the
response. I tested my code and it is working now.
(I'm working for a company so, hard to share the code.)


Regards,
Aditya Borde

On Wednesday, October 11, 2017 at 12:00:40 AM UTC-4, Konrad Malawski wrote:
>
> Weird indeed;
>
> With regards to versions, please always use the latest - esp when
> reporting issues like this.
> Please try 10.0.10 and 2.5.6 as I suggested above.
>
> Can you post a reproducer (repository) where we could reproduce this?
>
> —
> Konrad `kto.so` Malawski
> Akka  @ Lightbend 
>
> On 11 October 2017 at 10:22:19, bord...@gmail.com (bord...@gmail.com)
> wrote:
>
> Ok. I'm currently using
> akkaHttp: "10.0.7", akka: "2.5.2". Is there an issue? Or What packages I
> should be using?
>
>
>
>
> On Tuesday, October 10, 2017 at 9:17:49 PM UTC-4, Konrad Malawski wrote:
>>
>> Actually depend on akka-http 10.0.10 and akka 2.5.6 ;-)
>>
>> —
>> Konrad `kto.so` Malawski
>> Akka  @ Lightbend 
>>
>> On 11 October 2017 at 10:15:34, bord...@gmail.com (bord...@gmail.com)
>> wrote:
>>
>> Thanks for quick reply, Konrad.
>>
>> Actually, I'm using - these json parsing dependencies in Gradle.
>>
>> compile group: 'org.json4s', name: 'json4s-native_2.12', version: '3.2.11'
>> compile group: 'org.json4s', name: 'json4s-jackson_2.12', version: 
>> '3.5.0.RC1'
>> compile group: 'de.heikoseeberger', name: 'akka-http-json4s_2.12', version: 
>> '1.17.0'
>>
>>
>> And, I modified the function actually, where I'm using
>> *jackson.parseJson(info)* like this -
>>
>> Unmarshal(res.entity).to[String] map {
>> info =>
>>   jackson.parseJson(info).children.length
>>
>> Am I doing something wrong here?  or something wrong in Parsing using
>> *json4s*?
>>
>> Regards,
>> Aditya Borde
>>
>>
>> On Tuesday, October 10, 2017 at 9:04:22 PM UTC-4, Konrad Malawski wrote:
>>>
>>> The exception is pretty clear about something being wrong with
>>> dependencies:
>>>
>>> > java.lang.NoClassDefFoundError: akka/http/scaladsl/model/
>>> ContentType$WithMissingCharset
>>>
>>> How do you configure this project?
>>> What’s your dependencies / build file / build system?
>>>
>>> —
>>> Konrad `kto.so` Malawski
>>> Akka  @ Lightbend 
>>>
>>> On 11 October 2017 at 10:02:49, bord...@gmail.com (bord...@gmail.com)
>>> wrote:
>>>
>>> Hello,
>>>
>>> I'm receiving below exception in my application , *It is still showing
>>> me the result once though* and application crashes :
>>> This is my code : This failing at *complete :*
>>>
>>> Can someone help me on this :
>>>
>>>
>>> val resFuture = requests.map(x => (getFutureResp(req)))
>>>
>>>
>>> 
>>>
>>>  I'm making `complete` on the above resFuture onComplete event.
>>>
>>> ///
>>>
>>>
>>> def getFutureResp(req: HttpRequest)  = {
>>>
>>>   val responseFuture = 
>>> Source.single(Http().singleRequest(req)).runWith(Sink.head).flatMap{
>>> resultFuture => checkRespEntity(resultFuture)
>>>   }
>>>
>>>   responseFuture
>>>
>>> }
>>>
>>>
>>> futureFlags
>>>
>>> }
>>>
>>>
>>> def checkRespEntity(responseFuture: Future[HttpResponse]): 
>>> Future[Option[Int]] = {
>>>
>>>   val futureFlags : Future[Option[Int]] = responseFuture.flatMap {
>>> res =>
>>>   res.status match {
>>> case StatusCodes.OK =>
>>>   Unmarshal(res.entity).to[String] map {
>>> info =>
>>>   info.length
>>>   }
>>>   else {
>>> res.entity.dataBytes.runWith(Sink.ignore)
>>>
>>> None
>>>   }
>>>   }
>>>
>>> case _ =>  {
>>>   res.entity.dataBytes.runWith(Sink.ignore)
>>>   Future{ None }
>>> }
>>>   }
>>>
>>> }
>>>
>>>
>>> *Uncaught error from thread [myactor-akka.actor.default-dispatcher-5]
>>> shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for
>>> ActorSystem[myactor]*
>>> *java.lang.NoClassDefFoundError:
>>> akka/http/scaladsl/model/ContentType$WithMissingCharset*
>>> *at
>>> akka.http.scaladsl.marshalling.Marshal.$anonfun$toResponseFor$2(Marshal.scala:51)*
>>> *at scala.Option.flatMap(Option.scala:171)*
>>> *at
>>> akka.http.scaladsl.marshalling.Marshal.$anonfun$toResponseFor$1(Marshal.scala:50)*
>>> *at
>>> akka.http.scaladsl.util.FastFuture$.$anonfun$map$1(FastFuture.scala:23)*
>>> *at
>>> akka.http.scaladsl.util.FastFuture$.strictTransform$1(FastFuture.scala:41)*
>>> *at
>>> akka.http.scaladsl.util.FastFuture$.transformWith$extension1(FastFuture.scala:45)*
>>> *at
>>> akka.http.scaladsl.util.FastFuture$.map$extension(FastFuture.scala:23)*
>>> *at
>>> akka.http.scaladsl.marshalling.Marshal.toResponseFor(Marshal.scala:42)*
>>> *a

Re: [akka-user] [akka-http] Virtual hosts

[Konrad “ktoso” Malawski]

Simply Http().bind two times given the same routes ;)

Though in reality people would hide akka-http behind ngnix or something
similar and do the tls things there very often.

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 11 October 2017 at 15:10:34, Slowaner (turchaninov.nik...@gmail.com)
wrote:

I need two different sites at one machine with default listening ports.
I can extract requested domain name from RequestContext and configure
routes with extracted value. The problem is how configure different SSL
certificates for different domains?

среда, 11 октября 2017 г., 13:45:38 UTC+8 пользователь Konrad Malawski
написал:
>
> What’s the actual use case?
>
> By itself no.
>
> —
> Konrad `kto.so` Malawski
> Akka  @ Lightbend 
>
> On 11 October 2017 at 14:44:59, Slowaner (turchanin...@gmail.com) wrote:
>
> Is there any feature to bind many virtual hosts at one interface with same
> listening IP and Port?
> --
> >> 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 https://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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [akka-http] Virtual hosts

[Konrad “ktoso” Malawski]

What’s the actual use case?

By itself no.

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 11 October 2017 at 14:44:59, Slowaner (turchaninov.nik...@gmail.com)
wrote:

Is there any feature to bind many virtual hosts at one interface with same
listening IP and Port?
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Uncaught error from thread - ContentType$WithMissingCharset

[Konrad “ktoso” Malawski]

Weird indeed;

With regards to versions, please always use the latest - esp when reporting
issues like this.
Please try 10.0.10 and 2.5.6 as I suggested above.

Can you post a reproducer (repository) where we could reproduce this?

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 11 October 2017 at 10:22:19, bordec...@gmail.com (bordec...@gmail.com)
wrote:

Ok. I'm currently using
akkaHttp: "10.0.7", akka: "2.5.2". Is there an issue? Or What packages I
should be using?




On Tuesday, October 10, 2017 at 9:17:49 PM UTC-4, Konrad Malawski wrote:
>
> Actually depend on akka-http 10.0.10 and akka 2.5.6 ;-)
>
> —
> Konrad `kto.so` Malawski
> Akka  @ Lightbend 
>
> On 11 October 2017 at 10:15:34, bord...@gmail.com (bord...@gmail.com)
> wrote:
>
> Thanks for quick reply, Konrad.
>
> Actually, I'm using - these json parsing dependencies in Gradle.
>
> compile group: 'org.json4s', name: 'json4s-native_2.12', version: '3.2.11'
> compile group: 'org.json4s', name: 'json4s-jackson_2.12', version: '3.5.0.RC1'
> compile group: 'de.heikoseeberger', name: 'akka-http-json4s_2.12', version: 
> '1.17.0'
>
>
> And, I modified the function actually, where I'm using
> *jackson.parseJson(info)* like this -
>
> Unmarshal(res.entity).to[String] map {
> info =>
>   jackson.parseJson(info).children.length
>
> Am I doing something wrong here?  or something wrong in Parsing using
> *json4s*?
>
> Regards,
> Aditya Borde
>
>
> On Tuesday, October 10, 2017 at 9:04:22 PM UTC-4, Konrad Malawski wrote:
>>
>> The exception is pretty clear about something being wrong with
>> dependencies:
>>
>> > java.lang.NoClassDefFoundError: akka/http/scaladsl/model/
>> ContentType$WithMissingCharset
>>
>> How do you configure this project?
>> What’s your dependencies / build file / build system?
>>
>> —
>> Konrad `kto.so` Malawski
>> Akka  @ Lightbend 
>>
>> On 11 October 2017 at 10:02:49, bord...@gmail.com (bord...@gmail.com)
>> wrote:
>>
>> Hello,
>>
>> I'm receiving below exception in my application , *It is still showing
>> me the result once though* and application crashes :
>> This is my code : This failing at *complete :*
>>
>> Can someone help me on this :
>>
>>
>> val resFuture = requests.map(x => (getFutureResp(req)))
>>
>>
>> 
>>
>>  I'm making `complete` on the above resFuture onComplete event.
>>
>> ///
>>
>>
>> def getFutureResp(req: HttpRequest)  = {
>>
>>   val responseFuture = 
>> Source.single(Http().singleRequest(req)).runWith(Sink.head).flatMap{
>> resultFuture => checkRespEntity(resultFuture)
>>   }
>>
>>   responseFuture
>>
>> }
>>
>>
>> futureFlags
>>
>> }
>>
>>
>> def checkRespEntity(responseFuture: Future[HttpResponse]): 
>> Future[Option[Int]] = {
>>
>>   val futureFlags : Future[Option[Int]] = responseFuture.flatMap {
>> res =>
>>   res.status match {
>> case StatusCodes.OK =>
>>   Unmarshal(res.entity).to[String] map {
>> info =>
>>   info.length
>>   }
>>   else {
>> res.entity.dataBytes.runWith(Sink.ignore)
>>
>> None
>>   }
>>   }
>>
>> case _ =>  {
>>   res.entity.dataBytes.runWith(Sink.ignore)
>>   Future{ None }
>> }
>>   }
>>
>> }
>>
>>
>> *Uncaught error from thread [myactor-akka.actor.default-dispatcher-5]
>> shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for
>> ActorSystem[myactor]*
>> *java.lang.NoClassDefFoundError:
>> akka/http/scaladsl/model/ContentType$WithMissingCharset*
>> *at
>> akka.http.scaladsl.marshalling.Marshal.$anonfun$toResponseFor$2(Marshal.scala:51)*
>> *at scala.Option.flatMap(Option.scala:171)*
>> *at
>> akka.http.scaladsl.marshalling.Marshal.$anonfun$toResponseFor$1(Marshal.scala:50)*
>> *at
>> akka.http.scaladsl.util.FastFuture$.$anonfun$map$1(FastFuture.scala:23)*
>> *at
>> akka.http.scaladsl.util.FastFuture$.strictTransform$1(FastFuture.scala:41)*
>> *at
>> akka.http.scaladsl.util.FastFuture$.transformWith$extension1(FastFuture.scala:45)*
>> *at
>> akka.http.scaladsl.util.FastFuture$.map$extension(FastFuture.scala:23)*
>> *at
>> akka.http.scaladsl.marshalling.Marshal.toResponseFor(Marshal.scala:42)*
>> *at
>> akka.http.scaladsl.marshalling.ToResponseMarshallable.apply(ToResponseMarshallable.scala:17)*
>> *at
>> akka.http.scaladsl.marshalling.ToResponseMarshallable.apply$(ToResponseMarshallable.scala:16)*
>> *at
>> akka.http.scaladsl.marshalling.ToResponseMarshallable$$anon$1.apply(ToResponseMarshallable.scala:22)*
>> *at
>> akka.http.scaladsl.server.RequestContextImpl.complete(RequestContextImpl.scala:42)*
>> *at
>> akka.http.scaladsl.server.directives.RouteDirectives.$anonfun$complete$1(RouteDirectives.scala:47)*
>> *at
>> akka.http.scaladsl.server.StandardRoute$$anon$1.apply(StandardRoute.scala:19)*
>> *at
>> akka.http.scaladsl.server.StandardRoute$$an

Re: [akka-user] Uncaught error from thread - ContentType$WithMissingCharset

[Konrad “ktoso” Malawski]

Actually depend on akka-http 10.0.10 and akka 2.5.6 ;-)

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 11 October 2017 at 10:15:34, bordec...@gmail.com (bordec...@gmail.com)
wrote:

Thanks for quick reply, Konrad.

Actually, I'm using - these json parsing dependencies in Gradle.

compile group: 'org.json4s', name: 'json4s-native_2.12', version: '3.2.11'
compile group: 'org.json4s', name: 'json4s-jackson_2.12', version: '3.5.0.RC1'
compile group: 'de.heikoseeberger', name: 'akka-http-json4s_2.12',
version: '1.17.0'


And, I modified the function actually, where I'm using
*jackson.parseJson(info)* like this -

Unmarshal(res.entity).to[String] map {
info =>
  jackson.parseJson(info).children.length

Am I doing something wrong here?  or something wrong in Parsing using
*json4s*?

Regards,
Aditya Borde


On Tuesday, October 10, 2017 at 9:04:22 PM UTC-4, Konrad Malawski wrote:
>
> The exception is pretty clear about something being wrong with
> dependencies:
>
> > java.lang.NoClassDefFoundError: akka/http/scaladsl/model/
> ContentType$WithMissingCharset
>
> How do you configure this project?
> What’s your dependencies / build file / build system?
>
> —
> Konrad `kto.so` Malawski
> Akka  @ Lightbend 
>
> On 11 October 2017 at 10:02:49, bord...@gmail.com (bord...@gmail.com)
> wrote:
>
> Hello,
>
> I'm receiving below exception in my application , *It is still showing me
> the result once though* and application crashes :
> This is my code : This failing at *complete :*
>
> Can someone help me on this :
>
>
> val resFuture = requests.map(x => (getFutureResp(req)))
>
>
> 
>
>  I'm making `complete` on the above resFuture onComplete event.
>
> ///
>
>
> def getFutureResp(req: HttpRequest)  = {
>
>   val responseFuture = 
> Source.single(Http().singleRequest(req)).runWith(Sink.head).flatMap{
> resultFuture => checkRespEntity(resultFuture)
>   }
>
>   responseFuture
>
> }
>
>
> futureFlags
>
> }
>
>
> def checkRespEntity(responseFuture: Future[HttpResponse]): 
> Future[Option[Int]] = {
>
>   val futureFlags : Future[Option[Int]] = responseFuture.flatMap {
> res =>
>   res.status match {
> case StatusCodes.OK =>
>   Unmarshal(res.entity).to[String] map {
> info =>
>   info.length
>   }
>   else {
> res.entity.dataBytes.runWith(Sink.ignore)
>
> None
>   }
>   }
>
> case _ =>  {
>   res.entity.dataBytes.runWith(Sink.ignore)
>   Future{ None }
> }
>   }
>
> }
>
>
> *Uncaught error from thread [myactor-akka.actor.default-dispatcher-5]
> shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for
> ActorSystem[myactor]*
> *java.lang.NoClassDefFoundError:
> akka/http/scaladsl/model/ContentType$WithMissingCharset*
> *at
> akka.http.scaladsl.marshalling.Marshal.$anonfun$toResponseFor$2(Marshal.scala:51)*
> *at scala.Option.flatMap(Option.scala:171)*
> *at
> akka.http.scaladsl.marshalling.Marshal.$anonfun$toResponseFor$1(Marshal.scala:50)*
> *at
> akka.http.scaladsl.util.FastFuture$.$anonfun$map$1(FastFuture.scala:23)*
> *at
> akka.http.scaladsl.util.FastFuture$.strictTransform$1(FastFuture.scala:41)*
> *at
> akka.http.scaladsl.util.FastFuture$.transformWith$extension1(FastFuture.scala:45)*
> *at akka.http.scaladsl.util.FastFuture$.map$extension(FastFuture.scala:23)*
> *at akka.http.scaladsl.marshalling.Marshal.toResponseFor(Marshal.scala:42)*
> *at
> akka.http.scaladsl.marshalling.ToResponseMarshallable.apply(ToResponseMarshallable.scala:17)*
> *at
> akka.http.scaladsl.marshalling.ToResponseMarshallable.apply$(ToResponseMarshallable.scala:16)*
> *at
> akka.http.scaladsl.marshalling.ToResponseMarshallable$$anon$1.apply(ToResponseMarshallable.scala:22)*
> *at
> akka.http.scaladsl.server.RequestContextImpl.complete(RequestContextImpl.scala:42)*
> *at
> akka.http.scaladsl.server.directives.RouteDirectives.$anonfun$complete$1(RouteDirectives.scala:47)*
> *at
> akka.http.scaladsl.server.StandardRoute$$anon$1.apply(StandardRoute.scala:19)*
> *at
> akka.http.scaladsl.server.StandardRoute$$anon$1.apply(StandardRoute.scala:19)*
> *at
> akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$mapRouteResultWith$2(BasicDirectives.scala:67)*
> *at
> akka.http.scaladsl.server.directives.ExecutionDirectives.handle$1(ExecutionDirectives.scala:51)*
> *at
> akka.http.scaladsl.server.directives.ExecutionDirectives.$anonfun$handleRejections$4(ExecutionDirectives.scala:60)*
> *at
> akka.http.scaladsl.server.directives.BasicDirectives$$anonfun$recoverRejectionsWith$1.applyOrElse(BasicDirectives.scala:91)*
> *at
> akka.http.scaladsl.server.directives.BasicDirectives$$anonfun$recoverRejectionsWith$1.applyOrElse(BasicDirectives.scala:91)*
> *at
> akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$mapRouteResultWithPF$1(BasicDirectives.scala

Re: [akka-user] Uncaught error from thread - ContentType$WithMissingCharset

[Konrad “ktoso” Malawski]

The exception is pretty clear about something being wrong with dependencies:

> java.lang.NoClassDefFoundError:
akka/http/scaladsl/model/ContentType$WithMissingCharset

How do you configure this project?
What’s your dependencies / build file / build system?

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 11 October 2017 at 10:02:49, bordec...@gmail.com (bordec...@gmail.com)
wrote:

Hello,

I'm receiving below exception in my application , *It is still showing me
the result once though* and application crashes :
This is my code : This failing at *complete :*

Can someone help me on this :


val resFuture = requests.map(x => (getFutureResp(req)))




 I'm making `complete` on the above resFuture onComplete event.

///


def getFutureResp(req: HttpRequest)  = {

  val responseFuture =
Source.single(Http().singleRequest(req)).runWith(Sink.head).flatMap{
resultFuture => checkRespEntity(resultFuture)
  }

  responseFuture

}


futureFlags

}


def checkRespEntity(responseFuture: Future[HttpResponse]):
Future[Option[Int]] = {

  val futureFlags : Future[Option[Int]] = responseFuture.flatMap {
res =>
  res.status match {
case StatusCodes.OK =>
  Unmarshal(res.entity).to[String] map {
info =>
  info.length
  }
  else {
res.entity.dataBytes.runWith(Sink.ignore)

None
  }
  }

case _ =>  {
  res.entity.dataBytes.runWith(Sink.ignore)
  Future{ None }
}
  }

}


*Uncaught error from thread [myactor-akka.actor.default-dispatcher-5]
shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for
ActorSystem[myactor]*
*java.lang.NoClassDefFoundError:
akka/http/scaladsl/model/ContentType$WithMissingCharset*
*at
akka.http.scaladsl.marshalling.Marshal.$anonfun$toResponseFor$2(Marshal.scala:51)*
*at scala.Option.flatMap(Option.scala:171)*
*at
akka.http.scaladsl.marshalling.Marshal.$anonfun$toResponseFor$1(Marshal.scala:50)*
*at akka.http.scaladsl.util.FastFuture$.$anonfun$map$1(FastFuture.scala:23)*
*at
akka.http.scaladsl.util.FastFuture$.strictTransform$1(FastFuture.scala:41)*
*at
akka.http.scaladsl.util.FastFuture$.transformWith$extension1(FastFuture.scala:45)*
*at akka.http.scaladsl.util.FastFuture$.map$extension(FastFuture.scala:23)*
*at akka.http.scaladsl.marshalling.Marshal.toResponseFor(Marshal.scala:42)*
*at
akka.http.scaladsl.marshalling.ToResponseMarshallable.apply(ToResponseMarshallable.scala:17)*
*at
akka.http.scaladsl.marshalling.ToResponseMarshallable.apply$(ToResponseMarshallable.scala:16)*
*at
akka.http.scaladsl.marshalling.ToResponseMarshallable$$anon$1.apply(ToResponseMarshallable.scala:22)*
*at
akka.http.scaladsl.server.RequestContextImpl.complete(RequestContextImpl.scala:42)*
*at
akka.http.scaladsl.server.directives.RouteDirectives.$anonfun$complete$1(RouteDirectives.scala:47)*
*at
akka.http.scaladsl.server.StandardRoute$$anon$1.apply(StandardRoute.scala:19)*
*at
akka.http.scaladsl.server.StandardRoute$$anon$1.apply(StandardRoute.scala:19)*
*at
akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$mapRouteResultWith$2(BasicDirectives.scala:67)*
*at
akka.http.scaladsl.server.directives.ExecutionDirectives.handle$1(ExecutionDirectives.scala:51)*
*at
akka.http.scaladsl.server.directives.ExecutionDirectives.$anonfun$handleRejections$4(ExecutionDirectives.scala:60)*
*at
akka.http.scaladsl.server.directives.BasicDirectives$$anonfun$recoverRejectionsWith$1.applyOrElse(BasicDirectives.scala:91)*
*at
akka.http.scaladsl.server.directives.BasicDirectives$$anonfun$recoverRejectionsWith$1.applyOrElse(BasicDirectives.scala:91)*
*at
akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$mapRouteResultWithPF$1(BasicDirectives.scala:79)*
*at
akka.http.scaladsl.util.FastFuture$.strictTransform$1(FastFuture.scala:41)*
*at
akka.http.scaladsl.util.FastFuture$.transformWith$extension1(FastFuture.scala:45)*
*at
akka.http.scaladsl.util.FastFuture$.flatMap$extension(FastFuture.scala:26)*
*at
akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$mapRouteResultWith$2(BasicDirectives.scala:67)*
*at
akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$textract$2(BasicDirectives.scala:154)*
*at
akka.http.scaladsl.server.directives.ExecutionDirectives.$anonfun$handleExceptions$2(ExecutionDirectives.scala:32)*
*at
akka.http.scaladsl.server.Route$.$anonfun$asyncHandler$1(Route.scala:79)*
*at akka.stream.impl.fusing.MapAsync$$anon$23.onPush(Ops.scala:1172)*
*at
akka.stream.impl.fusing.GraphInterpreter.processPush(GraphInterpreter.scala:499)*
*at
akka.stream.impl.fusing.GraphInterpreter.processEvent(GraphInterpreter.scala:462)*
*at
akka.stream.impl.fusing.GraphInterpreter.execute(GraphInterpreter.scala:368)*
*at
akka.stream.impl.fusing.GraphInterpreterShell.runBatch(ActorGraphInterpreter.scala:571)*
*at
akka.stream.impl.fusing.GraphInterpreterShell$AsyncInput.execute(ActorGraphI

Re: [akka-user] yourkit CPU ignore list

[Konrad “ktoso” Malawski]

Well, it’s stream materialization, it takes time, you may want to know ;)

—
Konrad `kto.so` Malawski
Akka <http://akka.io> @ Lightbend <http://lightbend.com>

On 10 October 2017 at 19:32:21, Sam Halliday (sam.halli...@gmail.com) wrote:

What about PhasedFusingActorMaterializer.materialize? Or does that
indicate a problem with the way play is setup?



On 10 October 2017 at 10:49, Konrad “ktoso” Malawski
 wrote:
> ForkJoin noice mostly – people sometimes panic about ForkJoinPool#scan
> 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 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
> --
>>>>>>>>>>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] yourkit CPU ignore list

[Konrad “ktoso” Malawski]

ForkJoin noice mostly – people sometimes panic about ForkJoinPool#scan
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 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
--
>> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Changed osgi.ee requirement in Akka 2.5.6

[Konrad “ktoso” Malawski]

Hi there,
Its not an intended change as far as I can see.
Could you open a ticket please? ( GitHub.com/Akka/Akka )

We’ve been upgrading plugins to enable publishing with jdk9 recently so
something must have happened to abt-Osgi during that

On October 7, 2017 at 8:16:40, Oliver Heger (oheg...@gmail.com) wrote:

> Hi,
>
> I am using Akka in an OSGi environment with Apache Felix. After updating
> from version 2.5.4 to 2.5.6, the bundles can no longer be resolved due to a
> change in the osgi.ee requirement. I get the following error message:
>
> org.osgi.framework.BundleException: Unable to resolve
> com.typesafe.akka.actor [5](R 5.0): missing requirement
> [com.typesafe.akka.actor [5](R 5.0)] osgi.ee; 
> (&(osgi.ee=JavaSE)(version=1.8.0_141))
> Unresolved requirements: [[com.typesafe.akka.actor [5](R 5.0)] osgi.ee;
> (&(osgi.ee=JavaSE)(version=1.8.0_141))]
>
> Note the very specific version number 1.8.0_141. Earlier versions of Akka
> required the more generic version 1.8. Obviously, my OSGi framework cannot
> deal with this specific requirement out of the box.
>
> Was this an intended change?
>
> Thanks
> Oliver
>
> --
> >> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.