cloudfoundry / cloudfoundry/cf-java-client
CF V3 getProcessStatistics - The threads are not released
Personne n'a encore pris cette issue.
- Langage dominant
- Java
- Étoiles
- 334
- Forks
- 319
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
@twoseat I am tagging you directly as the issue still exists.
we have about 70 microservices running in the cloud foundry & we would like to monitor all the microservices with the following metrics,
- State
- Memory utilization
- CPU Utilization
- Disk Utilization
recently, I started to use CF v3 API & the issue is still the same. The allocated threads are not released, Due to which the application crashes multiple times a day.
The below API is called once every 5 minutes for about 70+ microservices
public void requestAllApplicationStatistics(DefaultCloudFoundryOperations cloudFoundryOperations, List<CfArtifacts> cfArtifacts) {
initializeTaskExecutor();
Flux.fromIterable(cfArtifacts)
.flatMap(application -> cloudFoundryOperations.getCloudFoundryClient().applicationsV3()
.getProcessStatistics(GetApplicationProcessStatisticsRequest.builder()
.applicationId(application.getId())
.type("web")
.build())
.map(response -> {
logger.debug("step 1 - cfStatistics fetched successfully");
CfApplicationResponse cfApplicationResponse = new CfApplicationResponse();
cfApplicationResponse.setApplicationId(application.getName());
cfApplicationResponse.setCfApplicationId(application.getId());
cfApplicationResponse.setPrefix(application.getPrefix());
List<ProcessStatisticsResource> resourceList = response.getResources();
cfApplicationResponse.setApplicationInstances(resourceList);
logger.debug("step 2 - cfStatistics before calling the callback");
return cfApplicationResponse;
})
.doOnError(e -> {
logger.error("cfStatistics Fetch Failed with error: {}", e.getMessage(), e);
})
.doFinally(signalType -> {
logger.debug("All applications processed. Shutting down the executor service.");
// shutdownTaskExecutor(); // Shutdown the executor service
})
)
.subscribeOn(Schedulers.fromExecutor(taskExecutor))// Use the shared task executor
.publishOn(Schedulers.fromExecutor(taskExecutor)) // Use the shared task executor
.doOnNext(cfResponseCallback::processCfMetrics)
.subscribe(); // Subscribe to start the execution
}
private static synchronized void initializeTaskExecutor() {
if (taskExecutor == null) {
taskExecutor = new ThreadPoolTaskExecutor();
taskExecutor.setCorePoolSize(10); // Set the desired core pool size
taskExecutor.setMaxPoolSize(20); // Set the desired maximum pool size
taskExecutor.setThreadNamePrefix("cf-task-executor-"); // Set a thread name prefix
taskExecutor.initialize(); // Initialize the task executor
}
}
Look at the active threads in the below screenshot, it keeps increasing & crashes (the screenshot was captured from the Health Monitoring on the total threads measured by java Open telemetry instrumentation)
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par le point d’entrée applicationsV3().getProcessStatistics et examinez l’issue 1054 ainsi que l’utilisation signalée de requestAllApplicationStatistics. Comme aucun fichier du dépôt ni aucun test n’est identifié dans l’issue, localisez d’abord l’implémentation et les tests existants, puis reproduisez les appels répétés. La fin du travail doit être démontrée par un test de régression montrant que le nombre de threads n’augmente plus une fois les demandes de statistiques terminées.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- java
- Domaine
- api
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 30/100