-
Notifications
You must be signed in to change notification settings - Fork 1.2k
[New Scheduler] Implement FPCInvokerReactive #5125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,45 @@ | ||
/* | ||
* Licensed to the Apache Software Foundation (ASF) under one or more | ||
* contributor license agreements. See the NOTICE file distributed with | ||
* this work for additional information regarding copyright ownership. | ||
* The ASF licenses this file to You under the Apache License, Version 2.0 | ||
* (the "License"); you may not use this file except in compliance with | ||
* the License. You may obtain a copy of the License at | ||
* | ||
* http://www.apache.org/licenses/LICENSE-2.0 | ||
* | ||
* Unless required by applicable law or agreed to in writing, software | ||
* distributed under the License is distributed on an "AS IS" BASIS, | ||
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
* See the License for the specific language governing permissions and | ||
* limitations under the License. | ||
*/ | ||
|
||
package org.apache.openwhisk.core.ack | ||
|
||
import org.apache.openwhisk.common.{Logging, TransactionId} | ||
import org.apache.openwhisk.core.connector.{AcknowledegmentMessage, MessageProducer} | ||
import org.apache.openwhisk.core.entity.{ControllerInstanceId, UUID, WhiskActivation} | ||
import spray.json.DefaultJsonProtocol._ | ||
|
||
import scala.concurrent.{ExecutionContext, Future} | ||
|
||
class HealthActionAck(producer: MessageProducer)(implicit logging: Logging, ec: ExecutionContext) extends ActiveAck { | ||
override def apply(tid: TransactionId, | ||
activationResult: WhiskActivation, | ||
blockingInvoke: Boolean, | ||
controllerInstance: ControllerInstanceId, | ||
userId: UUID, | ||
acknowledegment: AcknowledegmentMessage): Future[Any] = { | ||
implicit val transid: TransactionId = tid | ||
|
||
logging.debug(this, s"health action was successfully invoked") | ||
if (activationResult.response.isContainerError || activationResult.response.isWhiskError) { | ||
val actionPath = | ||
activationResult.annotations.getAs[String](WhiskActivation.pathAnnotation).getOrElse("unknown_path") | ||
logging.error(this, s"Failed to invoke action $actionPath, error: ${activationResult.response.toString}") | ||
} | ||
|
||
Future.successful({}) | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -155,6 +155,7 @@ whisk { | |
#aka 'How long should a container sit idle until we kill it?' | ||
idle-container = 10 minutes | ||
pause-grace = 50 milliseconds | ||
keeping-duration = 60 minutes | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this the same thing as the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For different configuration.
|
||
} | ||
action-health-check { | ||
enabled = false # if true, prewarm containers will be pinged periodically and warm containers will be pinged once after resumed | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe have infects for non-scheduler codes?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes,infects below codes
If don't want to infect above code, one option is
make the keepingCount and keepingTime value
to a fixed value this time rather thanread from db
, e.g.But there has a problem that all frequent invocation actions will exist at least
1
container in 60.seconds both, obviously, this is a waste of resourcesif add above 2 fileds, the benefit is, these 2 values can be configured from db, because these 2 value is for
namespace
, so one namespace's all actions complete for thiskeepingCount
value.So my opinion is, in spite of infect the non-scheduler code, it is better to add above 2 fields to
case class UserLimits
,anyway, the non-scheduler codes can run well in spite of infect the codes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bdoyle0182 @style95 ,due to above 2 fields(warmedContainerKeepingCount, warmedContainerKeepingTimeout) are added into
case class UserLimits
, do you guys have any opinion?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not opposed to infecting non-scheduler code where absolutely necessary. I think it's unreasonable to suggest we can make such a large architectural change without touching existing code at all. So long as we're avoiding a breaking change I see no issue with this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ningyougang @style95 also sorry haven't had time to dedicate to the scheduler recently, but will review the remaining existing pr's this week
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bdoyle0182 ,thanks for you review, just add 2 fields to
case class UserLimits
, it is nota large architectural change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea I just meant the entire new scheduler is
a large architectural change
so it's unreasonable to say we can't ever touch other components while implementing. We should avoid where possible, but it will be necessary in a couple situations like this one.