2011-12-05 30 views
15

Chúng tôi đang bắt đầu thử nghiệm với việc triển khai các dịch vụ phụ trợ của chúng tôi bằng CDI. Kịch bản này là:Ứng dụng CDI và phạm vi phụ thuộc có thể âm mưu tác động đến việc thu gom rác thải?

EJB với @Startup được bắt đầu khi EAR triển khai. Một đậu ApplicationScoped được tiêm vào này:

@ApplicationScoped 
public class JobPlatform { 

    private PooledExecutor threadHolder; 

    @Inject @Any 
    private Instance<Worker> workerSource; 
... 

bean cũng có một phương pháp quan sát, trong đó, khi một sự kiện được quan sát, được một bean nhân từ Instance workerSource và đặt nó trên ThreadPool, nơi nó cuối cùng chạy để hoàn thành.

Tất cả hoạt động tốt. Tuy nhiên ... chúng tôi đã bắt đầu thấy các vấn đề thu gom rác thải. Một biểu đồ heap của JMAP cho thấy có rất nhiều người trong số những công nhân này bị treo xung quanh, không thu gom rác thải.

Chúng tôi tin rằng điều này là do sự kết hợp của phạm vi CDI. Trang API cho @Dependant (http://docs.jboss.org/cdi/api/1.0-SP1/javax/enterprise/context/Dependent.html) củng cố rõ ràng hơn những gì trong các tài liệu:

  • Một ví dụ của một bean với phạm vi @Dependent tiêm vào một lĩnh vực, constructor đậu hoặc phương pháp khởi tạo là một đối tượng phụ thuộc của bean hoặc Java EE thành phần lớp mà nó được tiêm vào.
  • Một thể hiện của một bean với phạm vi @Dependent tiêm vào một phương pháp sản xuất là một đối tượng phụ thuộc của cá thể phương thức sản xuất bean đang được sản xuất.
  • Một thể hiện của một bean có phạm vi @Dependent thu được bằng cách gọi trực tiếp một Instance là một đối tượng phụ thuộc của cá thể Instance.

Vì vậy, sau này:

  • bean workerSource là ràng buộc để JobPlatform, và do đó có thể tồn tại mãi ApplicationScoped
  • Bất kỳ đậu nhân viên lấy ra sử dụng ví dụ rằng đang bị ràng buộc với nó, và do đó có một thời hạn sử dụng ApplicationScoped
  • Bởi vì các beanstore của bối cảnh ApplicationScoped (kiến thức của tôi về các thuật ngữ được một chút mờ ở đây) vẫn còn có một lên men đậu công nhân, chúng không bị phá hủy/rác thu được

Có ai sử dụng CDI đồng ý với điều này không? Bạn đã trải qua việc thiếu bộ sưu tập rác và nếu có, bạn có thể đề xuất bất kỳ cách giải quyết nào không?

Công nhân không thể ứng dụng được kiểm tra, nhưng nền tảng phải như vậy. Nếu chúng ta tạo một WorkerScope tùy chỉnh (uh ohhh ...) và chú thích mỗi lớp nhân viên với nó, thì điều đó có đủ để tách biệt sự phụ thuộc giữa công nhân và nguồn cá thể không?

Cũng có một số đề xuất tại Is it possible to destroy a CDI scope? mà tôi sẽ xem xét, nhưng muốn một số bản sao lưu về việc liệu phạm vi có vẻ như là một lý do hợp lệ hay không.

Hy vọng bạn có thể trợ giúp, cảm ơn.

Trả lời

9

Hiểu biết của bạn là chính xác. Đây là một sự giám sát trong spec, và cái gì đó sẽ được cố định trong CDI 1.1. Instance có thể bị rò rỉ bộ nhớ giống như bạn đã mô tả khi được sử dụng trong phạm vi hoạt động dài như SessionScoped hoặc ApplicationScoped.Những gì bạn cần làm là nắm giữ Contextual hoặc Bean cho trường hợp này và phá hủy nó theo cách đó.

Đối với những gì bạn đang làm và để tránh rò rỉ bộ nhớ, bạn nên sử dụng các phương thức BeanManager để tạo các phiên bản (theo cách đó, bạn cũng sẽ có thể xử lý trên Bean) Instance.

+0

Cảm ơn bạn rất nhiều vì đã quay trở lại quá nhanh - thật tuyệt khi biết nó được công nhận vấn đề. Sẽ cung cấp cho workaround một đi ngay bây giờ! Chúc mừng! –

+0

Đối với bất kỳ ai đọc ở đây, lưu ý rằng Weld 1.1 triển khai CDI 1.0, không phải CDI 1.1. –

+0

Craig đúng. Weld 2.0 thực hiện CDI 1.1 (vâng, tôi biết số là lạ). Nếu bạn muốn xem CDI 1.1 sẽ như thế nào, hãy thử Weld 2.0. Tôi tin rằng có những bản xây dựng đặc biệt của JBoss AS7 bao gồm Weld 2.0. – LightGuard

2

Trong khi nhìn vào thực hiện cách giải quyết đề nghị của Jason, tôi thấy một số chi tiết các nguồn lực liên quan đến vấn đề này:

Vấn đề: https://issues.jboss.org/browse/CDI-139https://issues.jboss.org/browse/WELD-920 hoạt động

Ví dụ beanManager: https://issues.jboss.org/browse/CDI-14?focusedCommentId=12601344&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12601344

hoặc org.jboss.seam.faces.util.BeanManagerUtils

Các vấn đề liên quan