Hash: SHA256


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
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/


To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to