Milestones
List view
- No due date•0/3 issues closed
Currently, partitioning works correctly for files that are large, and static. One can split a file into p partitions and have them traverse a network of pumps, and the partitions will be re-assembled only at the end where final consumers want them to be reassembled. so far, so good. When transferring partitions, the parts get the following suffix: .part.bsz,blktot,brem,bno (see sr_post(7) and sr_postv3(7) for detailed meaning of the fields) the problem with this suffix is that blktot, and brem will change as the file grows. So the resolution for this is for the partition file name suffixes to be something like: .part.bsz,bno and persist the full partition info to disk (xattr.) use cases we have difficulty with right now: log files, backups, genetic code dumps... Approach: 1. build a reproducible test case (start with a small file) announce it in partitions, transfer as partitions, then re-assemble at a second hop. 2. start appending to the file to reproduce the problem. 3. fix it.
No due date•3/8 issues closedStep 0: full v03 support (message in JSON body rather than AMQP headers), required to work MQTTv3 compatibility. Step 1: ability to send to an MQTT broker (exp_2mqtt.py) Step 2: Would like to see if MQTT clients can consume from a Sarracenia data pump, using the rabbitmq mqtt plugin. Step 3: ?
No due date•4/4 issues closed