-----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? - -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
