yhs0092 commented on code in PR #4837: URL: https://github.com/apache/servicecomb-java-chassis/pull/4837#discussion_r2137339631
########## foundations/foundation-vertx/src/main/java/org/apache/servicecomb/foundation/vertx/http/FileUploadStreamRecorder.java: ########## @@ -0,0 +1,174 @@ +/* + * 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.servicecomb.foundation.vertx.http; + +import java.io.IOException; +import java.util.ArrayList; +import java.util.Comparator; +import java.util.List; +import java.util.Map; +import java.util.concurrent.ConcurrentHashMap; +import java.util.concurrent.Executors; +import java.util.concurrent.ScheduledExecutorService; +import java.util.concurrent.TimeUnit; +import java.util.stream.Collectors; + +import org.apache.servicecomb.foundation.common.event.EventManager; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +import com.google.common.eventbus.EventBus; +import com.netflix.config.DynamicPropertyFactory; + +public class FileUploadStreamRecorder { + private static final Logger LOGGER = LoggerFactory.getLogger(FileUploadStreamRecorder.class); + + private static final FileUploadStreamRecorder RECORDER = new FileUploadStreamRecorder(); + + private static final String STREAM_OPEN_UPPER_LIMIT = "file.upload.stream.operate.upper-limit"; + + private static final String STREAM_STACKTRACE_ENABLED = "file.upload.stream.operate.stack-trace-enabled"; + + private static final String STREAM_CHECK_INTERVAL = "file.upload.stream.operate.check-interval"; + + private static final int DEFAULT_STREAM_OPEN_UPPER_LIMIT = 1000; + + private static final long DEFAULT_STREAM_CHECK_INTERVAL = 30000L; + + private final Map<InputStreamWrapper, StreamOperateEvent> wrapperRecorder = new ConcurrentHashMap<>(); + + private final EventBus eventBus; + + private final ScheduledExecutorService streamCheckExecutor; + + private FileUploadStreamRecorder() { + eventBus = EventManager.getEventBus(); + streamCheckExecutor = Executors.newScheduledThreadPool(1, (t) -> new Thread(t, "stream-operate-check")); + startCheckOpenStream(); + } + + private void startCheckOpenStream() { + streamCheckExecutor.scheduleWithFixedDelay(this::checkOpenInputStream, DEFAULT_STREAM_CHECK_INTERVAL, + getStreamCheckInterval(), TimeUnit.MILLISECONDS); + } + + public static FileUploadStreamRecorder getInstance() { + return RECORDER; + } + + public void recordOpenStream(final InputStreamWrapper wrapper) { + checkAndRemoveOldestStream(); + wrapperRecorder.put(wrapper, new StreamOperateEvent(wrapper)); + } + + private void checkAndRemoveOldestStream() { Review Comment: According to the current `checkAndRemoveOldestStream` logic, some cornor cases may not be handled well. For example, - if the business thread pool is large enough, - or the controller is developed in the reactive mode, opening file stream and scheduling the stream into a backend thread pool to process (I mean the response `CompletableFuture` is completed when the backend task is finished), in these two cases, it's possible that more than 1000 file streams are opened in a short period, and `checkAndRemoveOldestStream` method closes the previously opened stream, and the business logic is affected. From the perspective of business developers, these are normal usecases but we break their business logic. To solve the problem perfectly, it seems necessary to subscribe the `InvocationFinishEvent` and establish the mapping relationships between `Invocation` and `StreamOperateEvent`, which increases the complexity. Or as a simpler solution, can we just set the default value of the max recorders size bigger ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
