Tham chiếu đến một DLL không ổn định

Question

Chúng tôi đang tham chiếu một DLL CLI độc quyền của bên thứ ba trong dự án .net của chúng tôi. DLL này chỉ là một giao diện cho thư viện C++ độc quyền của chúng. Dự án của chúng tôi là một ứng dụng web asp.net (MVC4/Web API).

Thư viện không được quản lý C++ khá không ổn định. Đôi khi nó gặp sự cố với ví dụ: con trỏ lơ lửng. Chúng tôi không có cách nào để giải quyết nó, và sử dụng thư viện này là một yêu cầu của khách hàng hạng nhất.

Khi ứng dụng gặp sự cố, nhóm ứng dụng trong IIS không phản hồi nữa. Chúng ta phải khởi động lại nó, và làm như vậy mất một vài phút (có, đó là lâu!).

Chúng tôi muốn giữ tệp DLL không ổn định này khỏi ứng dụng của chúng tôi. Cách tốt nhất để làm điều đó là gì? Chúng ta có thể giữ CLI DLL trong một AppDomain riêng biệt không? Làm sao?

Xin cảm ơn trước.

Answer 1

Lần đầu tiên tôi sẽ tăng tỷ lệ tái xử lý IIS, có thể mã DLL không thành công sau một số cuộc gọi nhất định hoặc sau khi quá trình đạt đến mức sử dụng bộ nhớ nhất định.

Bạn có thể tìm thông tin về cấu hình của IIS 7.0 tùy chọn tái chế ở đây: http://technet.microsoft.com/en-us/library/cc753179(v=ws.10).aspx

Trong trường hợp của bạn tôi sẽ tái chế quá trình này tại một thời điểm cụ thể, khi bạn biết có ít tải trên ứng dụng. Và sau một số yêu cầu nhất định (thấp hơn giá trị mặc định) để thử và có quá trình "mới" phần lớn thời gian.

Quá trình tái chế là duyên dáng theo nghĩa là quy trình cũ không bị chấm dứt cho đến khi quá trình thay thế sẵn sàng, vì vậy sẽ không có thời gian chết đáng chú ý. Thông tin thêm về cơ chế tái chế tại đây: http://technet.microsoft.com/en-us/library/cc745955.aspx

Nếu ở trên không giải quyết được sự cố, tôi sẽ bao bọc các cuộc gọi trong mã của riêng tôi quản lý việc thực thi DLL không ổn định.

Mã này sẽ khôi phục từ các lỗi chẳng hạn bằng cách lặp lại các cuộc gọi không thành công cho đến khi có kết quả và không có lỗi nghiêm trọng nếu không thể thực hiện được sau một số lần thử.

Nội bộ các cuộc gọi đến DLL không ổn định có thể được thực hiện trong một luồng được sinh ra hoặc thậm chí mã có thể nằm trong một tệp thực thi bên ngoài mới mà bạn có thể khởi chạy với Process.Start.

Tùy chọn cuối cùng này có nhiều chi phí hơn nhưng có thể là tùy chọn duy nhất của bạn. Xem câu hỏi SO này để biết thêm thông tin về điều này: How do you handle a thread that has a hung call?

Answer 2

Tôi nghĩ mọi câu trả lời cho câu hỏi này sẽ là một số công việc xung quanh.

Giải pháp thay thế của tôi sẽ không tương tác trực tiếp với DLL từ ứng dụng web của bạn.

Thay vào đó, hãy viết yêu cầu của bạn từ ứng dụng web vào Hàng đợi tin nhắn hoặc bảng SQL. Sau đó, bạn có thể có một ứng dụng khác như một Dịch vụ Windows đọc các yêu cầu, tương tác với DLL và sau đó ghi lại kết quả cho ứng dụng web của bạn để đọc.

Tôi không nói rằng Hàng đợi SQL/Tin nhắn là đúng cách, tôi đang suy nghĩ nhiều hơn về quy trình xử lý chung.

Answer 3

Tôi đề xuất giải pháp sau đây.

1. Gói dll này bằng ứng dụng web khác. Có thể là một trong những người sau đây. Vì bạn đã sử dụng api web, nên nó phù hợp nhất với bạn.

   1. Simple ASMX Web Service
   2. Dịch vụ WCF
   3. Asp.Net MVC - WEB Api Dịch vụ

2. kiểm soát p-gọi của bạn code để bạn không có bất kỳ lỗi? Xem các bài viết sau.

   1. The Black Art of P/Invoke and Marshaling in .NET
   2. P/Invoke Revisited
3. Xuất bản ứng dụng này để IIS với ứng dụng khác nhau hồ bơi.
4. Sử dụng các kỹ thuật tiêu chuẩn được đề xuất trước đó. Tôi đề nghị cấu hình tái chế IIS cho cả bộ nhớ và thời gian đã lên lịch.
   1. IIS process recycling rate
   2. How to limit the memory used by an application in IIS?

Answer 4

Tôi có vấn đề này chính xác với một thư viện của bên thứ ba mà truy cập bộ nhớ được bảo vệ cho các mục đích tương tác với một dongle bảo vệ bản quyền phần cứng. Nó làm việc tốt trong một giao diện điều khiển hoặc ứng dụng winforms, nhưng bị rơi như điên khi được gọi từ một ứng dụng IIS.

Chúng tôi đã thử nhiều thứ khác nhau, một số trong số đó được đề cập trong các câu trả lời khác trên trang này. Nhưng cuối cùng, giải pháp tốt nhất cho chúng tôi là cho chúng tôi một công nghệ rất cũ - .Net Remoting. Tôi biết - nó hơi cau mày vào những ngày này. Nhưng nó phù hợp với nhu cầu đặc biệt này khá tốt.

Mã không ổn định được đặt trong ứng dụng Dịch vụ Windows. Ứng dụng web đã thực hiện các cuộc gọi từ xa đến dịch vụ này, chuyển tiếp các lệnh đến thư viện của bên thứ ba.

Bây giờ tôi chắc chắn bạn có thể làm điều tương tự với WCF, ổ cắm, v.v. Nhưng từ xa đã nhanh chóng và dễ dàng để thiết lập, và kể từ khi chúng tôi chỉ nói chuyện với cùng một máy chủ nó hoạt động mà không cần mở bất kỳ cổng. Nó chỉ nói về một đường ống có tên.

Nó có nghĩa là một dịch vụ thứ hai để cài đặt bên cạnh ứng dụng web, nhưng điều đó đã được chấp nhận trong trường hợp sử dụng cụ thể của tôi.

Nếu bạn đã làm điều gì đó tương tự, và mã của bên thứ ba thực sự bị hỏng dịch vụ, bạn có thể viết một số mã trong ứng dụng chính của mình để sao lưu nó.

Vì vậy, có lẽ ranh giới quy trình hữu ích hơn một miền ứng dụng khi bạn có mã không ổn định để sắp xếp.