Dịch vụ NetTcpActivator (Net.Tcp Listener Adaptor) dừng đáp ứng thỉnh thoảng

Question

Trong dự án hiện tại của tôi, chúng tôi (ý tôi là "nhóm dự án") sử dụng các dịch vụ WCF được lưu trữ trên IIS.

Dưới đây là một số chi tiết kỹ thuật mà có thể quan trọng:

1. Chúng tôi sử dụng NET 3.5 cho các dịch vụ WCF
2. Chúng tôi sử dụng giao thức truyền thông net.tcp
3. Chúng tôi sử dụng cả hai IIS 7 và IIS 7.5 để lưu trữ các dịch vụ này
4. Chúng tôi sử dụng nhiều quy trình công nhân IIS trên mỗi máy chủ

Vì vậy, vấn đề là - đôi khi WCF- dịch vụ trở nên không khả dụng. Khi chúng tôi cố gắng tiếp cận các dịch vụ WCF này, chúng tôi sẽ gặp lỗi thời gian chờ. Và cách duy nhất để khôi phục chức năng dịch vụ WCF là khởi động lại dịch vụ NetTcpActivator (Net.Tcp Listener Adapter) Windows.

Theo lý thuyết đồng nghiệp của tôi, lỗi này có thể liên quan đến những vấn đề mô tả trong bài viết này KB:

FIX: Smsvchost.exe cho các dịch vụ WCF dừng đáp ứng khi bạn chạy một .NET Framework 4 dịch vụ dựa trên WCF http://support.microsoft.com/kb/2536618

Theo bài báo này, SMSvcHost (vận chuyển container đi nơi tổ chức NetTcpActivator và Port Sharing Service) treo lên nếu nó không thể lộ trình yêu cầu w3wp (IIS worker process) trong hơn 60 giây (không thời gian chờ có thể định cấu hình). Thật không may, chúng tôi không thể tìm ra cách để tạo lại lỗi này. Ví dụ, chúng tôi giới hạn SMSvcHost đến 1 lõi CPU và 1 luồng và kết nối đang chờ mở rộng giới hạn đến 1M và đẩy nó tới 100% tải CPU ở chế độ người dùng. Và nó không treo!

Đôi khi kiểm tra tải của chúng tôi dẫn đến lỗi lạ, nhưng khi chúng tôi dừng chúng, tất cả các dịch vụ sẽ tự động phục hồi về trạng thái bình thường của chúng. Nhưng đôi khi không phải là một tải nặng có thể treo NetTcpActivator!

Ngoài ra, tôi muốn nói rằng đây không phải là vấn đề mới. Đồng nghiệp của tôi đã có nó 3 năm trước (xem chủ đề này để biết thêm thông tin http://forums.iis.net/t/1167668.aspx/1/10). Và, thật không may, họ đã không nhận được câu trả lời. Vấn đề chỉ biến mất sau khi một số thay đổi cấu hình! Và bây giờ nó đã trở lại trên máy chủ mới.

Tôi thực sự sẽ đánh giá cao tất cả suy nghĩ và ý tưởng của bạn!

Answer 1

Được rồi, sau nhiều nghiên cứu tôi đã theo dõi nguyên nhân của vấn đề của chúng tôi. Có thể có các tình huống khác xảy ra, nhưng hy vọng điều này sẽ giúp một số người. Microsoft đang trong quá trình tái tạo trong các phòng thí nghiệm của họ và cuối cùng cũng phải có một bản sửa lỗi.

Trong trường hợp của chúng tôi, tất cả các hành tinh phải căn chỉnh. Chúng tôi đã có một ứng dụng tích hợp .NET 4.0 cho máy khách và máy chủ (trên máy phát triển). Dịch vụ đang sử dụng tệp cấu hình bên ngoài cho các liên kết (<bindings configSource="serviceModel.bindings.config" />) được liên kết từ một dự án khác và được sao chép vào thời gian xây dựng với tác vụ xây dựng tùy chỉnh được thêm vào .csproj của dịch vụ.

Để mô phỏng vấn đề:

1. tất cả các dịch vụ SMSvcHost đang chạy (net.tcp *, Net.Pipe, Net.Msmq) Dừng. Khởi động lại sẽ không hoạt động vì quá trình SMSvcHost không biến mất.
2. Từ Visual Studio, chạy một sạch cho WcfService
3. Từ Windows Explorer, xóa serviceModel.bindings.config trong WcfService
4. Run iisreset (được thoát khỏi w3wp và bắt đầu SMSvcHost dịch vụ - nhấn F5 là danh sách các dịch vụ để xem đó)
5. Xây dựng WcfService (sao chép tệp cấu hình được liên kết)
6. Duyệt tới trang WcfClient, gửi hai lần. Nếu bạn gặp lỗi mỗi lần, bạn có thể gặp sự cố. Trên ứng dụng chính của chúng tôi nó đã cho một thời gian chờ, trong ứng dụng thử nghiệm CommunicationObjectFaultedException thay vì thời gian chờ, nhưng một trong hai là tốt.
7. Dừng dịch vụ SMSvcHost. Nếu sự cố xảy ra, ID sự kiện 8 cho SMSvcHost được ghi vào Nhật ký sự kiện hệ thống.

Tôi chưa biết liệu w3wp hoặc SMSvcHost có phải là thủ phạm hay không. BướC# 3 là rất quan trọng, mặc dù tôi không thể giải thích lý do tại sao. Nếu bạn không xóa tệp thì tất cả đều ổn. Nếu bạn sửa đổi tập tin (ngày tạo ra vẫn giữ nguyên), tất cả đều ổn. Nếu bạn di chuyển XML cấu hình vào tệp Web.config chính, tất cả đều ổn. Khi tác vụ xây dựng sao chép tệp, ngày tạo đã được cập nhật, vì vậy tôi đoán nó được lưu trữ theo cách nào đó và một trong các quy trình phát hiện thay đổi ngày.

Nếu bạn khởi động lại dịch vụ SMSvcHost (dừng đầy đủ, bắt đầu đầy đủ) một hoặc hai lần yêu cầu của khách hàng sẽ đi qua và từ đó bạn vẫn ổn. Vì vậy, tôi đoán bây giờ là điều này có thể là một vấn đề ngay sau khi triển khai, nhưng nếu bạn chắc chắn rằng mọi thứ đang chạy (và khởi động lại dịch vụ khi cần thiết) thì bạn sẽ ổn thôi. Bạn cũng không thể làm các tập tin bên ngoài/liên kết.

Khi Microsoft theo dõi vấn đề, tôi hy vọng sẽ có thông tin chi tiết hơn.

Cập nhật lần cuối Tôi quên quay lại điều này trước đó. Microsoft về cơ bản thừa nhận họ có thể đã có một lỗi nhưng vì có một workaround và đã dành đủ thời gian trên vé họ đã đóng nó và không nghiên cứu thêm. Có vẻ như một số loại điều kiện chủng tộc khi SMSvcHost khởi động với các thiết lập sau đây (tương tự như những gì tôi được đăng trước đó):

1. chủ WCF trong IIS
2. Sử dụng một tổ chức phi HTTP ràng buộc để SMSvcHost đi vào chơi
3. sử dụng tập tin cấu hình bên ngoài cho các ràng buộc sử dụng configSource

Liên kết các cấu hình bên ngoài không có gì để làm với nó. Cách giải quyết là không sử dụng configSource mà chúng tôi đang làm bây giờ.