Re: InactivityMonitor - OOME on sleep

[tabish...@gmail.com]

I think a quick fix is to change from calling scheduleAtFixedRate to just
calling schedule, this different being the way the interval between
executions is controlled.  

For scheduleAtFixedRate which we use now execution rate is scheduled based
on the time that the task was first scheduled.  



> In fixed-rate execution, each execution is scheduled relative to the
> scheduled execution time of the initial execution. If an execution is
> delayed for any reason (such as garbage collection or other background
> activity), two or more executions will occur in rapid succession to "catch
> up." In the long run, the frequency of execution will be exactly the
> reciprocal of the specified period (assuming the system clock underlying
> Object.wait(long) is accurate). 
> 

For schedule the rate is controlled based on the time of the last execution:



> In fixed-delay execution, each execution is scheduled relative to the
> actual execution time of the previous execution. If an execution is
> delayed for any reason (such as garbage collection or other background
> activity), subsequent executions will be delayed as well. In the long run,
> the frequency of execution will generally be slightly lower than the
> reciprocal of the specified period (assuming the system clock underlying
> Object.wait(long) is accurate). 
> 

In the case of the write check task I'd think that it'd be better to have
the occasional delays that can occur because of garbage collection etc vs
having write checks occur in quick rapid fire succession because things got
slowed down since once you do one write check, then you don't need to do
another until the next configured interval.  

Regards
Tim.

http://fusesource.com



Gary Tully wrote:
> 
> hmm, that sounds like a reasonable theory... seems like a scheduled
> executor is the answer or a scheduler that uses cpu relative time...
> so that sleep time is ignored.
> 
> Can you raise a jira issue to track this, there are a few schedulers
> in the code base, so they may all need the same treatment.
> 
> On 13 July 2011 22:45, Michael Brewer-Davis
>  wrote:
>> Using activemq 5.4.0 for a P2P desktop applicaiton, I get an OOME when my
>> computer awakes from sleep:
>>
>> Exception in thread "InactivityMonitor WriteCheck"
>> java.lang.OutOfMemoryError: unable to create new native thread
>>
>> The cause appears to be:
>>  - WRITE_CHECK_TIMER schedules checks at a fixed rate
>>  - ASYNC_THREADS uses an unbounded thread pool to service the checks
>>
>> When the computer wakes, WRITE_CHECK_TIMER satuates the system with pent
>> up
>> requests and uses up all available threads.
>>
>> Am I right in thinking:
>>  - this is an issue
>>  - some options for resolution are:
>>     bounding the ASYNC_THREADS
>>     converting WRITE_CHECK_TIMER to a scheduled executor, which would run
>> the submitted task serially
>>
>>
>> michael
>>
>>
> 
> 
> 
> -- 
> http://fusesource.com
> http://blog.garytully.com
> 


--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Possible-memory-leak-tp3665094p3667681.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Static link ActiveMQ-CPP on Mac OS X

[tabish...@gmail.com]

Can you give the ActiveMQ-CPP 3.4.x branch in SVN a try, I have back-ported
some fixes that may resolve this issue.

https://svn.apache.org/repos/asf/activemq/activemq-cpp/branches/activemq-cpp-3.4.x

Thanks.

--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Static-link-ActiveMQ-CPP-on-Mac-OS-X-tp3986182p4016377.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: size lib cms

[tabish...@gmail.com]

Have you attempted to use the strip command to remove all debug symbols from
the library, they are included by default but can be removed once you are
confident your application will no longer need them. 



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/size-lib-cms-tp4675178p4675336.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ broker 5.9 doesn't close TCP connection if qpid client close amqp connection

[tabish...@gmail.com]

I created a test case that shows the issue and opened a new Jira issue to
track the progress.
https://issues.apache.org/jira/browse/AMQ-4962




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-broker-5-9-doesn-t-close-TCP-connection-if-qpid-client-close-amqp-connection-tp4675756p4676058.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ broker 5.9 doesn't close TCP connection if qpid client close amqp connection

[tabish...@gmail.com]

This is now fixed on trunk, use the latest 0.26-SNAPSHOT of QPid client for
best results. 



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-broker-5-9-doesn-t-close-TCP-connection-if-qpid-client-close-amqp-connection-tp4675756p4676063.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: AmqpProtocolException: Could not decode AMQP frame

[tabish...@gmail.com]

My guess on this one is that you are sending using the async send mode and
closing the connection very quickly after a send which results in an
incomplete frame on the wire.  



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/AmqpProtocolException-Could-not-decode-AMQP-frame-tp4680794p4681124.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Question on failover transport options

[tabish...@gmail.com]

I've created an issue to track the behaviour as it's not really what you'd
expect and resolved it in ActiveMQ trunk and ActiveMQ-CPP trunk and the
3.8.x fixes branch.  Should work as you expected now.  



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Question-on-failover-transport-options-tp4681936p4682276.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.