firebase / firebase/firebase-admin-java
The firebase-admin-java 9.4.0 does not work with NIO (Non-blocking I/O).
- 主要言語
- Java
- スター
- 620
- フォーク
- 305
- 平均マージ
- 3時間 23分
- マージ済み PR(30日)
- 1
説明
### [READ] Step 1: Are you in the right place?
* For issues or feature requests related to __the code in this repository__
file a Github issue.
* If this is a __feature request__ make sure the issue title starts with "FR:".
* For general technical questions, post a question on [StackOverflow](http://stackoverflow.com/)
with the firebase tag.
* For general Firebase discussion, use the [firebase-talk](https://groups.google.com/forum/#!forum/firebase-talk)
google group.
* For help troubleshooting your application that does not fall under one
of the above categories, reach out to the personalized
[Firebase support channel](https://firebase.google.com/support/).
### [REQUIRED] Step 2: Describe your environment
* Operating System version: ubuntu
* Firebase SDK version: firebase-admin-java 9.4.0
* Library version: java 17
* Firebase Product: fcm
### [REQUIRED] Step 3: Describe the problem
Hello,
I am testing the firebase-admin-java SDK 9.4.0 with the following configuration:
```
FirebaseOptions options = FirebaseOptions.builder()
.setCredentials(googleCredentials(firebaseCredential, httpTransport))
.setDatabaseUrl(firebaseDatabaseUrl)
.setHttpTransport(httpTransport)
.setConnectTimeout(FIREBASE_CONNECT_TIMEOUT)
.setReadTimeout(FIREBASE_READ_TIMEOUT)
.setThreadManager(new CustomFirebaseThreadManager(
firebaseTaskExecutor.getThreadPoolExecutor()))
.build();
```
The reason I explicitly added ThreadManager is to monitor the ThreadPoolExecutor. Without this configuration, the ThreadPoolExecutor generated by FirebaseThreadManagers.DefaultThreadManager.doInit() will be used, which has a queue size of Integer.MAX_VALUE. If FCM responses are delayed, the queue can pile up, potentially causing an OOM (OutOfMemoryError).
Below is the configuration for H2AsyncClientBuilder:
```
H2AsyncClientBuilder h2AsyncClientBuilder = H2AsyncClientBuilder.create()
.setDefaultConnectionConfig(connectionConfig)
.evictIdleConnections(TimeValue.of(Duration.ofMinutes(10)))
.setDefaultRequestConfig(requestConfig())
.setIOReactorConfig(IOReactorConfig.custom()
.setSoTimeout(FIREBASE_READ_TIMEOUT, TimeUnit.MILLISECONDS)
.build())
.addRequestInterceptorFirst(
(HttpRequest request, EntityDetails entity, HttpContext context) -> {
activeStream.incrementAndGet();
if (context != null) {
context.setAttribute("startTime", System.nanoTime());
}
})
.addResponseInterceptorFirst(
(HttpResponse response, EntityDetails entity, HttpContext context) -> {
if (context == null || context.getAttribute("startTime") == null) {
return;
}
long startTime = Long.parseLong(context.getAttribute("startTime").toString());
long endTime = System.nanoTime();
if (startTime < endTime) {
Timer.builder(FCM_RESPONSE_TIMER_NAME)
.publishPercentiles(0.50, 0.95, 0.99)
.tags(
Lists.newArrayList(
Tag.of("host", ((HttpRoute) context.getAttribute("http.route")).getTargetHost().getHostName()),
Tag.of("http_version", context.getProtocolVersion().toString())
)
)
.register(meterRegistry)
.record(endTime - startTime, TimeUnit.NANOSECONDS);
}
activeStream.decrementAndGet();
})
.disableCookieManagement()
.setH2Config(H2Config.custom().setMaxConcurrentStreams(500 * 10).build())
.disableRedirectHandling()
.disableAutomaticRetries();
```
Here is the code for sending FCM messages. The postProcessExecutor is simply responsible for logging the send results:
```
ApiFuture responseApiFuture = firebaseMessaging.sendAsync(fcmMessage);
responseApiFuture.addListener(() -> {
try {
responseApiFuture.get();
message.setResponseCode(FcmResult.SUCCESS.getCode());
postProcessor.postProcess(MessageStatus.SENT, message);
} catch (Exception e) {
log ~~~
}
}, postProcessorExecutor);
```
When testing this, if I set a breakpoint inside addRequestInterceptorFirst (or addResponseInterceptorFirst) in the second code block, the thread executing addRequestInterceptorFirst is the httpclient-dispatch thread.
At this point, firebaseThreadPoolTask.getActiveCount() (as set in FirebaseOptions.builder().setThreadManager()) is 1.
In other words, it seems like the firebaseThread is staying active while the httpclient-dispatch thread is running.
I would like the behavior to work as follows:
The firebaseThread performs tasks (such as SDK validation) before the HTTP call.
After handing over to httpclient-dispatch, the firebaseThread is released.
The httpclient-dispatch makes the request to the FCM server, and the IO selector detects when a response is received.
Once the IO selector detects the response, it hands over to httpclient-dispatch, which processes operations like interceptors and then passes it to postProcessorExecutor.
This behavior should prevent the firebaseThread from getting blocked when the FCM server is down or latency is high.
If the firebaseThread gets blocked, it means that the queue in the thread pool fills up, which can lead to OOM or RejectedExecutionException.
If I have misunderstood anything, please let me know.
If my understanding is correct, how can I resolve this issue?
コントリビューションガイド
調査の方向性
まず、FirebaseOptions ThreadManager の設定と FirebaseThreadManagers.DefaultThreadManager.doInit() を通じて FirebaseMessaging.sendAsync を追跡します。interceptors で説明されている httpclient-dispatch と IO selector の動作と、firebase スレッドのライフサイクルを比較します。この issue ではファイル、テスト、受け入れられる解決策が指定されていないため、done の意味を定義する前に、意図されたハンドオフと再現可能な失敗を確認してください。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- java
- 領域
- api, backend
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 30/100