csync / csync-server Goto Github PK

mkistler commented on Mar 9, 2016
To make the live data path more efficient, we should allow the server to send multiple items (as many as are available to send, up to some limit) in a "data" message to clients.

https://hub.docker.com/r/ibmcom/csync/
https://hub.docker.com/r/ibmcom/csync-base/

• Add ability to modify ACLs from the dataviewer

• Set default ACL when creating node from inside dataviewer

• Ensure each node has own ACL vs it's parents if they are different

• When no node is selected, remove ACL div

Hi! You said what it does but when and why do I want to use it?

mkistler commented on Nov 17, 2015
We should have micro benchmarks to measure latency of various operations like: pub, advance, ??

tmpreiss commented on Dec 13, 2016
Advance and fetch are stateless in that the protocol allows for missed packets and missed requests so this lends itself to a stateless RESTful endpoint.

Server Version: 1.0.0

Details: Include full key in dataviewer Key section when node is selected

rajamony commented on Aug 25, 2015
This is a tough one (to describe and implement). Today, when a user session closes, we "remove" it and call the cleanup method on UserSession. This in turn flushes the FQ (by calling q.flush), which causes all pending messages for the session that haven't yet been delivered to them to get discarded. A better option would be to not just flush them but instead stuff them in the rabbit message queue. It isn't straightforward to implement (I think) because by the time you are invoking the flush on FQ, you may have canceled the mq. So some thought is required here on how it gets done.

The current mode of operation does not cause a correctness problem. A client will (eventually) reconnect and then either republish or resubscribe and things will all go right again. This fix is really about (a) optimizing what might be a corner case (b) making the flow more elegant.

Server Version: 1.0.1
Client Version: 1.0.1

Steps to Reproduce:

• Write a.b.c directly to the CSync instance.
• Then write a.b.d
• Delete c

Expected Behavior: c should be deleted
Actual Behavior: c and d are deleted

• Ensure each node has own default ACL when created from the dataviewer

• When no node is selected, remove ACL div

• Disable Delete and Edit buttons when no nodes are available

tmpreiss commented on Dec 13, 2016
When testing the fetch response from the android sdk, we found that sending rvts instead of vts, the server logs show that there is a Validation error in the request and the server closes the connection.

In the event the server receives a malformed packet. should the server close the websocket or should it just return an error for the one message?

• https://github.ibm.com/csync/csync-server/wiki/Create-a-CSync-Instance-on-Bluemix

• https://github.ibm.com/csync/csync-server/wiki/Create-a-CSync-Instance-on-Amazon-Web-Services

• setup HAProxy
• load testing

kba commented on Aug 21, 2015
A nice extension of the current functionality is to allow "transient" or "ephemeral" writes -- meaning writes of data to be disseminated to all current listeners but not persisted in the database. This would be useful for data that quickly loses its value with the passage of time, e.g. statistics about current connections. This amounts to skipping the DB operation and simply posting the data to the message queue -- conceptually very simple. The data would have to be marked as transient so that clients would know not to persist it in local DBs as well.

This seems like a potentially useful enhancement but we need to validate that there are real user requirements for it before applying resources.

mkistler commented on Mar 16, 2016
Clients must issue advance for every ACL they have read access to, but this set of ACLs can change, and we currently have no mechanism for refreshing or updating the client with the correct set of ACLs. We need to design and implement this mechanism.

mkistler commented on Mar 18, 2016
We actually need to address two related issues:

1. Client must refresh it's set of readable ACLs when necessary
2. Queue bindings must be updated when ACLs change

Client must clean up DB to eliminate any data not for ACLs the client can read.

laik commented on Feb 25, 2016
As a user I would like to listen on a key and receive only a subset of values at a time.

Sorting needs to be determined.

mkistler commented on Mar 16, 2016
The client must send regular advance messages to the server to check for missing data, and advance is specific to ACL, so for a user that has read access to n ACLs, this means n regular messages from client to server and back every advance interval (currently 5 seconds). We should find some way to batch some or all advance requests in one message to reduce message traffic between client and server.

Server Version: 1.0.0

https://github.com/csync/csync-server/wiki/Create-a-CSync-Instance-on-Bluemix

laik commented on Oct 24, 2016 • edited
Sample project using bluemix container deployment:

https://github.com/Puquios/hello-containers

Server Version:Master
Client Version:
Steps to Reproduce:

• Pub(103, Seq("a", "b", "*"), Some("z"), false, None, None)
• Basically, pub create on a wildcard
  Expected Behavior: Should fail or return an error
  Actual Behavior: Creates a node on "a.b"

tmpreiss commented on Dec 16, 2016
It is worth investigating different test flag options listed in http://www.scalatest.org/user_guide/using_the_runner

Server Version: 1.0.0

Expected Behavior: Should run the tests
Actual Behavior: The setup currently fails on Travis