-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SST Engine with MarshalMethod BP5: Loses content of vector<string>-type attributes #3453
Comments
Ah, nevermind, I have an explanation. If you add IO.SetParameter("UseOneTimeAttributes", "true") to your writer code, I think you'll find that the problem goes away. The original BP5 approach to attributes was borrowed from the FFS marshaling method, which was adapted directly from the approach to variables. But attributes and variables don't really have the same properties WRT how they appear in metadata, so it was always more of a "until we do this better" solution. The "OneTimeAttributes" approach is a reconsidered solution. It's used by default in BP5 files, but we hadn't changed the default in SST. Given that the old approach doesn't properly implement arrays of strings, it's probably time to change the default over to the new technique. |
Hey Greg,
|
Hmm. I wasn't working with your simple examples, but instead uncommented the "array of strings" attribute portion of TestCommon{Write/Read}Attrs. Not sure why the smaller case is different, but I'm not sure it matters. The deal here is that the older way of handling attributes in BP5 (which apparently doesn't handle arrays of strings) creates a record containing all attributes anytime one is added or changes. This is handy in SST, because if a reader arrives in the middle of a stream we want to give him all the active attributes and we only have to send him the most recent record to do that. But it's terrible if there are a lot of attributes and they change a lot. In the "OneTimeAttr" approach, each attribute is only encoded when it is defined or updated. This is more efficient, because we only encode changes, but it makes things more awkward for SST to support new readers getting all the previously-defined attributes. Thus we had left SST on the old mechanism until that could be reworked. So, to fix this we either have to implement array of strings in the old way, or fixup SST to work with attribute diffs rather than complete attribute blocks. The former might be quicker, but the latter is likely more forward-looking. |
Describe the bug
When using the MarshalMethod BP5 in the SST engine, the content of attributes containing vectors of strings are lost. The attribute can be inquired by the reader, but the vector is empty.
To Reproduce
Writer:
Reader:
Running this:
Expected behavior
Same as when using the default MarshalMethod:
Desktop (please complete the following information):
Additional context
@pnorbert This reproduces the issue mentioned yesterday
Following up
Was the issue fixed? Please report back.
The text was updated successfully, but these errors were encountered: