[JBoss JIRA] (JBMESSAGING-1955) Deadlock on failover with client lease
by Doug Grove (JIRA)
Doug Grove created JBMESSAGING-1955:
---------------------------------------
Summary: Deadlock on failover with client lease
Key: JBMESSAGING-1955
URL: https://issues.jboss.org/browse/JBMESSAGING-1955
Project: JBoss Messaging
Issue Type: Feature Request
Components: Messaging Core Distributed Support
Affects Versions: 1.4.8.SP5
Environment: JBoss EAP 5.1.2
Reporter: Doug Grove
JBoss is configured as an 8 node cluster. This cluster is for JMS messaging only. Other JBoss instances host MDBs. When failover occurs in the 8 node cluster, a deadlock is seen on the JBoss instances that host the MDBs.
{quote}
Found one Java-level deadlock:
=============================
"Thread-177":
waiting to lock monitor 0x4c561e18 (object 0x7c3dfdb0, a java.lang.Object),
which is held by "Thread-130"
"Thread-130":
waiting to lock monitor 0x08aea1a4 (object 0x81dde148, a java.lang.Object),
which is held by "Timer-18"
"Timer-18":
waiting to lock monitor 0x4c561e18 (object 0x7c3dfdb0, a java.lang.Object),
which is held by "Thread-130"
Java stack information for the threads listed above:
===================================================
"Thread-177":
at org.jboss.remoting.Client.removeConnectionListener(Client.java:599)
- waiting to lock <0x7c3dfdb0> (a java.lang.Object)
at org.jboss.jms.client.remoting.JMSRemotingConnection.removeConnectionListener(JMSRemotingConnection.java:565)
- locked <0x7f589740> (a org.jboss.jms.client.remoting.JMSRemotingConnection)
at org.jboss.jms.client.container.ConnectionAspect.handleClose(ConnectionAspect.java:183)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientConnectionDelegate.close(ClientConnectionDelegate.java)
at org.jboss.jms.client.JBossConnection.close(JBossConnection.java:132)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardownConnection(JmsActivation.java:635)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardown(JmsActivation.java:376)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.handleFailure(JmsActivation.java:275)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.onException(JmsActivation.java:312)
at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:120)
- locked <0x7f320410> (a java.lang.Object)
- locked <0x7f5899a0> (a org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener)
at org.jboss.remoting.ConnectionValidator$3.run(ConnectionValidator.java:524)
"Thread-130":
at org.jboss.remoting.MicroRemoteClientInvoker.establishLease(MicroRemoteClientInvoker.java:507)
- waiting to lock <0x81dde148> (a java.lang.Object)
at org.jboss.remoting.Client.setupClientLease(Client.java:2056)
- locked <0x7c3dfdb0> (a java.lang.Object)
at org.jboss.remoting.Client.connect(Client.java:1918)
at org.jboss.remoting.Client.connect(Client.java:737)
at org.jboss.jms.client.remoting.JMSRemotingConnection$1.run(JMSRemotingConnection.java:374)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.jms.client.remoting.JMSRemotingConnection.start(JMSRemotingConnection.java:368)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:175)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeTarget(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:80)
at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateConnectionDelegate_25018031.invoke(StateCreationAspect_z_handleCreateConnectionDelegate_25018031.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
at org.jboss.jms.client.container.ClusteringAspect.handleCreateConnectionDelegate(ClusteringAspect.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.createConnectionDelegate(ClientClusteredConnectionFactoryDelegate.java)
at org.jboss.jms.client.FailoverCommandCenter.failureDetected(FailoverCommandCenter.java:129)
at org.jboss.jms.client.container.ConnectionFailureListener.handleConnectionException(ConnectionFailureListener.java:62)
at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:84)
- locked <0x813598d0> (a org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener)
at org.jboss.remoting.ConnectionValidator$3.run(ConnectionValidator.java:524)
"Timer-18":
at org.jboss.remoting.Client.notifyListeners(Client.java:1873)
- waiting to lock <0x7c3dfdb0> (a java.lang.Object)
at org.jboss.remoting.LeasePinger.stopPing(LeasePinger.java:134)
at org.jboss.remoting.MicroRemoteClientInvoker.terminateLease(MicroRemoteClientInvoker.java:434)
- locked <0x81dde148> (a java.lang.Object)
at org.jboss.remoting.ConnectionValidator$WaitOnConnectionCheckTimerTask.run(ConnectionValidator.java:1081)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Found 1 deadlock.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-599) kjar archertype
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-599:
-------------------------------------
Summary: kjar archertype
Key: DROOLS-599
URL: https://issues.jboss.org/browse/DROOLS-599
Project: Drools
Issue Type: Feature Request
Affects Versions: 6.1.0.Final
Reporter: Matteo Mortari
Assignee: Mark Proctor
I'm opening this JIRA as I will later open PR related to https://groups.google.com/d/msg/drools-development/uO17-kC4mvc/aBRunEcZ_b4J
The version of the archetype defaults for non-CEP, non-Eclipse plugin in pom. There are property which user can change default value to have CEP, and Eclipse plug-in.
For reference,
* Set-up the new project's pom:
** Change Java version to 1.6 or greater, by including the maven-compiler-plugin
** Add Drools dependencies
** Change JUnit dependencies to version 4
** Add kie-maven-plugin
** [option] Add plug-in org.eclipse.m2e/lifecycle-mapping settings, to avoid Eclipse ERROR at the pom.xml line defining the kie-maven-plugin
** Set packaging to 'kjar'
* ( ALT + F5 in betweens )
* Creation of an initial .drl file in src/main/resources
* Creation of minimal kmodule.xml in src/main/resources/META-INF directory
* Create a simple JUnit test for:
** Creation of KieBase [option ->] with STREAM option for CEP features
** Creation of KieSession [option ->] with pseudo-clock
** [option: Advance] / Insert / Fire template
** ... and other verification/output patterns
* Include SLF4J and LOG4J binding for logging, including a log4j.properties file in src/test/resources
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-598) accumuate function not working when object chaining is used as accumulate condition
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-598?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-598:
---------------------------------------
In your example, there is only one TestD with count -999. The constraint count != -999 in your rule filters it out, so there is no way for this rule to match, nor to return 0.
If I remove the condition count != -999, the rule fires and return -999.
If I set D's count to 0 upon construction, the rule fires and returns 0.
Please reopen the ticket if you have a better reproducer for your original issue, but as far as your reproducer goes, the engine works as expected.
Best
Davide
> accumuate function not working when object chaining is used as accumulate condition
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-598
> URL: https://issues.jboss.org/browse/DROOLS-598
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.Beta2, 6.2.0.CR1, 6.2.0.Final
> Reporter: John Le
> Assignee: Mark Proctor
> Attachments: SumOfAllIssue.java
>
>
> Please see attached code file to reproduce issue. Rule is supposed to fire and yield 0.0 as the sum but rule does not. If we remove TestA, TestB, TestC and leave only TestD as condition then rule fire.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-507) Cannot issue fireUntilHalt when using persisted session
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-507?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-507:
---------------------------------------
The FireUntilHalt command is marked as unpersistable (for obvious reasons - it is usually executed in a dedicated thread), which
causes the exception even before the command is attempted.
Could you elaborate more on your use cases? In particular, what would you expect to happen if a running session was persisted
and then restored?
> Cannot issue fireUntilHalt when using persisted session
> -------------------------------------------------------
>
> Key: DROOLS-507
> URL: https://issues.jboss.org/browse/DROOLS-507
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 6.1.0.Beta3
> Environment: Mac OSX Maverick, Spring 4.0.1
> Reporter: Roger Lefebvre
> Assignee: Mark Proctor
>
> Generating the following exception when using runUntilHalt() with persistence.
> Exception in thread "SimpleAsyncTaskExecutor-1" java.lang.UnsupportedOperationException: Command session.fireUntilHalt(); cannot be issued on a persisted session at org.drools.persistence.SingleSessionCommandService$TransactionInterceptor.execute(SingleSessionCommandService.java:474) at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:353) at org.drools.core.command.impl.CommandBasedStatefulKnowledgeSession.fireUntilHalt(CommandBasedStatefulKnowledgeSession.java:272) at com.s.c.m.CallHandler$RunEngine.run(CallHandler.java:115) at java.lang.Thread.run(Thread.java:722)
> Persistence and KieSession defined in Spring as follows:
> <!-- provides KnowledgeStoreService implementation -->
> <kie:kstore id="kstore"/>
> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
> <property name="driverClassName" value="com.mysql.jdbc.Driver" />
> <property name="url" value="jdbc:mysql://localhost:3306/ruleEngine" />
> <property name="username" value="xxxxxx" /> <property name="password" value="yyyyyyyy" />
> </bean>
> <bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
> <property name="dataSource" ref="dataSource"/>
> <property name="persistenceUnitName" value="org.drools.persistence.jpa.local"/>
> </bean>
> <bean id="txManager" class="org.springframework.orm.jpa.JpaTransactionManager">
> <property name="entityManagerFactory" ref="emf"/>
> </bean>
> <kie:kmodule id="callManagerModule">
> <kie:kbase name="commandKBase" packages="rules.command" eventProcessingMode="stream">
> <kie:ksession name="commandEngine" type="stateful"></kie:ksession>
> </kie:kbase>
> <kie:kbase name="campaignKBase" packages="rules.campaign.*" eventProcessingMode="stream" equalsBehavior="equality">
> <kie:ksession name="campaignEngine" type="stateful" >
> <kie:consoleLogger/>
> <kie:configuration>
> <kie:jpa-persistence>
> <kie:transaction-manager ref="txManager"/>
> <kie:entity-manager-factory ref="emf"/>
> </kie:jpa-persistence>
> </kie:configuration>
> </kie:ksession>
> </kie:kbase>
> </kie:kmodule>
> <bean id="taskExecutor" class="org.springframework.core.task.SimpleAsyncTaskExecutor">
> <property name="daemon" value="true"/>
> </bean>
> <bean id="campaignHandler" class="com.s.c.m.CallHandler" init-method="init">
> <constructor-arg type="org.springframework.core.task.TaskExecutor" ref="taskExecutor"/>
> </bean>
> I invoke fireUntilHalt method as follows:
>
> private TaskExecutor taskExecutor;
> public CampaignCallHandler(TaskExecutor taskExecutor) {
> this.taskExecutor = taskExecutor; }
> public void init() { taskExecutor.execute(new RunEngine()); }
> class RunEngine implements Runnable {
> @Override public void run() { campaignEngine.fireUntilHalt(); } }
> NOTE: This occurs on a new system where nothing has been persisted to the database. In other words, there isn't a session available to be loaded. I have yet to have success reloading a session - that is a separate issue that I believe DROOLS-422 partially identifies.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-422) Timer based rules don't fire and facts can't expire after session restore
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-422?page=com.atlassian.jira.plugin... ]
Davide Sottara edited comment on DROOLS-422 at 9/13/14 9:59 PM:
----------------------------------------------------------------
Gentlemen, it seems that there are multiple discussions with multiple problems here, which makes it very hard to determine whether a problem has been solved.
@Roger, please create a separate ticket, in case they can be relinked later.
@Nedo, @Dushman, would you be able to submit a test case that reproduces the error? There are examples in the module drools-persistence-jpa that you could probably adapt.
Thank you all!
Davide
was (Author: dsotty):
Gentlemen, it seems that there are multiple discussions with multiple problems here, which makes it very hard to determine whether a problem has been solved.
@Roger, please create a separate ticket, in case they can be relinked later.
@Nedo, @Dushma, would you be able to submit a test case that reproduces the error? There are examples in the module drools-persistence-jpa that you could probably adapt.
Thank you all!
Davide
> Timer based rules don't fire and facts can't expire after session restore
> -------------------------------------------------------------------------
>
> Key: DROOLS-422
> URL: https://issues.jboss.org/browse/DROOLS-422
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Environment: Linux Mint 15
> JBoss AS 5.1
> Reporter: Nedo Nedic
> Assignee: Mark Proctor
> Attachments: drools-mongodb-persistence.zip
>
>
> I have implemented a custom persistence engine for Drools sessions in MongoDB. When session is built for first time, everything works like a charm. I am having some problems when Drools sessions are restored from MongoDB collection. Firstly, interval based rules (for example timer(int: 10s 10s)) don't fire. Some facts that should expire, they just don't expire and remain forever in WM. I attached the source code. When session is built for first time, I use code like this:
> KnowledgeBase kbase = createKBase(getKnowledgeBuilder(rulePackagePath),
> config);
> if (hasKnowledgeAgent) {
>
> createKnowledgeAgent(kbase, correlatorId);
>
> wm = (ReteooStatefulSession) ((KnowledgeBaseImpl) kagent
> .getKnowledgeBase()).ruleBase.newStatefulSession(
> (SessionConfiguration) ksconf, env);
> ksession = new StatefulKnowledgeSessionImpl(wm, kagent
> .getKnowledgeBase());
>
> stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller(this, ksession, ksconf);
> stateOutputMarshaller.init();
> ((InternalKnowledgeRuntime) ksession).setEndOperationListener(this);
> }
> Then, after every action I update the session in MongoDB collection.
> public void endOperation(InternalKnowledgeRuntime ikr) {
>
> stateOutputMarshaller.marshall();
> }
> For session restoring, after AS restart I use this code:
> KnowledgeBase kbase = createKBase( getKnowledgeBuilder(rulePackagePath), getKBaseConfig() );
> stateInputMarshaller = StateMarshallerFactory.newInputMarshaller( this, kbase, getSessionConf() );
> ksession = stateInputMarshaller.unmarshall(correlatorId);
> stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller( this, ksession, getSessionConf() );
>
> ((InternalKnowledgeRuntime)ksession).setEndOperationListener(this);
>
> protected static KnowledgeBaseConfiguration getKBaseConfig() {
> KnowledgeBaseConfiguration config = KnowledgeBaseFactory
> .newKnowledgeBaseConfiguration();
> config.setOption(EventProcessingOption.STREAM);
> return config;
> }
> protected static KnowledgeSessionConfiguration getSessionConf() {
> KnowledgeSessionConfiguration ksconf = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
> ksconf.setOption(ClockTypeOption.get("realtime"));
> return ksconf;
> }
> Any help is appreciated.
> Thanks
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-422) Timer based rules don't fire and facts can't expire after session restore
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-422?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-422:
---------------------------------------
Gentlemen, it seems that there are multiple discussions with multiple problems here, which makes it very hard to determine whether a problem has been solved.
@Roger, please create a separate ticket, in case they can be relinked later.
@Nedo, @Dushma, would you be able to submit a test case that reproduces the error? There are examples in the module drools-persistence-jpa that you could probably adapt.
Thank you all!
Davide
> Timer based rules don't fire and facts can't expire after session restore
> -------------------------------------------------------------------------
>
> Key: DROOLS-422
> URL: https://issues.jboss.org/browse/DROOLS-422
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Environment: Linux Mint 15
> JBoss AS 5.1
> Reporter: Nedo Nedic
> Assignee: Mark Proctor
> Attachments: drools-mongodb-persistence.zip
>
>
> I have implemented a custom persistence engine for Drools sessions in MongoDB. When session is built for first time, everything works like a charm. I am having some problems when Drools sessions are restored from MongoDB collection. Firstly, interval based rules (for example timer(int: 10s 10s)) don't fire. Some facts that should expire, they just don't expire and remain forever in WM. I attached the source code. When session is built for first time, I use code like this:
> KnowledgeBase kbase = createKBase(getKnowledgeBuilder(rulePackagePath),
> config);
> if (hasKnowledgeAgent) {
>
> createKnowledgeAgent(kbase, correlatorId);
>
> wm = (ReteooStatefulSession) ((KnowledgeBaseImpl) kagent
> .getKnowledgeBase()).ruleBase.newStatefulSession(
> (SessionConfiguration) ksconf, env);
> ksession = new StatefulKnowledgeSessionImpl(wm, kagent
> .getKnowledgeBase());
>
> stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller(this, ksession, ksconf);
> stateOutputMarshaller.init();
> ((InternalKnowledgeRuntime) ksession).setEndOperationListener(this);
> }
> Then, after every action I update the session in MongoDB collection.
> public void endOperation(InternalKnowledgeRuntime ikr) {
>
> stateOutputMarshaller.marshall();
> }
> For session restoring, after AS restart I use this code:
> KnowledgeBase kbase = createKBase( getKnowledgeBuilder(rulePackagePath), getKBaseConfig() );
> stateInputMarshaller = StateMarshallerFactory.newInputMarshaller( this, kbase, getSessionConf() );
> ksession = stateInputMarshaller.unmarshall(correlatorId);
> stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller( this, ksession, getSessionConf() );
>
> ((InternalKnowledgeRuntime)ksession).setEndOperationListener(this);
>
> protected static KnowledgeBaseConfiguration getKBaseConfig() {
> KnowledgeBaseConfiguration config = KnowledgeBaseFactory
> .newKnowledgeBaseConfiguration();
> config.setOption(EventProcessingOption.STREAM);
> return config;
> }
> protected static KnowledgeSessionConfiguration getSessionConf() {
> KnowledgeSessionConfiguration ksconf = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
> ksconf.setOption(ClockTypeOption.get("realtime"));
> return ksconf;
> }
> Any help is appreciated.
> Thanks
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-597) Custom implementations of dynamic salience don't work
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-597?page=com.atlassian.jira.plugin... ]
Davide Sottara edited comment on DROOLS-597 at 9/13/14 9:46 PM:
----------------------------------------------------------------
Fixed, I'm preparing a PR. It will be officially available next week
Thanks for reporting
Davide
[Edit: details]
Dynamic salience works using expressions e.g. {code}salience $p.age{code},
but custom implementations of dynamic salience were not supported. This
ticket fixes the issue allowing the users to set their own implementations of
dynamic salience
was (Author: dsotty):
Fixed, I'm preparing a PR. It will be officially available next week
Thanks for reporting
Davide
> Custom implementations of dynamic salience don't work
> -----------------------------------------------------
>
> Key: DROOLS-597
> URL: https://issues.jboss.org/browse/DROOLS-597
> Project: Drools
> Issue Type: Bug
> Environment: Eclipse/Windows 7 - 64 bits
> Reporter: Yacine Jaber
> Assignee: Mark Proctor
> Attachments: SalienceProject.7z, WodSalienceImpl.java
>
>
> I have implemented my own bean (Salience) that manage the dynamic salience for the rules.
> After building the drl file i overlaod the salience of the rules with my dynamic salience WodSalienceImpl(Attached file).
> However, the salience is not respected even if this bean was called (getValue) before the match creation.
> N.B: I used MVELSalience by writing the dynamic salience into the rules(MEVL expression). The result was the same.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years