On Fri, Feb 22, 2013 at 4:14 AM, Kelven Yang <kelven.y...@citrix.com> wrote:
> Rohit,
>
> I don't think the memory issue is related to auto-scanning, I'm
> investigating the heap dump now and will update the thread once I've
> nailed down the root cause.
Hi Kelven,
You're correct, in my case both with autoscanning+annotations and no
autoscanning + no annotation, there was not much difference (about few
MBs). The only flexibility with xml way is to enforce aop etc. on it
and not make spring a build time dependency. If you think we should go
the xml way, let me know I already have the fix for that.
The problem as Prasanna hints should be in applicationContext.xml
where we're adding proxies for all the classes and methods
(captureAnyMethod), see;
<aop:config proxy-target-class="true">
<aop:aspect id="dbContextBuilder" ref="transactionContextBuilder">
<aop:pointcut id="captureAnyMethod"
expression="execution(* *(..))"
/>
Thanks and regards.
>
> Kelven
>
> On 2/21/13 7:20 AM, "Rohit Yadav" <bhais...@apache.org> wrote:
>
>>I've a fix that works so far so good, let's hear from Kelven.
>>
>>Regards.
>>
>>On Thu, Feb 21, 2013 at 7:50 PM, Chip Childers
>><chip.child...@sungard.com> wrote:
>>> On Thu, Feb 21, 2013 at 02:03:25PM +0530, Prasanna Santhanam wrote:
>>>> On Thu, Feb 21, 2013 at 12:57:07PM +0530, Prasanna Santhanam wrote:
>>>> > On Thu, Feb 21, 2013 at 11:35:15AM +0530, Marcus Sorensen wrote:
>>>> > > We began seeing this at the point of the 4.1 cut. Our xen devclouds
>>>> > > stopped working until we increased the dom0 RAM to 1.5GB. Nobody
>>>>else
>>>> > > was complaining, and most people don't run the mgmt server in
>>>> > > devcloud, so I was just waiting to see where the conversation about
>>>> > > memory went on the MAVEN_OPTS e-mail thread.
>>>> >
>>>> > actually the devcloud-ci job broke soon as javelin came to master and
>>>> > the 2g recommendation wasn't useful for a machine that ran several
>>>> > devcloud workers. There was no hope for that machine that has since
>>>> > been recommissioned, the job deleted and now repurposed to build
>>>> > systemvms instead. If the memory overhead is fixed I can bring the ci
>>>> > back up.
>>>> >
>>>>
>>>> Alex posted CLOUDSTACK-1276 and quoted 4.1 would be difficult to ship
>>>> with autoscanning turned on. A sudden increase in memory requirements
>>>> post upgrade to 4.1 is going to be a surprise in a production
>>>> deployment (which should have enough memory) but I'd rather not depend
>>>> on that assumption.
>>>>
>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-1276
>>>>
>>>> --
>>>> Prasanna.,
>>>>
>>>
>>> Good call to bump that to blocker.
>>>
>>> Kelvin - adding you to the CC for this thread as a heads up, in case you
>>> didn't notice this thread or CLOUDSTACK-1276 being bumped to blocker.
>>>
>>> -chip
>
