Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

lsp.client: multi-mime LanguageServerProvider class registrations start one server process per MIME (reuse map is instance-keyed)

Đang mở
#9,581 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

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

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ả

LSP
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-server processes for a single mixed JS/TS project,
  • two deno lsp processes for one deno workspace,
  • two ngserver processes 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
  1. Register one LanguageServerProvider class for two mimes (e.g. text/javascript and text/typescript) with a plain class-level registration.
  2. Open one file of each mime from the same project.
  3. 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

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/netbeans

Tất cả issue của apache/netbeans

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.