You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here is an example of a supervoxel (1000417481) which was split a long time ago, back in node 017ad, but is not mentioned in the kafka log. Do we know exactly when kafka logging was first enabled?
At the very least, this indicates that when our production server's internal mutation log is finally updated to include all split events, we cannot rely solely on the kafka log.
Analysis
(The following assumes you've installed neucleasevia conda install -c flyem-forge neuclease)
First, does the kafka log mention this supervoxel?
In [1]: from neuclease.dvid import *
In [2]: from neuclease import configure_default_logging
In [3]: configure_default_logging()
In [4]: splits_df = fetch_supervoxel_splits('emdata3:8900', '9e0d', 'segmentation', source='kafka', format='pandas')
INFO [2018-09-10 16:54:49,440] Reading kafka messages from ['kafka.int.janelia.org:9092', 'kafka2.int.janelia.org:9092', 'kafka3.int.janelia.org:9092'] for emdata3:8900 / 9e0d / segmentation
INFO [2018-09-10 16:55:40,647] Reading 912094 kafka messages took 51.20722818374634 seconds
In [5]: splits_df.head()
Out[5]:
uuid mutid old remain split type
0 017ade09fc214382acba582a97db9164 1 1329532718 5812984423 5812984422 split-supervoxel
1 017ade09fc214382acba582a97db9164 2 1341870875 5812984425 5812984424 split-supervoxel
2 017ade09fc214382acba582a97db9164 3 1345855821 5812984427 5812984426 split-supervoxel
3 017ade09fc214382acba582a97db9164 4 1351234270 5812984429 5812984428 split-supervoxel
4 017ade09fc214382acba582a97db9164 5 1354640265 5812984431 5812984430 split-supervoxel
In [6]: 1000417481 in splits_df['old'].values
Out[34]: False
OK, it's not in the kafka log. In which UUID did it disappear?
According to Bill, if you sift through the http logs for emdata3:8900, you can see that it was indeed split in that node, apparently successfully. So why isn't it in the kafka log?
Other examples
The above situation also applies to the following list of supervoxels (143 of them, including the example above):
This is really issue #316 and could be a queue issue.
I'm confused. This issue is about splits that were recorded in DVID, but not recorded in kafka. But issue #316 is the opposite -- when kafka records a split that was not recorded in DVID. Are those really the same issue?
Here is an example of a supervoxel (
1000417481
) which was split a long time ago, back in node017ad
, but is not mentioned in the kafka log. Do we know exactly when kafka logging was first enabled?At the very least, this indicates that when our production server's internal mutation log is finally updated to include all split events, we cannot rely solely on the kafka log.
Analysis
(The following assumes you've installed
neuclease
viaconda install -c flyem-forge neuclease
)First, does the kafka log mention this supervoxel?
OK, it's not in the kafka log. In which UUID did it disappear?
OK, it was apparently split in node
017a
.According to Bill, if you sift through the http logs for
emdata3:8900
, you can see that it was indeed split in that node, apparently successfully. So why isn't it in the kafka log?Other examples
The above situation also applies to the following list of supervoxels (143 of them, including the example above):
Upon investigation ALL of them were also split in node
017ade09fc214382acba582a97db9164
.The text was updated successfully, but these errors were encountered: