As discussed, lets attach a custom life cycle implementation to
axisServiceContext by checking whether transport session scope is
configured. Within the lifecycle implementation, we can destroy the
ruleSession.

By default we can always dispose the rule session and if the transport
session scope is configured, we can set our custom lifecycle implementation
and differ destorying the rule session. when axis2 called the life cycle
implementation's destroy method rule session will be destroyed.

Then we  will not need additional attributes.

Regards
Nandika

On Sun, Nov 8, 2015 at 7:41 PM, Milinda Perera <milin...@wso2.com> wrote:

> Hi Nandika and all,
>
> During simple load test we observed WSO2 BRS both 2.2.0-SNAPSHOT does OOM
> [1]. After further investigation, found that our implementation misuses
> drools engine.
>
> When request is received by BRS, It creates knowledgeSession from
> KnowledgeBase and feed facts and execute rules.
>
> In Drools there are two types of Knowledge sessions
> *(1) Stateful *[2]
>     Stateless knowledge sessions are long lived and knowledge keeps
> reference until they get disposed. In BRS we have binded Stateful sessions
> with Axis2 sessions.
>
> *(2) Stateless*. [3]
>     Stateless knowledge session is similar to a function, feed facts,
> execute rules and receive results. Stateless knowledge session simply wraps
> Stateful knowledge session and dispose it at the end of execution.
>
> Since the knowledge base[4] keeps reference for Stateful knowledge
> sessions, memory consumed by knowledgeBase get increase and goes OOM, *if
> we don't dispose them*. At the moment there is no dispose mechanism
> included in BRS. Therefore it goes OOM when invoke deployed service
> continuously.
>
> To solve this we have to solve two things:
>     (a) Deviate operations that require stateful or stateless knowledge
> sessions.
>     (b) Dispose stateful knowledge sessions when axis2 session get
> destroyed
>
> I think to solve above mentioned (a), we need mechanism to deviate
> operations require Stateful and Stateless knowledge sessions. One possible
> solution is as follows:
>
> Currently our operation config in .rsl file is as follows:
>
>     <brs:operation name="[OPERATION_NAME]">
>         <brs:input namespace="[NAMESPACE]"
> wrapperElementName="[WRAP_NAME]">
>           <brs:fact elementName="[ELEMENT_NAME]" namespace="[NAMESPACE]"
> type="[FACT_TYPE]"/>
>         </brs:input>
>         <brs:output namespace="[NAMESPACE]"
> wrapperElementName="[WRAP_NAME]">
>           <brs:fact elementName="[ELEMENT_NAME]" namespace="[NAMESPACE]"
> type="[FACT_TYPE]"/>
>         </brs:output>
>     </brs:operation>
>
> To deviate operation which require stateful knowledge sessions from
> stateless, we can add new attribute, lets say "*operationType*" whith
> possible values "*stateful*" and "*stateless*" so final operation config
> will look like as follows:
>
>     <brs:operation name="[OPERATION_NAME]"
> operationType="[OPERATION_TYPE]">
>         <brs:input namespace="[NAMESPACE]"
> wrapperElementName="[WRAP_NAME]">
>           <brs:fact elementName="[ELEMENT_NAME]" namespace="[NAMESPACE]"
> type="[FACT_TYPE]"/>
>         </brs:input>
>         <brs:output namespace="[NAMESPACE]"
> wrapperElementName="[WRAP_NAME]">
>           <brs:fact elementName="[ELEMENT_NAME]" namespace="[NAMESPACE]"
> type="[FACT_TYPE]"/>
>         </brs:output>
>     </brs:operation>
>
> When request received to particular operation's messageReceiver, we can
> create appropriate statful or stateless knowledge session for it.
>
> WDYT, any ideas?
>
> [1] mail: [BRS] BRS 2.2.0 - snapshot goes OOM in clustered setup during
> load test
> [2]
> https://docs.jboss.org/jbpm/v5.1/javadocs/org/drools/runtime/StatefulKnowledgeSession.html
> [3]
> https://docs.jboss.org/jbpm/v5.1/javadocs/org/drools/runtime/StatelessKnowledgeSession.html
> [4]
> https://docs.jboss.org/jbpm/v5.1/javadocs/org/drools/KnowledgeBase.html
>
> Thanks,
> Milinda
> --
> Milinda Perera
> Software Engineer;
> WSO2 Inc. http://wso2.com ,
> Mobile: (+94) 714 115 032
>
>


-- 
Nandika Jayawardana
WSO2 Inc ; http://wso2.com
lean.enterprise.middleware
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to