On Mar 12, 2006, at 6:07 PM, Trustin Lee wrote: On 3/13/06, peter royal <[EMAIL PROTECTED]> wrote: On Mar 12, 2006, at 1:08 AM, [EMAIL PROTECTED] wrote: > * Returns a new (or reusable) instance of [EMAIL PROTECTED] > ProtocolEncoder} which > * encodes message objects into binary or protocol-specific data. > */ > - ProtocolEncoder getEncoder(); > + ProtocolEncoder getEncoder() throws Exception; > > /** > * Returns a new (or reusable) instance of [EMAIL PROTECTED] > ProtocolDecoder} which > * decodes binary or protocol-specific data into message objects. > */ > - ProtocolDecoder getDecoder(); > + ProtocolDecoder getDecoder() throws Exception;
Performance will suck if shared instances are returned due to synchronization on the returned instances in the ProtocolCodecFilter... Unless the synchronization is removed, it would be unadvisable to return shared instances. It depends on the implementation of codec. Some codec might be stateless so they don't need any synchronization. Of course, a codec factory usually returns a new instance. It's a user's choice.
No, regardless of codec implementation...
look in messageReceived.. it synchronizes on decoder, prior to doing decoder.decode. So if you have a ProtocolDecoder that is stateless that could be shared, you will not be able to decode multiple messages in parallel.
-pete
|
smime.p7s
Description: S/MIME cryptographic signature