• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Stateful Application Server_JRubyConf13_Lukas Rieder
 

Stateful Application Server_JRubyConf13_Lukas Rieder

on

  • 925 views

After more than one year of development, Wooga is heading for the global launch of its game "Kingsbridge"! ...

After more than one year of development, Wooga is heading for the global launch of its game "Kingsbridge"!

This is the first game at Wooga with a backend written in JRuby!

The talk includes an introduction to the problems that were solved by choosing a stateful applicaton server.

I will explain constraints, benefits and obvious differences to traditional database backed application servers.

Safely sharing state in a concurrent environment using JRuby
Using Java concurrency utils in JRuby
Sample problems solved, backed up with code
Practical tips for capacity planning

Statistics

Views

Total Views
925
Views on SlideShare
922
Embed Views
3

Actions

Likes
3
Downloads
12
Comments
0

1 Embed 3

https://twitter.com 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Stateful Application Server_JRubyConf13_Lukas Rieder Stateful Application Server_JRubyConf13_Lukas Rieder Presentation Transcript

    • stateful application server
    • Hi I’m Lukas @Overbryd
    • Working @Wooga
    • stateful application server
    • database based system
    • app app app load db clients
    • stateful system
    • app app app client
    • app app app dns load clients
    • every server is equal
    • app nginx jvm redis ssd
    • state
    • jvm {}
    • ‣ SessionManager ‣ Session ‣ Resources ‣ Items ‣ Quests ‣ Payments ...
    • the hard part
    • one place at a time
    • easy with one server, but how to scale out?
    • sharding!
    • “static sharding” shard = facebook_id % shards
    • raise Invalid, “wrong shard” unless Shard.valid?(facebook_id)
    • concurrency
    • jvm http threads sessions ticker thread worker threads
    • the hard part
    • serialized access to a session
    • easy for low contention like a single session
    • class Session attr_reader :lock def initialize @lock = Mutex.new end # ... end session.lock.synchronize do session.foo end
    • harder for high contention like the SessionManager
    • class SessionManager @current = ConcurrentHashMap.new def self.get(id) raise WrongShard unless Shard.valid?(id) unless session = @current.get(id) new_session = create(id) unless session = @current.put_if_absent(id, new_session) session = new_session end end session end end
    • t1 t2 {} S S
    • t1 t2 {} S S
    • t1 t2 {} S S session = @current.get(id) # => nil session = @current.get(id) # => nil
    • S2 t1 t2 {} S S
    • S2 t1 t2 {} S S S1 S2
    • S2 t1 t2 {} S S S1 S2 S2
    • S2 t1 t2 {} S S S1 S2 S2 S2
    • S2 t1 t2 {} S S S1 S2 S2 S2
    • S2 new_session = create(id) unless session = @current.put_if_absent(id, new_session) # => nil session = new_session # => #<Session:0x2> end t1 new_session = create(id) unless session = @current.put_if_absent(id, new_session) # => #<Session:0x2> t2 {} S S S1 S2 S2 S2
    • deployment
    • the hard part
    • one place at a time
    • handover
    • app nginx jvm1 jvm2 S1
    • app nginx jvm1 jvm2 S1
    • app nginx jvm1 jvm2 S1
    • app nginx jvm2 S1
    • global state
    • weird problem when handling sharded state
    • even weirder when every machine should be equal
    • app nginx jvm redis ssd
    • global data is kept local
    • populates via UPD broadcast
    • not “a huge” problem if stale
    • last write wins self healing
    • class Broadcast def self.spawn_listener Thread.new do socket = wait_until_socket_bind loop do if @stop_listener socket.close return end message, from = socket.recvfrom(1024) handle_message(message) end end end end
    • appjvm redis appjvm redis internal network jvm
    • appjvm redis appjvm redis internal network jvm
    • appjvm redis appjvm redis internal network jvm