2008-11-11 34 views
7

Tôi có ứng dụng khách flex thực hiện cuộc gọi dịch vụ tới máy chủ tomcat đang chạy BlazeDS. Tôi muốn xử lý thời gian chờ của phiên máy chủ một cách duyên dáng trong môi trường này.Xử lý thời gian chờ của máy chủ tuyệt vời trong BlazeDS

Tôi có các ràng buộc về bảo mật trên dịch vụ, vì vậy máy khách xác thực đối tượng từ xa bằng cách khởi tạo một ChannelSet dựa trên đích, sau đó đăng nhập bằng ChannelSet đó.

Sau khi người dùng được xác thực, nếu họ nhận được một tách cà phê (dài), phiên của họ chắc chắn sẽ hết thời gian chờ.

Tôi muốn khách hàng phát hiện thời gian chờ và đưa người dùng trở lại trang đăng nhập, với các thông báo thích hợp.

Nhưng tôi gặp khó khăn khi tìm cách tốt nhất để phát hiện thời gian chờ này từ ứng dụng khách. Là nó có thể, hoặc tôi phải có máy chủ ném một lỗi khi thời gian chờ xảy ra?

Cảm ơn!

Trả lời

0

Xem tài liệu và xem sự kiện có được kích hoạt hay không khi kết nối bị ngắt kết nối. Tôi sẽ tưởng tượng rằng có. Nếu không, hãy sử dụng thử/nắm bắt các kết nối của bạn và nắm bắt mọi vấn đề liên quan đến kết nối. Nếu bạn làm như vậy, hãy chuyển hướng ứng dụng của bạn và thông báo cho người dùng. Bạn có thể sẽ cần phải chơi với nó để tìm các mã lỗi chính xác được ném cho các vấn đề kết nối nhưng nó phải được khá dễ dàng trong gỡ lỗi.

0

Tôi gặp sự cố này trên một dự án, đặc biệt vì BlazeDS có thời gian chờ phiên khác với ứng dụng thực tế (sử dụng một dấu hiệu đơn trên kiến ​​trúc thông qua ClearTrust). Do lưu ý, điều này đã được trong một môi trường JBoss. Tôi đã kết thúc tham gia một cách tiếp cận khá đơn giản bằng cách tìm kiếm cụ thể 2 errorCodes trong xử lý lỗi (đã có một lớp cơ sở với một xử lý lỗi phổ biến): DuplicateSessionDetected and DeliveryInDoubt. Tôi thấy DuplicateSessionDetected bất cứ khi nào BlazeDS cố gắng tạo một phiên mới cho cùng một phiên ID JBoss. DeliveryInDoubt có xu hướng hiển thị đôi khi là tốt, nhưng tôi không chắc chắn lý do tại sao. Khi tôi thấy những mã lỗi đó, tôi đã thực hiện hành động cần thiết để làm mới ứng dụng (tùy theo nhu cầu của bạn, bạn có thể chuyển hướng đến trang đăng nhập hoặc một thứ khác). Rõ ràng, tùy thuộc vào môi trường, bạn có thể phải lắng nghe một mã lỗi khác nhau, và cách tiếp cận này có thể không hoạt động trong mọi tình huống cho các môi trường khác nhau/configs/etc.

Một cách tiếp cận khác đã được thảo luận là sử dụng bộ hẹn giờ trong ứng dụng Flex đại diện cho bộ đếm thời gian chờ của BlazeDS, nhưng tôi không phải là người hâm mộ có hẹn giờ ngồi quanh đó. Tôi cũng đã nghe nói về việc gửi một ít dữ liệu qua lại cho máy chủ để kiểm tra thời gian chờ, nhưng một lần nữa, điều đó có vẻ ít hơn lý tưởng.

+0

Bạn đang sử dụng phiên bản BlazeDS nào? – Rydell

+0

chúng tôi đang sử dụng 3.2.0.3978 – pinkeerach

1

