2013-04-13 44 views
5

Đây là câu hỏi gồm hai phần, trước hết là một câu hỏi thiết kế hơn là cách thực hiện nó, và thứ hai là một số mối quan tâm thực hiện với Akka.Câu hỏi Akka, Scalatra và Web state

Tôi đang sử dụng Scalatra để xây dựng điểm kết thúc dịch vụ REST khi được gọi sẽ kéo hình ảnh từ nhiều nguồn, thao tác và trả lại chúng. Đây có thể là một quá trình chạy khá dài và có khả năng lâu hơn sẽ được chấp nhận cho một chu kỳ yêu cầu/phản hồi http đơn lẻ. Suy nghĩ của tôi về điều này là khi cuộc gọi được thực hiện, tôi sẽ khởi động một loạt các diễn viên để kéo các tài nguyên hình ảnh, và họ đã đưa kết quả cho các diễn viên xử lý hình ảnh để mở rộng vv. Yêu cầu ban đầu sẽ quay trở lại ngay lập tức một số loại Id xử lý có thể được sử dụng để thực hiện các cuộc gọi thăm dò tới một điểm kết thúc khác sẽ trả về kết quả khi chúng được xử lý, với cờ để xác định xem có nhiều kết quả hơn không để cho khách hàng biết ngừng bỏ phiếu.

Câu hỏi của tôi, như sau:

  1. Liệu điều này làm cho cảm giác từ một quan điểm thiết kế của xem?
  2. Nếu tôi sử dụng phương pháp này thì mỗi yêu cầu tiếp theo để truy xuất hình ảnh đã xử lý sẽ phải có một số loại nhận thức của tiểu bang để biết hình ảnh nào khách hàng đã nhận được. Làm cách nào bạn quản lý trạng thái này?
  3. Tôi chưa bao giờ xem xét điều này, nhưng yêu cầu HTTP kiểu sao chổi chạy dài có ý nghĩa hơn là bỏ phiếu trong tình huống này không?

Thực hiện Phần

Giả sử tôi kết thúc với một thiết kế tương tự như trên, Tôi rất mới để Scalatra & Akka (hoặc bất kỳ mô hình diễn viên) và tôi có một vài câu hỏi.

Ok, câu hỏi đầu tiên là một câu hỏi cụ thể về Scala/Scalatra I nghĩ rằng. Ok, tôi nhìn vào các tài liệu Scalatra trên AKKA http://www.scalatra.org/guides/async/akka.html, và trong ví dụ này họ thiết lập các ứng dụng bootstrap như sau:

// Get a handle to an ActorSystem and a reference to one of your actors 
    val system = ActorSystem() 
    val myActor = system.actorOf(Props[MyActor]) 

    // In the init method, mount your servlets with references to the system 
    // and/or ActorRefs, as necessary. 
    override def init(context: ServletContext) { 
    context.mount(new PageRetriever(system), "/*") 
    context.mount(new MyActorApp(system, myActor), "/actors/*") 
    } 

Tôi giả định rằng bootstraping của scalatra xảy ra một lần khi khởi động ứng dụng, thì system.actorOf (Đạo cụ [MyActor]) tạo một cá thể đơn lẻ hoặc một bản sao cho mỗi yêu cầu?

Thứ hai, nói lớp MyActor của tôi (hoặc một tên hợp lý hơn) đã làm như sau:

class MyActor extends Actor { 
    def receive = { 
    //Find the [ImageSearchingActor] actor in akka registry and send search message 
    case initiateSearchRequest: InitiateSearchRequestMessage => TODO 

    //Find free [ImageProcessingActors] in akka registry and send each Image url to process 
    case imageInformationFound : ImageInformationFoundMessage => TODO 

    //Persist the result to a cache, or data store with the ProcessingId that all message will pass 
    case imageProcessed : ImageProcessedMessage => TODO 
    } 
} 

Bây giờ, trong trường hợp này nhiều có nhiều nơi tôi sẽ được lấy hình ảnh và rất nhiều diễn viên sẽ được grabbing dữ liệu này. Khi họ tìm thấy hình ảnh phù hợp, một số diễn viên sẽ được sử dụng để xử lý hình ảnh. Nếu tôi đi với thiết kế của tôi sau đó tôi cần phải cờ một nơi nào đó cho một ProcessingId nhất định không có hình ảnh xử lý nhiều hơn có sẵn. Điều này có nghĩa là tôi cần biết khi nào TẤT CẢ các hình ảnh tìm kiếm và các diễn viên xử lý hình ảnh đã hoàn thành cho một ProcessId đã cho. Làm thế nào để tôi làm điều này?

