13 lines
1.1 KiB
Markdown
13 lines
1.1 KiB
Markdown
TODO & DESIGN LIMITATIONS
|
|
=========================
|
|
|
|
* !!!! lock up multi-threaded unsafe data structures
|
|
|
|
* The rabbitmq connection isn't pooled. Throughput limitation (but could be resolved by just starting more instances of JamWebsocket behind Haproxy)
|
|
* The database connection isn't pooled. Throughput limitation (but could be resolved by just starting more instances of JamWebsocket behind Haproxy)
|
|
* We make just one user topic registration and session registration for all users/sessions. If ever we had 10 of servers, it could be wasteful. It just depends on how fast the bogus messaging can be ignored
|
|
* The database connection is pooled.
|
|
* The user model is stored in memory, meaning periodically it should be reloaded from the database (in case a user was marked inactive and you want them knocked out of the system)
|
|
* The user could easily join to multiple sessions. Currently, though, the ClientContext object only tracks one jam session topic subscription. This is minimial to change.
|
|
* peek logic not implemented on server for protoc messages; this could be done to save cost of deserialization and serialization for session/user directed messages
|