[akka-user] Need help in configuring logging for AKKA.

[Nitin Jadon]

We are trying to configure AKKA in Java to monitor JBPM engine in clustered 
nodes using below configuration for logging.

Application.conf

loggers = ["akka.event.slf4j.Slf4jLogger"]
loglevel = "DEBUG"

logback.xml


System.out

%X{akkaTimestamp} %-5level[%thread] %logger{0} - 
%msg%n


c:/logs/akka.log
true

%date{-MM-dd} %X{akkaTimestamp} %-5level[%thread] 
%logger{1} - %msg%n






But when we trying to run the jar, it's not creating the log file.

Does someone know what might be going wrong?

-- 
>>  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] ANNOUNCE: Akka HTTP 10.0.0 – fully stable release!

[Roland Kuhn]

Woohoo, congrats everyone!

Sent from my iPhone

> On 22 Nov 2016, at 17:23, Konrad 'ktoso' Malawski  wrote:
> 
> Dear hakkers,
> 
> Today, we are proud and happy to announce the immediate availability of the 
> fully stable version of Akka HTTP – 10.0.0, charmingly code named “X” by 
> @jonas on gitter!
> 
> Please note that while the version number changed significantly, the actual 
> surface APIs did not by much. The akka-http-core module was already stable 
> back in Akka 2.4, so it remained binary compatible, and the sources for 
> akka-http are almost completely compatible with those that were shipped as 
> Akka 2.4.11 – you should not have any trouble upgrading.
> 
> 
> 
> From here-on the Akka HTTP releases will respect binary compatibility, as 
> expected from stable Akka modules. We will also try out a novel way of 
> introducing new APIs, by shipping them in the stable modules however marking 
> them as “experimental” or “not-sure-if-we-keep-them” so you’d be able to 
> opt-in into those on a case-by case basis. This idea is under discussion in 
> the Consider @Experimental / @ApiMayChange markers on APIs issue on github.
> 
> 
> 
> Along with the new version, and stability of all of the modules, we expect 
> the community to quickly catch up with releasing the various support projects 
> for the new version, such as akka-http-cors, akka-sse, akka-http-session, 
> akka-json. This includes cross releases for Scala 2.12, for which Akka HTTP 
> is now available as well.
> 
> Documentation
> 
> The documentation is available under a separate directory under doc.akka.io, 
> and will follow the following scheme: doc.akka.io/docs/akka-http/[version]/, 
> the usual “current” symlink is also available and we recommend using that if 
> linking to Akka documentation from external sites such as stack overflow or 
> blogs.
> 
> The documentation has moved to the Lightbend Paradox tool, which allows us to 
> write documentation using extended markdown, instead of restructuredtext 
> which we found was making it difficult for first time contributors. Thanks a 
> lot, @jonas, who contributed the biggest part of the conversion!
> 
> 
> 
> We are currently working on a redesign of the documentation pages, so they 
> will soon get a shiny new look. Please bear with us during the transition 
> period. Other projects, like Alpakka, Reactive Kafka have also already 
> adopted Paradox, and Akka itself will soon follow as well. We will be able to 
> provide very interesting features thanks to Paradox, keep your eyes peeled 
> for them soon.
> 
> 
> 
> As always, help is very welcome, and if you find a part of the documentation 
> you’d like to see improved, please open tickets or send in pull requests 
> directly, thanks in advance!
> 
> Versioning
> 
> Akka HTTP from here-on will be versioned separately from Akka “core”. The 
> original purpose of these projects sharing their version number was that Akka 
> HTTP was evolving and providing many real-world requirements for the Akka 
> Streams implementation, thus they were developed together. Now that both 
> projects are stable, we want to be able to move them more independently.
> 
> 
> 
> The version scheme will follow semantic versioning, breaking changes will 
> only be made in major releases (i.e. the next one being 11.0.0). However we 
> will also introduce a new way of marking experimental APIs released inside 
> existing modules – for a discussion on this please see the issue 
> akka/akka-http#3.
> 
> The -experimental suffix has now been dropped for all of Akka HTTP’s module. 
> During the transition period make sure not to transitively depend on old 
> artifacts that still carry the suffix (like akka-http-experimental). 
> Otherwise, you could end up with multiple versions of the same classes on the 
> classpath.
> 
> 
> 
> This version of Akka HTTP depends on Akka 2.4.14, since some critical fixes 
> and improvements were made in the recent version of Akka.
> 
> Community
> 
> We consider ourselves very lucky that we have such vibrant and helpful 
> community around Akka, and Akka HTTP specifically. In recent months we 
> started to include more community members in our github teams for the various 
> projects (reactive-kafka, alpakka, akka-http), and plan on continuing to do 
> so. If you’re interested in becoming part of our extended teams, please read: 
> Akka HTTP - stable, growing and tons of opportunity on akka-meta and keep 
> hakking :-)
> 
> Credits
> 
> A total 22 issues were closed since the last release candidate, most of the 
> work has been fixes, stability improvements and preparing for the upcoming 
> stable release.
> 
> The complete list of closed issues since the split from Akka 2.4.11 can be 
> found on the 3.0.0-RC1, 10.0.0-RC2, 10.0.0 as well as the HTTP/2 PoC 
> milestones on github.
> 
> 
> 
> For this release we had the help of 23 committers – thank you! We continue to 
> be amazed by the steady stream of contributions from you all!

