Simple question: How do you set akka.http.client.idle-timeout on a
per-request basis?
Thanks,
--
Alan Burlison
--
--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
/247 for the details. With that
in place, the routing logic for processing looks similar to this
outline, where JobFinishedMsg is a protobuf message:
path("job_finished") {
post {
entity(as[JobFinishedMsg])(msg => {
log.debug("received message {}", msg.id)
basically useless and you were forced to use the BUI.
--
Alan Burlison
--
--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will s
, not just Akka, is that correct?
As I read it, the advice on that page is "Don't use the mailing list
functionality" so I'm a bit surprised to see it being recommended here.
--
Ala
://groups.google.com/forum/#!searchin/akka-user/discuss$20%7Csort:date
- oh look, a searchable archive!) but you've done so anyway. The lack of
discussion (pun intended) doesn't exactly send a positive message to
your community.
--
Alan Burlison
nd.com site it's clear that
Lightbend have made a corporate-level decision to abandon mailing lists
and switch to Discourse, presumably because the PHBs think Facebookising
the interactions between Lightbend and their community looks prettier.
That's a shame, as I certainly won't be using
ed 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-us
y 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
On 01/03/18 10:56, Konrad “ktoso” Malawski wrote:
Ping in one place is enough, reopened :-)
Ta, first reply wasn't to the email I intended it to be ;-)
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional
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
On 01/03/18 10:44, Konrad “ktoso” Malawski wrote:
Thanks, I’ll close the one I had opened then
Ok, sorry - I didn't realise you'd already opened one :-)
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional
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
On 01/03/18 01:24, Konrad “ktoso” Malawski wrote:
Thanks again, hope the TCP one will be fine for you for now in any case?
Yes, in fact it's probably a better choice anyway as the message rate is
low.
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ
On 01/03/18 01:37, Konrad “ktoso” Malawski wrote:
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.
Done, thanks :-)
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs
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 becaus
recorder and continue debugging the underlying
Artery issue, my current suspicion is it is related to the communication
mechanism used with the Aeron Media Driver.
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional
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
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://do
I didn't realise you could tag things to exclude, 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
serialization = off` was set!
Message type was: [class akka.actor.ActorSelection$$anon$1]
Doesn't this mean that "akka.actor.serialize-creators" is pretty much
useless in practice?
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io
imply
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
, 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
OK, makes sense - thanks for the explanation :-)
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http
lled 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 th
no "proper" way of forcing the addition of the
charset to the application/json content type in Akka-HTTP but it is
possible to hack around it:
val ct = ContentType(MediaType.custom("application/json",
false).asInstanceOf[MediaType.WithOpenCharset], HttpCharset.custom("ut
can
examine and manipulate the persisted Actor data using other tools, which
is extremely useful during development.
--
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
into those. Plus I
couldn't see any way of getting the name of the field that was being
deserialised just using the Akka-HTTP exception handling mechanism. But
yes, starting from scratch it is probably a bit daunting.
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check
} else {
super.toResponse
}
}
That way the JSON deserialization errors are handled as normal
completions rather than using a specific Akka-HTTP exception handler.
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/cu
tor/FunctionRef;
at akka.stream.stage.GraphStageLogic$StageActor.(GraphStage.scala:142)
at akka.stream.stage.GraphStageLogic.getStageActor(GraphStage.scala:929)
...
Thanks for your help :-)
--
Alan Burlison
--
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>&
developers? The
closest match I've been able to find is
https://bugs.openjdk.java.net/browse/JDK-8141566 but I'm not certain it
is the same issue. Are the benchmarks used in 22560 available from
somewhere?
Thanks,
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ
I noticed this from the 2.5.0 release notes:
- Fix performance regression for Scala 2.12, due to change in scheduling
fairness of the JDK8 ForkJoinPool implementation
Is there a bugid for this? What is the change in the JDK ForkJoinPool
that caused the problem?
Thanks,
--
Alan Burlison
esafe.akka:akka-parsing_2.12:10.0.5, default:sim_2.12:1.0,
com.typesafe.akka:akka-stream_2.12:2.4.17 (),
com.typesafe.akka:akka-persistence_2.12:2.5.0)
[info] Here are other libraries that were evicted:
[info] * com.typesafe:config:1.2.0 -> 1.3.1 (caller:
com.typesafe.akka:akka-actor_2
is that Sink.head[T] materializes into a Future[T] so the response
will be completed asynchronously when delay duration elapses.
That's not an approach that occurred to me as I haven't played with
streams - thanks, I'll investigate.
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs
it that doesn't require reflection to
enumerate the fields in the case class that the JSON is being
unmarshalled in to. And although I've used Spray/JSON quite a bit I have
no idea how the case class/tuple marshalling/unmarshalling stuff works.
--
Alan Burlison
--
--
Read the docs: http
it to reject unrecognised fields,
or is it a case of having to switch to a different framework? I'm also
using Spray/JSON to implement Akka persistence and I don't want to have
2 JSOn frameworks in the same app, so switching to another JSON
framework would not be trivial.
Thanks,
--
Alan Burlison
ed. I
can't find any obvious way of doing this, is there one?
Thanks,
--
Alan Burlison
--
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka
Scheduler
(http://doc.akka.io/docs/akka/current/scala/scheduler.html) to send a
message back to the HTTP actor after a delay containing the response to
send back to the client, but I'm wondering if there's a smarter way to
do this?
Thanks,
--
Alan Burlison
--
--
Read the docs: http
faster in the error case although I haven't
tested that. I think it would be a simple addition to make to the
PathMatcher DSL but that's not my call :-)
--
Alan Burlison
--
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>>
def apply(path: Path) = if (path.head == segment)
Matched(path.tail, ()) else Unmatched
}
Then you can say:
pathPrefix(seg("someseg"))
If that gets a nod of approval from the Akka HTTP folks I'll figure
out to log a RFE.
--
Alan Burlison
--
--
>>>>>>>>
isting PathMatcher DSL so it can be used with the path
and pathPrefix directives, and I'm not sure of how to do that.
--
Alan Burlison
--
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>
mentation that it is deliberate - I have no
idea why it was considered to be a good design, if indeed it was.
I'm trying to figure out how to write my own implementation of
Segment("foo") to allow complete matching of a path segment, but it's
not easy as the DSL implementation is pretty
choice), would it be possible to add
a matcher DSL item that specifically matched a complete path segment?
There's already 'Segment', could that be extended to take a segment to
fully match against, e.g. 'Segment("foo")' ?
--
Alan Burlison
--
--
>>>>>>>>>>
t;.r would match "foobar", "foobaz" etc
and extract "bar" and "baz".
Currently a string of "foo" will *also* match "foobar", "foobaz" but
won't extract the "bar" or "baz" suffix, which seems almost certainly
pathPrefix("root") {
I can bodge around this with:
pathPrefix("^root$".r)
but that's unspeakably vile.
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
Search
lines of
segment() where that fully matches just the next path segment and leaves
the remaining path to be matched by inner routes, but there doesn't seem
to be such a thing.
What am I missing?
Thanks,
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http:/
will increase but I have no
reason to believe I won't be able to support many hundreds of emulated
services from a single JVM, and there's Akka clustering for beyond that.
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/curr
Anyone have any suggestions? Thanks!
On 07/03/17 22:32, Alan Burlison wrote:
I have an Akka HTTP route for a REST API that first checks the base path,
then checks the user authentication is valid, adds some custom headers and
extracts the base URI before processing the sub-routes. However
the docs
(I mean http://doc.akka.io/docs/akka/current/scala/persistence.html
rather than the scaladocs) could be tweaked slightly to make the
distinction clear?
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional
.
--
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 "
On 08/03/17 14:03, Alan Burlison wrote:
That's not in the docs, it's just a source code comment - I'd have thought
it was important enough a restriction to be in the scaladocs?
Also, if BackoffSupervisor shouldn't be used with PersistentActors, what is
the correct way of dealing with IO
is
the correct way of dealing with IO failures in persistent actors?
--
Alan Burlison
--
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/
Route.seal(concat(
pathEndOrSingleSlash { topRoute(sess, baseUri) },
pathPrefix("users") { userRoute(sess, baseUri) }
))}
}
}
}
--
Alan Burlison
--
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>&
. And as you say, there are layers
on top of Akka which add higher-level functionality if you need it.
--
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
e "toolbox" approach of Akka but it can be a bit
daunting to be given a box of spanners and then be expected to go build
a car ;-)
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
Search
On 21/02/2017 12:20, Viktor Klang wrote:
Perhaps it was implicit but I assumed that the question was how to not
process any new information until the response had been received, otherwise
you're just use pipeTo and be done with it?
Ah, got you - thanks for the clarification.
--
Alan Burlison
, but the performance I'm getting from the Persistence TCK
benchmark is more than adequate for my needs - ~62k records/second, so I
didn't bother, plus I noticed that other existing Persistent Journal
implementations do serialization in the same way.
Thanks,
--
Alan Burlison
--
--
Read the docs
in this scenario though?
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
actor in a subsequent message. I got rid of the need to use await
by just pushing the calculation down into the actor. The takeway I got
from that was that if you find yourself using await you probably need to
think again about your design.
--
Alan Burlison
--
--
Read the docs: http
On 20/02/2017 12:01, Viktor Klang wrote:
No. I'd recommend to use stashing, makes the cost explicit.
Could you expand on what you mean by "stashing"?
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additiona
> This is not a solution because it creates one new thread for every blocker.
In general I agree, but if the code has already aggregated all the
futures into a single one, as seems to be suggested in an earlier
email, wouldn't it be an option - albeit not an ideal one?
--
Alan Burli
olutions.net/teamblogs/demystifying-the-blocking-construct-in-scala-futures
Probably best avoided if at all possible, though.
--
Alan Burlison
--
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> C
using is nothing
special, 2Ghz i5 laptop, laptop HDD for storage.
--
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
to replicate...
--
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
again in IDEA then the error is gone and the application
runs fine, so it seems like there was a problem with the akka-stream
dependency
Most odd.
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
t;leveldbjni-all" % "1.8",
"com.typesafe.akka" %% "akka-persistence-tck" % "2.4.17" % "test"
)
I don't know how to get the dependency graph, if it's needed let me know
what to do.
--
Alan Burlison
--
--
Read the docs: htt
ctorSystem$.apply(ActorSystem.scala:242)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:288)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:233)
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additiona
On 01/02/2017 10:19, Viktor Klang wrote:
Try(block).fold(Status.Success(_), Status.Failure(_))
Neat, I wasn't aware of that - it appeared in 2.12:
https://issues.scala-lang.org/browse/SI-8336
Ta :-)
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http
o, reader) }
IIRC akka.actor.Status.Success was created aeons ago,
scala.util.Success was added with scala.util.Try, so they have
separate origins. (just like java.util.List and
scala.collection.immutable.List)
Ah, the curse of history :-) Sounds completely plausible - thanks.
--
Alan Burlison
--
--
the JSON serialization directly inside the journal.
That might be one way of doing what you want - don't use the Akka
mechanism for configuring & looking up the serializer, just do it
explicitly inside the journal implementation?
--
Alan Burlison
--
--
Read the docs: http
us.Success, or should I just do
it with a match expression? What I'm doing is wrapping the IO functions
that could fail in a "Try { ??? }" and returning the result to the
calling actor.
Is there a reason why there's both scala.util.Success and an
akka.actor.Status.Success?
--
Alan Burlis
On 31/01/17 23:34, Viktor Klang wrote:
I think the problem is that your responding with a scala.util.Success
rather than a akka.actor.Status.Success.
Ahah! I think you may of nailed it... Thanks!
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http
and when I looked at the mapTo
implementation it was going to throw an exception as well, which is why
I settled on the map alternative - but that didn't feel quite right
either, hence the question. Thanks for the confirmation that's the right
approach.
--
Alan Burlison
--
--
Read the docs
n't missed anything obvious.
However that's a bit clunky - the method in the actor returns a
Future[Unit], by the time it gets back to the "ask"ing Actor is has been
converted to a Future[Any] and then you have to map it back to a
Future[Unit] again.
--
Alan Burlison
--
--
Read t
works, but sort of
smells a bit.
Is there a cleaner way of doing this?
--
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 m
is for
debugging and for a simulation application, where the journal files will
be post-processed outside of the simulation.
--
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
they are managed per-file.
As I said I was sure I was missing something obvious, I just couldn't
see what - thanks for pointing me in the right direction :-)
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional/
that seems very
restrictive. If not, how do you create multiple instances of persistent
actors without having duplicate persistence IDs?
// Hope this helps, typed in a rush on an airplane
It does, thank you - as I said I thought I was missing something obvious :-)
--
Alan Burlison
--
--
there
is a problem - or is it (sequenceNr, writerUuid)? And if so, why doesn't
AsyncWriteJournal.asyncReplayMessages take writerUuid as a parameter?
I suspect I'm missing something blindingly obvious here, but for the
life of me I can't see how this is supposed to work.
--
Alan Burlison
a-persistence).
Ahah, that's the bit I was missing - where they were used. Thanks :-)
https://github.com/akka/akka/blob/v2.4.16/akka-persistence/src/main/scala/akka/persistence/journal/EventAdapter.scala#L39
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://
/akka/persistence/cassandra/journal/CassandraJournal.scala#L392
Why is is the PersistentRepr one saved? I don't seem to be able to
find it being used anywhere.
Thanks,
--
Alan Burlison
--
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>&
further question - I see mention in the docs and source of tags, I
don't think it's something I'll need, at least not initially. I assume
it's OK to just leave it all unimplemented?
Thanks again for the help and pointers,
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs
- they tell you about the API but I haven't been able
to find any information about how you hook it up with the serializer,
for example.
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
Search
to find one.
You did not mention which datastore you're using, which is very very
relevant to this question.
Flat file, JSON content.
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
Search
thing would write to persistent storage here
println(new String(bytes))
}
Future.successful(Nil)
}
How do I get the *entire* payload that's stored in the journal saves
in JSON via my custom serializer?
Thanks,
--
Alan Burlison
--
--
>>>>>>>>>>
Apache Derby and use
that for persistence, but that's still really overkill.
--
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
?
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
> I added this to the docs in case it wasn't obvious at first sight:
> https://github.com/akka/akka-http/pull/744
Works a treat, thank you :-)
--
Alan Burlison
--
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>
I have a rejection handler that handles non-existent paths via
handleNotFound. However I can't seem to find an obvious way of
accessing the path in question so it can be displayed/logged by the
handler. Is there a way?
--
Alan Burlison
--
--
>>>>>>>>>> Read
On 07/01/2017 16:31, Patrik Nordwall wrote:
That is for the c++ client as far as I know, and that is not used by Akka.
Ah, good to hear, thank you for the clarification :-)
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka
that Aeron had a JNI dependency was the mention of
C++ and CMake. If that's just an optional requirement, great :-)
--
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
is performance. There are other cases
where the focus is on cross-platform rather than performance, a
pure-Java is going to be preferable in those cases.
--
Alan Burlison
--
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional
Gah, yes, clicked on the wrong goddam doc link, sorry for the noise,
time to go to bed I think...
The continual "{}" nesting in the Scala DSL get's messy pretty quickly...
--
Alan Burlison
--
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>
;)));
too many arguments (2) for method path: (pm:
akka.http.scaladsl.server.PathMatcher[L])akka.http.scaladsl.server.Directive[L]
val route1 = path("foo", () ->
The "() ->" idiom that I've also seen elsewhere in the documentation
doesn't seem to work?
gt; provide(l)
case Success(None) => reject(AuthRejection("invalid credentials"))
case Failure(e) => reject(AuthRejection("internal error"))
}
}
}
def combinedAuth = authBasicHttp | authXHeader | authXSession
--
Alan Burlison
--
--
Read the docs: http://akka.
:-)
--
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
("X-Auth-User") &
headerValueByName("X-Auth-Key")).tflatMap { up =>
onComplete(authenticateUserPass(up._1, up._2)).flatMap {
case Success(s) => provide(s)
case Failure(ex) => reject()
}
}
seems to be what is required.
--
Alan Burlison
-
doesn't compile as the resulting value of type Directive[(String,
String)] doesn't have a flatMap. Do you mean tFlatMap?
--
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.googl
t or a rejection is completely unclear to me.
I must say that I'm finding the high level Akka-HTTP API rather
difficult to use, for simple cases it all looks so easy but as soon as
you step outside of that it immediately gets incredibly complicated
:-/
--
Alan Burlison
--
--
>>>>>>>&
quot;X-Auth: $user") } ~
headerValueByName("X-Auth-Session") { session => complete(s"Session: $session")
What's missing for the second two is the actual validation of the
user/pass or token.
Thanks,
--
Alan Burlison
--
--
>>>>>>>>>>
I've done a bit more investigation and it appears that the Akka
behaviour is correct HTTP/1.1 behaviour, which says that connections
should be persistent by default and that the "Connection: Keep-Alive"
header isn't needed. I was comparing to another REST service which
seems to get it wrong and
On Saturday, 24 December 2016 12:15:58 UTC, Konrad Malawski wrote:
Share your code. What are you doing and what's the expected outcome.
>
> It's the demo code from
http://doc.akka.io/docs/akka-http/current/scala/http/introduction.html#routing-dsl-for-http-servers.
The response I'm getting is:
1 - 100 of 101 matches
Mail list logo