Closed jfenner closed 9 years ago
When eureka first starts up without peers it takes about 5 mins for it to start serving requests because it waits for all clients to register completely before it can give out the list. You can disable this by setting this
eureka.waitTimeInMsWhenSyncEmpty=0
In a production environment, it is recommended that you don't set this property. You might want to revert the other property changes above as they are unrelated.
Hi Karthik-vn,
Thanks for the reply. I'm actually already setting that parameter, but it doesn't seem to make a difference. Here's what I have for a config:
Tomcat setenv.sh:
export JAVA_OPTS="$JAVA_OPTS \
-Deureka.enableSelfPreservation=false \
-Deureka.registration.enabled=false \
-Deureka.environment=dev \
-Deureka.datacenter=ndc"
echo $JAVA_OPTS
And my eureka-server.properties (masked):
#Set this only for this sample service without which starting the instance will by default wait for the default of 5 mins
eureka.waitTimeInMsWhenSyncEmpty=0
#AWS access key which has access to EIP binding and looking up autoscaling information
eureka.awsAccessId=*****
eureka.awsSecretKey=******
@next=eureka-${environment}-${region}.properties
And finally eureka-server-dev.properties (masked):
#AWS access key which has access to EIP binding and looking up autoscaling information
eureka.awsAccessId=******
eureka.awsSecretKey=*******
@jfenner - this might sound silly, but are you rebuilding the eureka-server webapp with the new properties being set?
also, you might want to try setting those -D's in the actually eureka-server.properties file itself.
here's a link to my FluxCapacitor Netflix OSS FAQ that describes this issue: https://github.com/cfregly/fluxcapacitor/wiki/NetflixOSS-FAQ#eureka-service-discovery-load-balancer
The eureka.registration.enabled=false should have taken care of the problem (it has for others), so i wonder if those -D's aren't being picked up for some reason.
i just added karthik's recent suggestion of setting eureka.waitTimeInMsWhenSyncEmpty=0 to the FAQ as i hadn't heard of that before.
lemme know if that helps.
-chris
I'm also seeing this, even with eureka.waitTimeInMsWhenSyncEmpty
set to 0
. While this is hard to see with Tomcat, attempting to run under Jetty shows a tremendous number of stack traces as Eureka server tries and fails to connect to itself with the Eureka client, presumably because it's still attempting to come up.
@NiteshKant @cfregly @karthik-vn This is actually happening in EurekaBootStrap.contextInitialized
, when it calls registry.syncUp()
(roughly line 102, depending on which PRs are merged when you look this up). syncUp()
will sleep up to, by default, five times, for 30 seconds, until it can find a peer to register with. There's your 3-5 minute start-up time with the default .properties
files.
There are two possible fixes to this:
eureka.numberRegistrySyncRetries
to 0
for debuggingeurekaServer.testingMode
, that bypasses the initial syncUp
call entirely.The first is obviously less work, but second's also pretty simple. Thoughts?
@bpollack I personally like the option 2. so that there is less configuration to set. In fact we should be able to support starting the servers with no eureka peers configured. This would automatically remove all these issues. Thoughts?
@NiteshKant Hmm, I like your idea. Will quickly whip up a PR in that style for feedback.
To eliminate syncUp just set eureka.numberRegistrySyncRetries=0
. Once it is set, the server starts up instantly.
I propose to close this issue, as there was no follow up on it for some time, and there is alternative approach to achieve this goal.
When starting Eureka in a dev environment with no other Eureka servers available, the startup times takes between 3 and 5 minutes. I was that setting the following parameters would bypass this:
eureka.enableSelfPreservation=false eureka.registration.enabled=false
However, it still is taking 3-5 minutes. Is there something else that needs to be set for this to work?