[akka-user] ANNOUNCE: Akka HTTP 10.0.0 – fully stable release!

[Konrad 'ktoso' Malawski]

Dear hakkers,

Today, we are proud and happy to announce the immediate availability of the 
fully stable version of Akka HTTP – 10.0.0, charmingly code named “X” by 
@jonas on gitter!

Please note that while the version number changed significantly, the actual 
surface APIs did not by much. The akka-http-core module was already stable 
back in Akka 2.4, so it remained binary compatible, and the sources for 
akka-http are almost completely compatible with those that were shipped as 
Akka 2.4.11 – you should not have any trouble upgrading.


>From here-on the Akka HTTP releases will respect binary compatibility, as 
expected from stable Akka modules. We will also try out a novel way of 
introducing new APIs, by shipping them in the stable modules however 
marking them as “experimental” or “not-sure-if-we-keep-them” so you’d be 
able to opt-in into those on a case-by case basis. This idea is under 
discussion in the Consider @Experimental / @ApiMayChange markers on APIs 
 issue on github.


Along with the new version, and stability of all of the modules, we expect 
the community to quickly catch up with releasing the various support 
projects for the new version, such as akka-http-cors 
, akka-sse 
, akka-http-session 
, akka-json 
. This includes cross 
releases for Scala 2.12, for which Akka HTTP is now available as well.
Documentation

The documentation  is available 
under a separate directory under doc.akka.io, and will follow the following 
scheme: doc.akka.io/docs/akka-http/[version]/, the usual “current” symlink 
is also available and we recommend using that if linking to Akka 
documentation from external sites such as stack overflow or blogs.

The documentation has moved to the Lightbend Paradox 
 tool, which allows us to write 
documentation using extended markdown, instead of restructuredtext which we 
found was making it difficult for first time contributors. Thanks a lot, 
@jonas , who contributed the biggest part of the 
conversion!


We are currently working on a redesign of the documentation pages, so they 
will soon get a shiny new look. Please bear with us during the transition 
period. Other projects, like Alpakka, Reactive Kafka have also already 
adopted Paradox, and Akka itself will soon follow as well. We will be able 
to provide very interesting features thanks to Paradox, keep your eyes 
peeled for them soon.


As always, help is very welcome, and if you find a part of the 
documentation you’d like to see improved, please open tickets or send in 
pull requests 
 directly, 
thanks in advance!
Versioning

Akka HTTP from here-on will be versioned separately from Akka “core”. The 
original purpose of these projects sharing their version number was that 
Akka HTTP was evolving and providing many real-world requirements for the 
Akka Streams implementation, thus they were developed together. Now that 
both projects are stable, we want to be able to move them more 
independently.


The version scheme will follow semantic versioning, breaking changes will 
only be made in major releases (i.e. the next one being 11.0.0). However we 
will also introduce a new way of marking experimental APIs released inside 
existing modules – for a discussion on this please see the issue 
akka/akka-http#3 .

The -experimental suffix has now been dropped for all of Akka HTTP’s 
module. During the transition period make sure not to transitively depend 
on old artifacts that still carry the suffix (like akka-http-experimental). 
Otherwise, you could end up with multiple versions of the same classes on 
the classpath.


This version of Akka HTTP depends on Akka *2.4.14*, since some critical 
fixes and improvements were made in the recent version of Akka.
Community

