These are chat archives for spring-cloud/spring-cloud

26th
Jul 2016
David Steiman
@xetys
Jul 26 2016 12:01

hey @dsyer . What I had uploaded yesterday contains a dumb error done by me. I tried it to solve that with only one application. Finally netflix feign works perfect fixing my error. Finally i ended up to reconstruct that 3 application setup, and this time it really works....

i wrote one shell script starting everyting in the right order, to make this comfortable to test....i hope you got no problems with gradle :D

Dave Syer
@dsyer
Jul 26 2016 12:15
I didn't try it yet if I'm honest
So it's working, and I don't need to?
David Steiman
@xetys
Jul 26 2016 12:16
in short: using feign clients with eureka and ribbon breaks the option of using two clients with different requestinterceptors. it takes "one for all"....
i found that bug using oauth2 and feign, but also reconstructable with basic auth
it's ok
if I tell a direct url, it's ok
but with loadbalancing something happens with bean wiring inside
no, it is not working.....i needed harder conditions to pull this bug out from it's cave
to make that 3 application setup easier to test, there is a simple script inside starting everyting in the right order, telling something about why things are failing and so on
Dave Syer
@dsyer
Jul 26 2016 14:30
I doubt we really need eureka and multiple processes to verify such a simple bug
I'll look at it now
Dave Syer
@dsyer
Jul 26 2016 15:06
Indeed it is so. I can reproduce the same problem with your consumer app on its own, if I just add the producer endpoints to it.
There's no need for eureka or docker or even the second app
It's because you have 2 Feign clients with the same name, but different configuration.
The configuration is actually keyed on the name.
So that's kind of a feature.
I'll comment on your gh issue
Matt Benson
@mbenson
Jul 26 2016 16:37
@dsyer could you confirm that if I'm wanting to test the cloud bus over Kafka, that springCloudBusInput and springCloudBusOutput are the proper queue names
David Steiman
@xetys
Jul 26 2016 16:39
ahh, i see
i didn't see it this way, that its also the feign clients name, i was thinking more of the service instance id
But I wouldn't expect you'd have to know that explicitly.
(I don't think they are called "queues")
(but the names are what you said)
Matt Benson
@mbenson
Jul 26 2016 16:46
having trouble connecting for some reason so I'm trying to poke around with Kafka CLI tools
Thanks
Dave Syer
@dsyer
Jul 26 2016 16:47
The physical name in the broker is controlled by the binder
Matt Benson
@mbenson
Jul 26 2016 16:47
That's where I took the names from, just making sure I was reading that correctly
thanks for the tip
Dave Syer
@dsyer
Jul 26 2016 16:47
AFAIK the physical names are the same as the logical ones in SCS 1.0.
(and 1.1)
Matt Benson
@mbenson
Jul 26 2016 17:32
Actually I found the kafka-topics script and saw that there is a topic simply called springCloudBus; grepped that from spring-cloud-bus and found that in BusProperties... so it looks like the bus I/O channels both write to a single BindingProperties destination
Dave Syer
@dsyer
Jul 26 2016 17:45
Sounds plausible. I don't think there's any need for more than one physically
turick
@turick
Jul 26 2016 17:59
hi all, still working on my zuul/security/session issues. i think i've made progress... if i hit my back-end service directly, the session cookie in my browser matches session ID in the HttpSession object, which matches the entry in redis. however, whenever i access my service through zuul, the cookie id in the browser will match the session id in zuul (and in redis), but once it forwards it to my service it creates a new session id and adds an additional session to redis. With each request, the service reports a new session id and another session appears in redis. oddly enough, however, the service still picks up the proper principal and authentication from zuul. does anybody have any ideas what may be causing all of the additional sessions?
Dave Syer
@dsyer
Jul 26 2016 18:08
Is it all on the same host?
turick
@turick
Jul 26 2016 18:08
yes sir, just different ports
i'm modifying my config to line up with what you specified now...
Dave Syer
@dsyer
Jul 26 2016 18:09
Probably they are all sharing the same cookie then?
Notice the way the cookie in the auth server has a different path n the tutorial/blog
turick
@turick
Jul 26 2016 18:12
yes. i'm running in a private window each time to make sure i'm getting a new cookie with each test, but if i switch from using localhost to my hostname in the url, it re-prompts for my credentials. i did notice that the path for the cookie in my browser is simply "/" even though i'm going to "http://localhost:8081/geoserver/ows?....."
Dave Syer
@dsyer
Jul 26 2016 18:36
It's the path that's the problem probably
You have multiple apps all issuing cookies for localhost and the same path
Matt Benson
@mbenson
Jul 26 2016 18:38
anyone have any idea why the spring-cloud-stream-binder-jms repo is empty?
Dave Syer
@dsyer
Jul 26 2016 18:42
Because there's no code?
Matt Benson
@mbenson
Jul 26 2016 18:54
Enlightening ;P ... the implied question was why there is no code and whether it is planned for that to change
turick
@turick
Jul 26 2016 19:01
hmmm.. isn't that what spring session is supposed to do though? create the session once and share it amongst all services and not create more sessions/cookies at each service?
Dave Syer
@dsyer
Jul 26 2016 19:36
Yes, that's what spent session does. But each app has its own cookie/session. You have 2 apps with the same cookie (I think).
turick
@turick
Jul 26 2016 19:49
you're correct
i deployed the edge on a different server
so what i see now is a cookie with the path / and a cookie with the path /geoserver/
the /geoserver/ cookie matches with the session id on geoserver
of which i have 2 instances... no more creation of extra session ids
thanks for helping with this @dsyer -- i would not have thought that's how things worked
turick
@turick
Jul 26 2016 21:01
although i'm still experiencing the issue where i'm authenticating with http basic on the edge service and that authentication is stored in that session, then when i get proxied on to geoserver, geoserver creates it's own session and considers me an anonymous user
checketts
@checketts
Jul 26 2016 21:24
@spencergibb With Config Server I'm trying use an encrypted value like {cipher}{key:firstKey}23409a8ce908ce0a9c88c09 in the application.yml file in our config server repo. My config server is in spring.cloud.config.server.bootstrap: true mode and config server is failing to decrypt that value (it's working if a profile is present like application-prod.yml or if I don't use a named key). Is this an expected feature? Or should it support named keys?
Oops, I see @spencergibb hasn't been active for a bit (just tweeting photos of Mt Rushmore) @dsyer Would you know the answer to my question?