Vì vậy, đó là rất nhiều câu hỏi, thông tin để tiêu thụ Tôi hy vọng nó có ý nghĩa.

Chúc mừng. Chris.

Trả lời

3

Khá nhiều câu hỏi ở đây.Trả lời nhanh:

  1. Vâng, tôi nghĩ vậy.

  2. Bạn có thể muốn sử dụng một lớp Actor làm bộ tổng hợp, tổng thể hoặc điều phối viên, khởi động quá trình truy xuất hình ảnh và lớp diễn viên xử lý hình ảnh. Trình tổng hợp sau đó chứa logic khi tính toán tổng thể của bạn có thể được coi là hoàn chỉnh. Có một vài ví dụ về loại điều này nổi trên internet, nếu bạn muốn các ví dụ cụ thể phù hợp với những gì bạn đang làm, hãy đảm bảo rằng bạn xem các ví dụ Akka 2.1.x, vì đó là những gì bạn có thể cần nếu bạn ' tái sử dụng codebase Scalatra hiện tại.

  3. Có thể là một ý tưởng hay. Scalatra có một sự tích hợp với khung công tác Atmosphere, làm cho nó dễ dàng thực hiện việc bỏ phiếu dài trên websocket/comet. Bạn có thể đọc khoảng in the docs. Cho dù điều đó có ý nghĩa đối với ứng dụng của bạn hay không phụ thuộc vào nhiều yếu tố, nhưng nó đáng xem. Trong lập trình socket kinh nghiệm của tôi đôi khi có thể là tuyệt vời và đôi khi rắc rối hơn nó có giá trị - nếu bạn đang đi qua rất nhiều proxy, ví dụ, websockets có vấn đề, trừ khi SSL đang được sử dụng. Đó là một điều tuyệt vời, tuy nhiên, để xem thông tin được đẩy vào khách hàng ngay sau khi nó có sẵn.

Để các câu hỏi khác, khoảng ActorSystem tạo:

Trong Scalatra, bộ điều khiển của bạn được khởi tạo trên một cơ sở cho mỗi yêu cầu; ActorSystem trong mã ví dụ của bạn chỉ được khởi tạo một lần. Bất cứ khi nào một yêu cầu đến trong cửa, một cá thể bộ điều khiển mới được tạo ra, với một tham chiếu đến ActorSystem.

Diễn viênSự tạo hệ thống là a heavyweight operation và sẽ xảy ra vài lần khi bạn có thể sử dụng.

+0

Câu trả lời rất hoàn chỉnh, cảm ơn bạn. Tôi đang nghĩ rằng sao chổi không có ý nghĩa cho điều này vì những yêu cầu này sẽ đến từ nhiều nguồn và tôi không muốn áp đặt điều này lên chúng. Tôi sẽ đánh dấu điều này là chính xác, nhưng tôi thiếu điểm về cách ActorSystem khởi tạo các diễn viên. Điều này là do làm thế nào tôi hỏi câu hỏi của tôi, đó là ngu ngốc khi rereading :-). – Owen

+0

Vì vậy, tôi hỏi nếu system.actorOf (Đạo cụ [MyActor]) sẽ instansiate một MyActor mới cho mỗi yêu cầu, nhưng rõ ràng nó sẽ không. Nhưng nếu tôi không chuyển tham chiếu đến MyActor cho bộ điều khiển, và chỉ ref cho ActorSystem, sẽ gọi actorOf tạo một cá thể mới mỗi lần? Nếu vậy làm cách nào để kiểm soát số lượng diễn viên được tạo? Lý tưởng nhất, tôi muốn có một nhóm những người có sẵn để lựa chọn. Trên thực tế, trên suy nghĩ thứ hai nevermind, tôi nên đọc các tài liệu một số chi tiết và ngừng đặt câu hỏi :-) – Owen

+0

Tôi đoán tôi có vẻ hơi tiêu cực trên mặt trước ổ cắm. Hãy nhớ rằng Khí quyển không rơi vào tình trạng bỏ phiếu dài trong các tình huống mà các ổ cắm web sẽ không ổn định, vì vậy chúng vẫn có giá trị để thử. – futurechimp