Sau khi loại ngoại lệ/lỗi nào xảy ra khi cá thể Azure Cloud thực hiện khởi động lại?

Question

Theo như tôi nhớ, một cá thể vai trò sẽ tự động thực hiện khởi động lại sau một sự cố/lỗi. Để kiểm tra hành vi đó, tôi đã viết một ứng dụng thực thi ngoại lệ ngoài bộ nhớ và ứng dụng của tôi bị lỗi. Ví dụ vai trò đã không thực hiện khởi động lại, bởi vì nó vẫn chạy và ok - cá thể chỉ khởi động lại thời gian chạy .NET.

Tôi đang cố gắng tìm hiểu cách một cá thể phản ứng trên các lỗi khác nhau. Trong trường hợp của tôi, khởi động lại không cần thiết. Loại lỗi/ngoại lệ nào (mà tôi có thể thực thi) sẽ gây ra một khởi động lại hoàn toàn một cá thể? Loại lỗi/ngoại lệ nào sẽ giết chết một cá thể mãi mãi?

Answer 1

Lý do duy nhất gây ra một trường hợp vai trò được tái chế (khởi động lại) là khi phương pháp Run của số RoleEntryPoint thoát. Điều này thường xảy ra khi bạn:

1. Overrided Run (phương pháp
   ), và
2. Có một ngoại lệ unhandled trong mã chương trình của bạn, có thể gây ra các phương pháp Run() để thoát

Vai trò của bạn tuy nhiên sẽ tái chế , nhưng thay vào đó, khi bạn đã bật thu thập nhật ký IntelliTrace.

Mẫu mặc định cho WebRole không ghi đè phương thức Run(), do đó để mặc định triển khai, đó là "Thread.Sleep (-1);". Không có sự kiện (tự động) nào có thể gây tái chế vai trò tự động của WebRole. Trừ khi bạn làm điều gì đó trong RoleEntryPoint của bạn, điều đó sẽ khiến phương thức Run thoát ra. Việc tái chế tự động này chỉ xảy ra với WorkerRole, thực hiện phương thức Run().

UPDATE 1 (theo công bình luận 1)

run-Methoded of a RoleEntryPoint faces an error 

Không chỉ là một lỗi, nhưng loại đó của lỗi (ví dụ: một ngoại lệ unhandled), gây phương pháp Run() để thoát. Hơn nữa, bạn không thể ghi đè lên Run() trong WebRole của bạn, bởi vì hậu duệ RoleEntryPoint của bạn sống trong miền ứng dụng khác nhau (thậm chí là quá trình khác), sau đó ứng dụng web của bạn (vì vậy nó sẽ không có ý tưởng về ngoại lệ của ứng dụng của bạn) . Đọc thêm về lưu trữ và xử lý IIS đầy đủ here.

Vì vậy, đối với vai trò web, bạn chỉ có một ứng dụng web có đầy đủ tính năng IIS 7.0/7.5, điều này không có ý tưởng rằng IIS này là một phần của triển khai Azure. Global.asax là nơi bạn quản lý các lỗi ứng dụng web chưa được giải quyết trong ASP.NET. Hãy xem this question, câu trả lời cung cấp một ví dụ điển hình cho trình xử lý Application_Error().

Bạn có thể sử dụng phương thức tĩnh RequestRecycle kiểu RoleEnvironment để yêu cầu tái chế vai trò theo cách thủ công trong phương thức Application_Error() của bạn. Tuy nhiên không khuyên bạn nên làm như vậy. Tôi không thấy thực tiễn tốt trong việc khởi động lại máy chủ web do lỗi ứng dụng. Bạn nên thực hiện xử lý ngoại lệ tốt và chiến lược ghi lỗi, kiểm tra các nhật ký lỗi của bạn và thực hiện các hành động để tránh các lỗi crytical yêu cầu khởi động lại máy chủ.

