In DefaultAttributeContainer
private final Map<AttributeKey<?>, Object> attributes = new
HashMap<AttributeKey<?>, Object>();
we could use a ConcurrentHashMap, and get rid of the locks no ?
On Fri, Mar 22, 2013 at 8:57 PM, Julien Vermillard <[email protected]>wrote:
> hmm we have a lock on all session attributes, why ?
>
>
> On Fri, Mar 22, 2013 at 5:54 PM, Emmanuel Lécharny <[email protected]>wrote:
>
>> Hi,
>>
>> as I'm implementing the UDP server, and got really low performances
>> compared to the same test done on MINA2, I did some profiling. It
>> appears that the idle processing is a bit of a bootleneck, the way it's
>> currently implemented.
>>
>> For instance, we grab the WRITE_IDLE_INDEX from the session attributes,
>> and update it :
>>
>> public void sessionWritten(final AbstractIoSession session, final
>> long timeInMs) {
>> final Integer oldIndex = session.getAttribute(WRITE_IDLE_INDEX);
>> ...
>> session.setAttribute(WRITE_IDLE_INDEX, index);
>> }
>>
>> Accessing the WRITE_IDLE_INDEX attribute is done with this method :
>>
>> public final <T> T getAttribute(final AttributeKey<T> key) {
>> return attributes.getAttribute(key);
>> }
>>
>> which calls :
>>
>> public <T> T getAttribute(AttributeKey<T> key) {
>> assertNotNull(key, "key");
>> readLock.lock();
>>
>> try {
>> T value = (T) attributes.get(key);
>>
>> return value;
>> } finally {
>> readLock.unlock();
>> }
>> }
>>
>> So far, so good, except that we acquire a lock and release it for every
>> call.
>>
>> Wouldn't it be better to store the WRITE_IDLE_INDEX as an AtomicLong in
>> the session itself ?
>>
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>>
>