Chúng tôi đã viết một thành phần tùy chỉnh cho khách hàng nắm bắt các sự kiện phím và chuột và sau đó xử lý thời gian chờ trên máy khách.

+0

Không có cách nào để phát hiện thời gian chờ ở phía máy khách vì vậy đây là giải pháp lý tưởng. Nếu bạn đặt thời gian chờ trên máy khách là hơi ít thì máy chủ này hoạt động thực sự tốt. –

+1

Sự kiện 'IDLE' sẽ giải quyết vấn đề này cho bạn out-of-the-box: http://bit.ly/cQljgq –

0

Tôi gặp sự cố này trong một trong các dự án của tôi. Những gì tôi đã làm để khắc phục điều đó là mỗi lần máy khách truy cập vào máy chủ, hoặc qua RemoteObject hoặc HTTPService, nó sẽ kiểm tra xác thực của người dùng trước, nếu nó đã hết thời gian, nó sẽ trả về một cái gì đó và nếu nó tốt thì nó sẽ tiếp tục quá trình của nó. Trong sự kiện kết quả xử lý phản hồi của phía khách hàng, máy khách sẽ kiểm tra xem phản hồi có bị hết thời gian chờ không và nếu có, nó sẽ chuyển tiếp tới trang đăng nhập một lần nữa. Theo như tôi biết không có cách nào máy chủ sẽ ném một lỗi cho khách hàng khi phiên của người dùng hết thời gian chờ. Bạn sẽ chỉ biết phiên thời gian chờ ra trên truy cập tiếp theo của bạn đến máy chủ.

0

Triển khai giao diện FlexSessionListener ở phía máy chủ. Nó cung cấp một cách để xử lý việc tạo/hủy phiên Flex trước khi chúng thực sự được thực hiện.

Trên phiên làm việc Xử lý được xử lý nhanh nhất, hãy sử dụng một Nhà sản xuất nhắn tin để gửi thư từ máy chủ đến máy khách cho biết rằng phiên sắp hết hạn.

+0

Vấn đề với điều này là các lớp trừu tượng FlexSession và FlexClient chỉ phơi bày một cách tĩnh để nghe phiên/khách hàng tạo sự kiện. Nhìn vào mã, tập hợp các trình lắng nghe phá hủy không được lưu trữ theo cùng một cách tĩnh, vì vậy thậm chí ghi đè các lớp sẽ không cung cấp cách dễ dàng để thực hiện việc này. Dường như với tôi, họ ngây thơ đã cho người dùng cuối của API BlazeDS một cách dễ dàng để thực hiện điều này trên máy chủ – Alex

1

Chúng tôi đã triển khai dịch vụ giao diện người dùng tùy chỉnh ping liên tục máy chủ (1 ping/10 phút) để ngăn Máy chủ ứng dụng ngừng hoạt động kết nối. Chúng tôi cũng chạy một số bộ đếm thời gian giao diện người dùng nội bộ bị xóa mỗi khi có bất kỳ yêu cầu nào (ngoại trừ "ping") với chức năng gọi điện hoàn toàn để chuyển về đăng nhập và hiển thị "Phiên hết hạn do khách hàng không hoạt động".

1

Đây không phải là cụ thể cho BlazeDS, nhưng như Flex 4.5 (có thể sớm hơn) có một mã cụ thể lỗi trên các sự kiện lỗi cho các lỗi timeout:

Trong xử lý lỗi của bạn:

if(faultEvent.fault.faultCode == "Client.Error.RequestTimeout"){ 
    trace("TIMEOUT ERROR"); 
} 
0

Mở rộng CallResponder và ghi đè phương pháp lỗi.

Kiểm tra dữ liệu.fault.faultMã mã cho các mã lỗi đã biết, chẳng hạn như ErrorMessage.MESSAGE_DELIVERY_IN_DOUBT.

Nếu bạn nhận được lần truy cập, hãy sử dụng hàm gốc navigationToURL để chuyển hướng.

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