On Fri, May 15, 2020 at 12:00 AM Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Mark, > > On 5/14/20 14:21, Mark Thomas wrote: > > On 14/05/2020 18:41, Christopher Schultz wrote: > >> Mark, > >> > >> On 5/14/20 12:53, Mark Thomas wrote: > >>> On 14/05/2020 17:46, Mark Thomas wrote: > >>>> On 14/05/2020 16:48, Christopher Schultz wrote: > >>>>> All, > >>>>> > >>>>> I'm interested in the history of the > >>>>> StandardSession.writeObjectData method. I've been looking > >>>>> at it lately because I'm interested in possibly > >>>>> (optionally) encrypting the sessions in the backend session > >>>>> store. But this isn't about encryption at all. > >>>>> > >>>>> The code for > >>>>> StandardSession.doWriteObject(ObjectOutputStream stream) > >>>>> looks like this: > >>>>> > >>>>> > >>>>> // Write the scalar instance variables (except Manager) > >>>>> stream.writeObject(Long.valueOf(creationTime)); > >>>>> stream.writeObject(Long.valueOf(lastAccessedTime)); > >>>>> stream.writeObject(Integer.valueOf(maxInactiveInterval)); > >>>>> stream.writeObject(Boolean.valueOf(isNew)); > >>>>> stream.writeObject(Boolean.valueOf(isValid)); > >>>>> stream.writeObject(Long.valueOf(thisAccessedTime)); > >>>>> > >>>>> > >>>>> Is there any reason we are writing object wrappers for > >>>>> these primitive members instead of just writing the > >>>>> primitives directly? > >>>> > >>>> That code goes all the way back to at least Tomcat 3.1.x > >>>> (20+ years ago). > >>>> > >>>>> It turns out that the byte stream is identical whether one > >>>>> uses objects or primitives, > >>>> > >>>> That surprises me. Looking at the JRE source code it really > >>>> surprises me. So much that I am going to go and try it for > >>>> myself. > >> > >>> My testing shows the opposite. There is a significant > >>> difference between writing primitives and writing objects. > >> > >> Hmm. I did a micro-test with just writing a single > >> Long.valueOf() value and a (primitive) long alone to an > >> ObjectOutputStream. I didn't test the StandardSession itself. > > > > I performed the same micro-test. > > > >>> Given backwards compatibility requirements we can't change this > >>> in 9.0.x and earlier. > >> > >> Agreed. > >> > >>>> One reason we might want to stick with writing objects is to > >>>> support sessionAttributeValueClassNameFilter. I'm only going > >>>> from reading the source so I could easily have missed > >>>> something but it looks like that will only work if we > >>>> write/read objects. > >> > >>> We only care about this for session attributes. We know our > >>> internal attributes are safe so we could switch to primitives > >>> in 10.0.x. > >> > >> I'll have to play-around a bit to see what was wrong with my > >> initial tes t. > > So my test was bunk, the data on-the-wire (so to speak) is very > different, and there is no way at all to make them compatible. :/ > > Perhaps a rewindable input stream would work, but it's just not really > that important. > > I think it's okay to make a breaking change at 10.0, but only if > anyone really cares. It saves a couple of bytes which can add up. > > In my microtest, I wrote a java.lang.Long value and a (primitive) long > to two separate files. The object-file was 82 bytes and the > primitive-file was 14 bytes. It looks like after the 2-byte header and > 2-byte version identifier, the primitive long is written as "block > data" with a 1-byte length (8) and then the 8 bytes of the long. The > object flavor is ... more verbose. > > So we get almost 90% savings for a single long value. On the other > hand, the primitive only values going into sessions are the metadata > and not the attributes, which will dominate the bulk of the data (or > should, anyway). > > I still think this is worth doing. > > Any objections? > Ok. Rémy > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl69sXYACgkQHPApP6U8 > pFi6pg/9ExBQhRRlUv4QPUVDJEhJ8pN6KfBIoHgd/UWw2zYxjeifhDrN+biK2lLG > GHWmJuF+wEAFz9xtYqN46q1QqSKIQcWTAqI05NchNlqFd29JHwj+9QZV00VTd0eK > My4MTCVY4dSObJrePyw14tEHyRVcFl539bDhtez7fnjOGkq4EGNXvr7ep9L3w5GB > ckwKAp1OuFYz5/0ZCCDEVdRiSpoXAac06B5v0FUQb3TBn06gdavUJb9q0HM57RjI > 0FkQHPyZ1ibfWOOLldBrCgA+7SygGiD6LO2nMo5Fgy1A4l5W/uekkhW96FXBKHng > /ocXJRQSkeDoanpQmu5pC/Ru1S0bNjZCIo9OMS0de6iEMEO3wPtvuLYhINYydk6E > 3ZNx+EPZEFPoZuB1K0peWNDgFsE3ar5gL+y6cvztNoZtT1WymoDS6uQ4OvGXcXNL > 61SOSe3CmqHF0dQTlD/Xikakumz4Kefny5QGw/XlchPVNCqUmvgxUwYPb965kwz3 > Vt/3nib0QgKxbR0j54InFIRkG7gPuGyUaL0kwtMbFEdOTw+PqAEyIPSqIRtmkhVG > Mzf6ikh+TOToYi+OIJXUMloaVL8xafAo6hKTc7lbu2hAUv9bE47X6uVyQmD7Yxqu > R3LQGo3OYX9+GBdKBhgvbZB9bEkUImMbsgIXKIUScGaMH4RdtBE= > =AZle > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