We consider ourselves very lucky that we have such vibrant and helpful 
community around Akka, and Akka HTTP specifically. In recent months we 
started to include more community members in our github teams for the 
various projects (reactive-kafka , 
alpakka , akka-http), and plan on 
continuing to do so. If you’re interested in becoming part of our extended 
teams, please read: Akka HTTP - stable, growing and tons of opportunity 
 on akka-meta and keep hakking 
:-)
Credits

A total 22 issues were closed since the last release candidate, most of the 
work has been fixes, stability improvements and preparing for the upcoming 
stable release.

The complete list of closed issues since the split from Akk

[akka-user] Akka with HTTP in Java

[Jay Pandya]

Hi - We have configured AKKA as a standalone jar file listening to TCP port 
and running on stand alone JVM so whenever this JVPM/TCP Port will go down 
other AKKA nodes will get notification.

our application.conf file is defined as per below

akka 
 {


 actor 
  {
provider = "akka.cluster.ClusterActorRefProvider"
 
 debug {
  receive = on
  autoreceive = on
  lifecycle = on
  fsm = on
  event-stream = on
  unhandled = on
  router-misconfiguration = on
}
  }
  
  remote 
  {
log-remote-lifecycle-events = off
netty.tcp {
  hostname = "127.0.0.1"
  port = 2551
}
  }
}

We have defined our Java code where we are loading config file using 

ActorSystem system = ActorSystem.create("ClusterSystem", config);



As per current configuration, we are listening to TCP Port, can anyone help 
me in guiding if i want to listen HTTP Port so that whenever HTTP port will 
go down, i can get notification?


-Jay

-- 
>>  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] ANNOUNCE: Akka 2.4.14 released!

[Konrad 'ktoso' Malawski]

Dear hakkers,

We are proud to announce the fourteenth maintenance release of Akka 2.4 
which contains a number of improvements and bugfixes.


Some notable changes are:

   - When reading snapshots fails for a persistent actor it will now cause 
   recovery failure #21842 
   - Performance improvements for the LocalSnapshotStore #20821 
   
   - Attributes on flatMapConcat/flatMapMerge now propagated to the inner 
   streams #21743 
   - Methods around actor selection returning Java CompletionStages #21726 
   
   - gzip/deflate Flows have been moved to Akka-Streams from Akka HTTP, so 
   that they can be used in any streaming application #21395 
   
   
Akka HTTP

Akka HTTP is not part of this release as it has moved to it’s own 
repository and will be released as soon as possible, as Akka 10.0.0. 

Keep your eyes our for an announcement about it *very soon*.
Skip Akka 2.4.13, due to uncovered regression

Please note that the 2.4.13 release contained a bug in the ByteStringParser 
that 
we noticed immediately after releasing, and decided to not announce that 
version - please upgrade immediately to 2.4.14 instead (or higher, as new 
versions become available). We will invest in strengthening 
downstream-dependency testing throughout the coming sprints, to avoid such 
issue from happening again.
Credits

A total 39 issues were closed since 2.4.12. The complete list of closed 
issues can be found on the 2.4.14 milestone on github 
.

For this release we had the help of 20 committers – thank you all very much!

Credits:
commits  added  removed
 12432  231 Patrik Nordwall
  9726  141 Johannes Rudolph
  6189   64 Johan Andrén
  5 20  862 Konrad Malawski
  5464  107 drewhk
  5 71   45 Björn Antonsson
  3650   24 Olli Helenius
  2 64   88 Hawstein
  2 80   33 Richard Imaoka
  2 67   18 Andy Chung
  2 39   14 Nafer Sanabria
  2 24   26 Martynas Mickevičius
  1 431 Vsevolod (Seva) Belousov
  1 332 Alexander Gavrilov
  1 256 Wojciech Grajewski
  1  8   14 Cédric Chantepie
  1  77 kenji yoshida
  1  64 Andrey Kuznetsov
  1  72 ortigali
  1  11 Marc Piechura

*Happy hakking!*

– The Akka Team

-- 
>>  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] Understanding scala.concurrent.Await#result

[Viktor Klang]

scala> def fut = {
 |   Thread.sleep(5000)
 |   Future(42)
 | }
fut: scala.concurrent.Future[Int]

scala> Await.result( fut, FiniteDuration(1, SECONDS) )
res1: Int = 42

