Thời gian chờ WCF là một cơn ác mộng

Question

Chúng tôi có một loạt dịch vụ WCF hoạt động gần như mọi lúc, sử dụng các ràng buộc khác nhau, cổng, kích thước tối đa, v.v. Điều siêu bực bội về WCF là khi nó (hiếm khi) bị lỗi, chúng ta bất lực để tìm hiểu tại sao nó thất bại. Đôi khi bạn sẽ nhận được thông báo giống như sau:

System.ServiceModel.CommunicationException: Kết nối socket bị hủy. Điều này có thể do lỗi xử lý tin nhắn của bạn hoặc nhận được thời gian chờ bị vượt quá bởi máy chủ từ xa hoặc mạng cơ bản vấn đề tài nguyên. Thời gian chờ của ổ cắm cục bộ là '01: 00: 00 '. ---> System.IO.IOException: Không thể đọc dữ liệu từ kết nối truyền tải: An kết nối hiện có bị buộc đóng bởi máy chủ từ xa.

Vấn đề là thời gian chờ ổ cắm cục bộ mà nó cung cấp cho bạn chỉ là một nỗ lực để thuận tiện. Nó có thể hoặc không thể là nguyên nhân của vấn đề. Nhưng OK, đôi khi mạng có vấn đề. Không phải vấn đề lớn. Chúng ta có thể thử lại hay gì đó. Nhưng đây là vấn đề lớn. Trên đầu trang của không cho bạn biết chính xác thời gian chờ (nếu có) dẫn đến lỗi ("thời gian chờ phía máy chủ của bạn đã vượt quá", hoặc một cái gì đó, sẽ hữu ích), WCF dường như có hai loại thời gian chờ.

Loại thời gian chờ # 1) Thời gian chờ, nếu tăng, sẽ tăng cơ hội thành công cho hoạt động của bạn. Vì vậy, thời gian chờ thích hợp là một giờ, bạn đang tải lên một tệp lớn sẽ mất một giờ và hai mươi phút. Nó thất bại. Bạn tăng thời gian chờ, nó thành công. Tôi không có vấn đề với loại thời gian chờ này.

Timeout Loại # 2) Đã hết thời gian mà chỉ xác định bao lâu bạn phải đợi cho dịch vụ để thực sự thất bại và cung cấp cho bạn một lỗi, nhưng việc sửa đổi giá trị của thời gian chờ này không ảnh hưởng đến cơ hội sự thành công. Về cơ bản, có điều gì đó xảy ra trong giây đầu tiên của yêu cầu dịch vụ, điều đó làm mọi thứ trở nên buồn cười. Nó sẽ không bao giờ phục hồi. WCF không kỳ diệu thử lại kết nối mạng cho bạn. Tốt, đôi khi thiết lập một kết nối mạng không hoạt động tốt. Tuy nhiên, nếu thời gian chờ của bạn là 2 giờ, bạn phải đợi 2 giờ đồng hồ mà không có cơ hội nào hoạt động trước khi nó cuối cùng thừa nhận rằng nó không hoạt động và cung cấp cho bạn lỗi.

Nhưng lỗi bạn thấy trong cả hai trường hợp đều giống nhau. Với timeout Type # 2, nó vẫn có vẻ như bạn đang chạy vào một thời gian chờ. Tuy nhiên, bạn có thể tăng tất cả thời gian chờ của mình lên 4 năm và tất cả những gì cần làm là mất 4 năm để nhận được thông báo lỗi. Tôi biết rằng Type # 2 tồn tại vì tôi có thể thực hiện một thao tác được biết là hoàn thành sau chưa đầy một phút khi thành công và mất 2 giờ để không thành công. Nhưng, nếu tôi giết nó và thử lại, nó thành công nhanh chóng. (Nếu bạn tự hỏi tại sao có thể mất 2 giờ thời gian chờ trong một hoạt động mất ít hơn một phút, có những lúc tôi chạy hoạt động với một tệp lớn hơn nhiều và có thể mất hơn một giờ.)

