Yes it could but you would you not end up having the overhead of context
switching from the thrown thread interrupts? On a low resource device this
can't be the best of situations I imagine.
On 21 Jun 2012, at 00:16, Yan Zhou <yanzhou_2...@yahoo.com> wrote:
> Any objections if the following is added as a new issue in the issue tracker?
>
> I am thinking that the selectKeys(sleepTime) call below really should be able
> to return immediately (thread interrupted, for example) if there has been a
> connection state change that needs attention. The sleepTime will then have
> little effect on how soon or how often controlConnections() is run.
>
> Thanks,
> Yan Zhou
>
>> Hi,
>>
>> We are noticing that an idling Restlet server has about 2MB of garbage
>> collected in 30 seconds.
>>
>> I think I tracked it down to the loop in ConnectionController that invokes
>> the method below:
>>
>>
>> @Override
>> protected void doRun(long sleepTime) throws IOException {
>> super.doRun(sleepTime);
>> registerKeys();
>> updateKeys();
>> selectKeys(sleepTime);
>> controlConnections();
>> }
>>
>> The sleepTime comes from the controllerSleepTimeMs parameter, which is 1 by
>> default.
>>
>> So if the loop generates 60 bytes of garbage (2 iterator objects), it'd lead
>> to: 60 x 1000 x 30 = 1,800,000 bytes or 1.8MB every 30 seconds.
>>
>> Can I ask if this is a known issue? And if there are workarounds?
>>
>> I have already tried tweaking the controllerSleepTimeMs and changing it to
>> something like 30000 (30 seconds). Every connection then takes up to 30
>> seconds to close - probably not acceptable as a solution.
>>
>> Additional info: Restlet 2.1 rc4 Android edition.
>>
>> Thanks,
>> Yan Zhou
>
> ------------------------------------------------------
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2972283
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2972387
