lsp.client: multi-mime LanguageServerProvider class registrations start one server process per MIME (reuse map is instance-keyed)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- java
- Lĩnh vực
- developer-experience, tooling
Hướng nghiên cứu
Bắt đầu bằng cách đọc LSPBindings.buildBindings và các đăng ký MimeLookup/layer liên quan đến việc phân giải các instance LanguageServerProvider. Tái hiện vấn đề với một provider được đăng ký cho text/javascript và text/typescript, sau đó quan sát các process bằng pgrep. Hoàn tất khi cùng một project sử dụng một process language-server và một regression test bao phủ việc đăng ký nhiều MIME cũng như việc tái sử dụng.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Apache NetBeans version
Apache NetBeans 25 (observed on RELEASE300, still present on RELEASE310)
Bug description
Summary: When one LanguageServerProvider is registered for multiple MIME types with a class-level @MimeLookup.Registration / layer class registration, LSPBindings starts one language-server process per MIME type instead of reusing the running server, because its server-reuse map is keyed by provider instance — and a class registration places a separate .instance in each mime folder, each instantiated independently.
Measured effect (in a NetBeans-Platform-based IDE using ide/lsp.client, with providers registered for both text/javascript and text/typescript):
- two
typescript-language-serverprocesses for a single mixed JS/TS project, - two
deno lspprocesses for one deno workspace, - two
ngserverprocesses in an Angular project with a component (.ts) and its template open.
Each extra process is a full tsserver-class JVM/node footprint per project, silently.
Mechanism (from reading the RELEASE300/310 LSPBindings source/bytecode): buildBindings files a started server under every declared mime only when the same provider instance is presented for each mime folder. With a class-level registration, the second mime folder resolves a different instance of the same provider class, misses the reuse map, and a second server process is spawned. Shutdown being GC-driven (LSPReference + keep-alive) means both processes then live for the session.
Workaround we ship: converting every multi-mime provider registration to a static singleton factory method (methodvalue registration), so every mime folder resolves the same object. That fixes it completely — A/B measured 2 processes → 1 — but the requirement is undocumented and very easy to violate (we re-introduced it once via a three-mime CSS provider before gating registrations structurally).
Steps to reproduce
- Register one
LanguageServerProviderclass for two mimes (e.g.text/javascriptandtext/typescript) with a plain class-level registration. - Open one file of each mime from the same project.
- Observe two identical language-server processes for the project (e.g.
pgrep -fl typescript-language-server).
Expected behavior
One server process per project for a provider declared on multiple mimes — or, failing that, a documented requirement that multi-mime providers must be registered as singletons.
Suggested fix directions: key the reuse map by provider class (or by the provider's declared mime set), or have MimeLookup resolution for LanguageServerProvider treated as singleton-per-class in LSPBindings. Happy to provide more detail or test against a patch — we carry a structural test (registrations == getMimeTypes(), no class-instance backdoor) that could inform one upstream.
Context
Found while building NMOX Studio (Apache-2.0, NetBeans-Platform based): https://github.com/NMOX/NMOX-Studio — details in our engineering ledger entry 83 (docs/engineering/tech-debt.md).
- Ngôn ngữ chính
- Java
- Star
- 3.1k
- Fork
- 939
- Merge trung bình
- 5 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 22
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của apache/netbeans
-
Contribution welcome kind:feature Platform
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
apache/netbeans#9614 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
kind:bug LSP needs:triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
apache/netbeans#9548 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Editor Java kind:feature needs:triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
The main Options dialog window has buttons with OK on the left instead of on the right on LinuxĐang mởkind:bug needs:triage os:linux os:macos Platform UI
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Incorrect DTD for wstcref-FilesĐang mởkind:bug needs:triage
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của apache/netbeans
Issue tương tự
-
waiting-for-triage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
spring-cloud/spring-cloud-openfeign#1443 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 84/100
ADORSYS-GIS/keycloak-oid4vp-plugin#221 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Upgrade to Spring Pulsar 2.0.8Đang mởstatus: team-only type: dependency-upgrade
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
spring-projects/spring-boot#52099 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
tchiotludo/akhq#3307 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
objectionary/jeo-maven-plugin#1885 ·
Maintainer thường phản hồi trong vòng 4 ngày