Mục đích ban đầu của bạn là gì? Để hiểu khi nào vai trò sẽ được tái chế tự động hoặc mô hình hóa ứng dụng của bạn như tự động tái chế vai trò của bạn do lỗi? Nếu nó là sau này, tôi đề nghị bạn sửa đổi yêu cầu kinh doanh/logic của bạn.

UPDATE 2

Tôi không thể nói từ miệng Neil, nhưng "thất bại dụ" là tất cả những gì có thể gây ra một máy ảo chạy để treo. Ví dụ trong Windows Azure là một Máy ảo đăng ký lưu trữ mã của ứng dụng của bạn (đọc this blog post để được giải thích chi tiết về Dịch vụ được lưu trữ, Vai trò, Sơ thẩm). Ứng dụng của bạn chạy trên hệ điều hành Windows Server. Nó là một máy ảo. Bất cứ điều gì có thể xảy ra - từ lỗi phần cứng trên máy chủ, đến một lỗi phần mềm/trình điều khiển chung của hệ điều hành khách. Nó không phải là cần thiết để được mã của bạn. Vì vậy, trong trường hợp một cái gì đó xảy ra mà sẽ gây ra một máy ảo duy nhất để thất bại - vấn đề này được tự động xử lý bởi Windows Azure Vải. Nếu cần thiết - mã của bạn sẽ tự động được triển khai cho một máy ảo khác. Và điều này xảy ra tự động. Bạn làm nohting. Hãy tưởng tượng một HDD bị hỏng, hoặc một mô-đun bộ nhớ bị cháy, hoặc một giao diện mạng ngừng đáp ứng - đây chỉ là một vài vấn đề đơn giản có thể gây ra một máy ảo đang chạy thất bại. Đây là một trường hợp thất bại.

Lỗi trong mã của bạn là thứ mà bạn nên xử lý. Mọi thứ khác - Bộ điều khiển Windows Azure Fabric sẽ xử lý.

CẬP NHẬT 3

1. gì xảy ra với một ứng dụng asp.net trong một webrole nếu một ngoại lệ xảy ra và nó không được xử lý? Ứng dụng sẽ chỉ treo trong trạng thái chưa được xác định là ("bị hỏng") cho đến khi tôi tìm hoặc sẽ là bị vm chấm dứt?

Câu hỏi này hoàn toàn nằm ngoài phạm vi! Điều gì sẽ xảy ra với ứng dụng asp.net trong tài khoản lưu trữ được chia sẻ? Hoặc trong cài đặt IIS tại chỗ? Sự cố ứng dụng cho người dùng có hành động gây ra sự cố. Các hồ bơi ứng dụng trường hợp xấu nhất tái chế. Tôi chưa bao giờ thấy một ứng dụng asp.net "treo". Không có điều như "chấm dứt ứng dụng asp.net" hoặc "bị hỏng". Nếu đó là lỗi chung được gây ra trong quá trình khởi động ứng dụng hoặc yêu cầu đầu tiên - ứng dụng sẽ không bao giờ trực tuyến. Nếu đó là lỗi do một số chuỗi hành động người dùng gây ra - người dùng sẽ thấy thông báo lỗi xấu và không có gì khác (trừ khi bạn có trình xử lý Application_Error() thích hợp trong Global.asax của mình. với Azure.

2. bạn có thể nghĩ ra một đoạn mã NET trong ứng dụng của tôi mà có thể gây ra sự sụp đổ của một vai trò web toàn bộ hoặc nó không phải là có thể với quản lý mã (ngoài một lỗi không xác định trong .NET)?

Bạn đang đùa? Mã này sẽ phá vỡ vai trò web của bạn và sẽ buộc tái chế:

RoleEnvironment.RequestRecycle() 

Vui lòng chấp nhận câu hỏi này vì tôi không nghĩ có điều gì đó bị thiếu. Thêm vào đó nó có câu trả lời cho ít nhất 4 câu hỏi, thêm vào câu hỏi ban đầu.

CUỐI CÙNG

Không có những điều như "giết dụ mãi mãi".