The code above is equivalent of:

Thread.sleep(5000)
val anon = Future(42)
Await.result(anon, FiniteDuration(1, SECONDS))


On Tue, Nov 22, 2016 at 2:44 PM, Kevin Meredith 
wrote:

> Given the following on Scala 2.11.8:
>
> import scala.concurrent.Future
> import scala.concurrent.duration._
> import scala.concurrent.Await
> import scala.concurrent.ExecutionContext.Implicits.global
>
> scala> def fut = {
>  |   Thread.sleep(5000)
>  |   Future(42)
>  | }
> fut: scala.concurrent.Future[Int]
>
> Why does the following not throw a java.util.TimeoutException?
>
> scala> Await.result( fut, FiniteDuration(1, SECONDS) )
> res1: Int = 42
>
> As I understand, Await#result will throw if the time-out, i.e. its second
> argument, completes before the completion of the Future.
>
> If that's true, then why does 42 return in the above example instead of an
> exception?
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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] Understanding scala.concurrent.Await#result

[Konrad Malawski]

Why would it – the 42 is completed immediately.
It'd be different if you'd say Future { Thread.sleep(...); 42 }
that actually makes the future take a long time.

Your first example just takes "a long time, to get to an immediately
completing future.
The timeout is on the Future, not on "getting to it". :)

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 22 November 2016 at 14:44:56, Kevin Meredith (kevin.m.mered...@gmail.com)
wrote:

Given the following on Scala 2.11.8:

import scala.concurrent.Future
import scala.concurrent.duration._
import scala.concurrent.Await
import scala.concurrent.ExecutionContext.Implicits.global

scala> def fut = {
 |   Thread.sleep(5000)
 |   Future(42)
 | }
fut: scala.concurrent.Future[Int]

Why does the following not throw a java.util.TimeoutException?

scala> Await.result( fut, FiniteDuration(1, SECONDS) )
res1: Int = 42

As I understand, Await#result will throw if the time-out, i.e. its second
argument, completes before the completion of the Future.

If that's true, then why does 42 return in the above example instead of an
exception?
--
>> 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: Understanding scala.concurrent.Await#result

[Kevin Meredith]

Note that the following works as I had expected, per my above stated 
understanding:

scala> def fut = Future { Thread.sleep(5000) }
fut: scala.concurrent.Future[Unit]

scala> Await.result( fut, FiniteDuration(1, SECONDS) )
java.util.concurrent.TimeoutException: Futures timed out after [1 second]
  at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)
  at scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:223)
  at scala.concurrent.Await$$anonfun$result$1.apply(package.scala:190)
  at 
scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:53)
  at scala.concurrent.Await$.result(package.scala:190)
  ... 32 elided


On Tuesday, November 22, 2016 at 8:44:53 AM UTC-5, Kevin Meredith wrote:
>
> Given the following on Scala 2.11.8:
>
> import scala.concurrent.Future
> import scala.concurrent.duration._
> import scala.concurrent.Await
> import scala.concurrent.ExecutionContext.Implicits.global
>
> scala> def fut = {
>  |   Thread.sleep(5000)
>  |   Future(42)
>  | }
> fut: scala.concurrent.Future[Int]
>
> Why does the following not throw a java.util.TimeoutException?
>
> scala> Await.result( fut, FiniteDuration(1, SECONDS) )
> res1: Int = 42
>
> As I understand, Await#result will throw if the time-out, i.e. its second 
> argument, completes before the completion of the Future.
>
> If that's true, then why does 42 return in the above example instead of an 
> exception?
>

-- 
>>  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] Understanding scala.concurrent.Await#result

[Kevin Meredith]

Given the following on Scala 2.11.8:

import scala.concurrent.Future
import scala.concurrent.duration._
import scala.concurrent.Await
import scala.concurrent.ExecutionContext.Implicits.global

scala> def fut = {
 |   Thread.sleep(5000)
 |   Future(42)
 | }
fut: scala.concurrent.Future[Int]

Why does the following not throw a java.util.TimeoutException?

scala> Await.result( fut, FiniteDuration(1, SECONDS) )
res1: Int = 42

As I understand, Await#result will throw if the time-out, i.e. its second 
argument, completes before the completion of the Future.

If that's true, then why does 42 return in the above example instead of an 
exception?

-- 
>>  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.