Stability of serialization across boost versions
A program I wrote using the Boost serialization library trips up when communicating with instances of itself on hosts with different versions of the library. terminate called after throwing an instance of 'boost::archive::archive_exception' what(): unsupported version It's not reasonable to require that users of my software upgrade their hosts in lock step with each other, all at once or not at all. But library skew on the order of a bit over two years at least (consider users of Ubuntu LTS) arises naturally and quite often. I think the solution would be for boost serialize to offer an API point that says "write with binary protocol n", which leaves the library free to read with any protocol it knows. When I feel that n+1 has existed for long enough, I can tell my program to use n+1. Unfortunately, and I'd like to be shown wrong, I don't think the library provides such an API point. Any feedback or suggestions other than not using boost for serialization? Jeff Abrahamson http://jeff.purple.com/ http://blog.purple.com/jeff/
A program I wrote using the Boost serialization library trips up when communicating with instances of itself on hosts with different versions of the library.
terminate called after throwing an instance of 'boost::archive::archive_exception' what(): unsupported version
It's not reasonable to require that users of my software upgrade their hosts in lock step with each other, all at once or not at all. But library skew on the order of a bit over two years at least (consider users of Ubuntu LTS) arises naturally and quite often. I think the solution would be for boost serialize to offer an API point that says "write with binary protocol n", which leaves the library free to read with any protocol it knows. When I feel that n+1 has existed for long enough, I can tell my program to use n+1. Unfortunately, and I'd like to be shown wrong, I don't think the library provides such an API point.
Any feedback or suggestions other than not using boost for serialization?
It was my understanding that stuff like that should be supported, if you have a test case then filing a bug report would seem to be in order? John.
On 18/05/2014 4:34 AM, John Maddock wrote:
A program I wrote using the Boost serialization library trips up when communicating with instances of itself on hosts with different versions of the library.
terminate called after throwing an instance of 'boost::archive::archive_exception' what(): unsupported version
It's not reasonable to require that users of my software upgrade their hosts in lock step with each other, all at once or not at all. But library skew on the order of a bit over two years at least (consider users of Ubuntu LTS) arises naturally and quite often. I think the solution would be for boost serialize to offer an API point that says "write with binary protocol n", which leaves the library free to read with any protocol it knows. When I feel that n+1 has existed for long enough, I can tell my program to use n+1. Unfortunately, and I'd like to be shown wrong, I don't think the library provides such an API point.
Any feedback or suggestions other than not using boost for serialization?
It was my understanding that stuff like that should be supported, if you have a test case then filing a bug report would seem to be in order?
Based on the error, it seems like what is happening is that a newer version of Boost is attempting to communicate with an older version of Boost. The actual exception is from the archive itself, IIUC. The library has explicitly said this is not supported, unfortunately. To the OP, I'd suggest not upgrading Boost serialization or requiring upgrading in lockstep. Upgrading multiple hosts in random order means new communicating with old. This is an unsupported use case. Sohail
participants (3)
-
Jeff Abrahamson -
John Maddock -
Sohail Somani