Vì vậy, để chống lại sự cố với Type # 2, bạn muốn thời gian chờ của mình thực sự nhanh chóng để bạn ngay lập tức biết nếu có sự cố. Sau đó, bạn có thể thử lại. Nhưng vấn đề không thể vượt qua là bởi vì tôi không biết thời gian chờ là nguyên nhân của thất bại, tôi không biết thời gian chờ là Type # 1 và cái nào là Type # 2. Có thể có một thời gian chờ (giả sử thời gian chờ gửi phía máy khách) hoạt động như Loại # 1 trong một số trường hợp và Loại # 2 trong các trường hợp khác. Tôi không biết, và tôi không có cách nào để tìm ra.

Có ai biết cách theo dõi thời gian chờ loại 2 để tôi có thể đặt giá trị thấp xuống mà không phải rút ngắn thời gian chờ thực tế (đọc: Loại # 1) và giảm cơ hội thành công không?

Cảm ơn bạn.

Làm rõ Loại # 2 timeout để phản ứng lại bình luận Andrew Anderson:

niềm tin của tôi là họ gặp khó khăn giữa các yêu cầu của khách hàng và mã bắt đầu thực hiện trên máy chủ. Trong mọi trường hợp chúng ta có mã máy chủ chỉ ra một phần tiến bộ, nó không bao giờ kết thúc một số thao tác mà không hoàn thành toàn bộ điều đó. Vì vậy, mã máy chủ không bao giờ được thực thi và mất bao lâu để thực thi không liên quan (ngoài việc nó ảnh hưởng đến những gì chúng tôi đặt các giá trị hết thời gian của chúng tôi ở vị trí đầu tiên để thích ứng với nó).

Answer 1

Tôi luôn đặt thông báo "nhịp tim" trong các dịch vụ WCF hoạt động lâu dài của mình. Sau đó, bạn có thể đặt thời gian chờ loại # 1 thành giá trị thấp (2-3 lần tần số gọi nhịp tim) và thời gian chờ loại # 2 trở nên rõ ràng.

Answer 2

Để tìm hiểu thời gian chờ cụ thể nào đã gây ra lỗi hết giờ hoặc lỗi khác, hãy định cấu hình và sử dụng tracing.

Answer 3

Tôi gặp vấn đề tương tự, và nó liên quan đến phần cứng xấu, và thực sự khó gỡ lỗi, cũng với wireshark (tcp sniffer) các gói không hiển thị bất kỳ lỗi cụ thể nào, chúng tôi tìm thấy một số tcp và những điều này có thể là một triệu chứng, nhưng thực ra các gói tin đã bị kẹt ở đâu đó bên trong modem-router là modem viễn thông (pirelli gate 2 plus), sau khi thay đổi modem/router, vấn đề hoàn toàn biến mất.

Dù sao chúng tôi đã tìm ra rằng một wsHttpBinding qua http, nó đáng tin cậy hơn cho một kết nối internet mà bạn không có quyền kiểm soát, và bạn không thể chắc chắn về những gì phần cứng được cài đặt trên trang web.

Hy vọng điều này cũng có thể giúp người khác :)

Answer 4

Đảm bảo bạn xử lý đúng ngoại lệ dịch vụ. Bạn sẽ thường xuyên nhận được các kết nối mà bỏ ra không có lý do nếu trường hợp ngoại lệ không được xử lý một cách chính xác. Ngoài ra, nếu họ làm, và họ đang xử lý một cách chính xác, bạn thường có thể nhận được một số thông tin hữu ích hơn:

https://msdn.microsoft.com/en-us/library/ms733721(v=vs.110).aspx

Ngoài ra, sử dụng một "Heartbeat" hoặc phương pháp ping thường mà bạn có thể gọi từ khách hàng. Tôi đã thấy rằng các router của khách hàng có một thời gian chờ tự động được xây dựng thành các kết nối TCP mà nó sử dụng để kết thúc các kết nối nhàn rỗi. Nếu không có phương pháp nhịp tim, bộ định tuyến của khách hàng có thể kết thúc sớm kết nối không bị ảnh hưởng bởi các thiết lập dịch vụ WCF