[JBoss JIRA] (DROOLS-745) Unnecessary and thread-blocking "synchronized" in MVELSafeHelper.java
by Andrey Bichkevskiy (JIRA)
Andrey Bichkevskiy created DROOLS-745:
-----------------------------------------
Summary: Unnecessary and thread-blocking "synchronized" in MVELSafeHelper.java
Key: DROOLS-745
URL: https://issues.jboss.org/browse/DROOLS-745
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.2.0.Final
Reporter: Andrey Bichkevskiy
Assignee: Mario Fusco
Class org.drools.core.util.MVELSafeHelper, obsolete and thread-blocking "synchronized" keyword in static getter of a static final field:
public class MVELSafeHelper {
private static final MVELEvaluator evaluator;
static {
evaluator = KiePolicyHelper.isPolicyEnabled() ? new SafeMVELEvaluator() : new RawMVELEvaluator();
}
public static synchronized MVELEvaluator getEvaluator() {
return evaluator;
}
//
}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-744) Rule Generation Feature Request
by Justin Holmes (JIRA)
[ https://issues.jboss.org/browse/DROOLS-744?page=com.atlassian.jira.plugin... ]
Justin Holmes updated DROOLS-744:
---------------------------------
Description:
As a developer using Drools, I want a rule generation java api that supports control logic in the rule templates (e.g. for loops, if/else) and integrates with the rule workbench in order to build highly dynamic business rules driven systems.
The initial thought process around implementation is to build two things 1) a simple way to author mvel templates in business central, the existing text editor could be used at first and 2) a simple embedded java api in it's own maven module which can checkout the git project that has the mvel template, apply a set of domain objects to the template, check in the resulting rule files to the local git repo and then push the changes back to business central. This allows us to leverage the power of the existing MVEL and JGit tech stack while pushing the complexity to a java api, where we are stronger than the workbench itself.
was:As a developer using Drools, I want a rule generation java api that supports control logic in the rule templates (e.g. for loops, if/else) and integrates with the rule workbench in order to build highly dynamic business rules driven systems.
> Rule Generation Feature Request
> -------------------------------
>
> Key: DROOLS-744
> URL: https://issues.jboss.org/browse/DROOLS-744
> Project: Drools
> Issue Type: Feature Request
> Components: core engine, kie server
> Affects Versions: 6.2.0.Final
> Reporter: Justin Holmes
> Assignee: Mario Fusco
> Fix For: 6.3.0.Final
>
>
> As a developer using Drools, I want a rule generation java api that supports control logic in the rule templates (e.g. for loops, if/else) and integrates with the rule workbench in order to build highly dynamic business rules driven systems.
> The initial thought process around implementation is to build two things 1) a simple way to author mvel templates in business central, the existing text editor could be used at first and 2) a simple embedded java api in it's own maven module which can checkout the git project that has the mvel template, apply a set of domain objects to the template, check in the resulting rule files to the local git repo and then push the changes back to business central. This allows us to leverage the power of the existing MVEL and JGit tech stack while pushing the complexity to a java api, where we are stronger than the workbench itself.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-744) Rule Generation Feature Request
by Justin Holmes (JIRA)
Justin Holmes created DROOLS-744:
------------------------------------
Summary: Rule Generation Feature Request
Key: DROOLS-744
URL: https://issues.jboss.org/browse/DROOLS-744
Project: Drools
Issue Type: Feature Request
Components: core engine, kie server
Affects Versions: 6.2.0.Final
Reporter: Justin Holmes
Assignee: Mario Fusco
Fix For: 6.3.0.Final
As a developer using Drools, I want a rule generation java api that supports control logic in the rule templates (e.g. for loops, if/else) and integrates with the rule workbench in order to build highly dynamic business rules driven systems.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4427) Step status of the failed step by <fail> element becomes COMPLETED.
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-4427?page=com.atlassian.jira.plugin.... ]
Cheng Fang commented on WFLY-4427:
----------------------------------
Batch spec discussion thread:
https://java.net/projects/jbatch/lists/public/archive/2015-03/message/23
> Step status of the failed step by <fail> element becomes COMPLETED.
> -------------------------------------------------------------------
>
> Key: WFLY-4427
> URL: https://issues.jboss.org/browse/WFLY-4427
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 8.2.0.Final
> Reporter: Takashi Nishigaya
> Assignee: Cheng Fang
> Attachments: batch-restart-failed.zip
>
>
> Assuming the following job definition, if STEP1 returns "1" as the exit status, the job status becomes FAILED. But the step status is COMPLETED.
> {noformat}
> job status: FAILED
> step: STEP1, step status: COMPLETED
> {noformat}
> {noformat}
> <job id="batch-job1" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/jobXML_1_0.xsd ">
> <step id="STEP1">
> <batchlet ref="TestBatchlet1" />
> <next on="0" to="STEP2" />
> <fail on="1" exit-status="FAILED_BY_EXIT_STATUS" />
> </step>
> <step id="STEP2">
> <batchlet ref="TestBatchlet2" />
> </step>
> </job>
> {noformat}
> In this case, we can not restart the failed job from the failed step STEP1.
> This behavior is correct based on the description of 10.8 Restart Processing, 3. a. in JSR 352.
> But it is not expected result.
> {quote}
> 10.8 Restart Processing
> 3. Starting at the restart position, each execution element is re-examined to determine if it should re-execute:
> a. If the execution element is a COMPLETED step that specifies allow-restart-if- complete=false, then follow the transition to the next
> execution element based on the exit status for this step from the previous execution.
> {quote}
> On the other hand, If the STEP1 is failed by throwing an exception, both of the resulting job status and the step status are FAILED.
> {noformat}
> job status: FAILED
> step: STEP1, step status: FAILED
> {noformat}
> In this case, restarting the failed job is correctly executed, because the step status is FAILED.
> I think the step status of the failed step should be FAILED in both cases. But the section "8.6.2 Fail Element" of JSR352 says nothing about what step status value must be exposed after failed.
> This behavior is the same in GlassFish 4 and WildFly 8.2.
> So, I want to know what is the correct specification or intended behavior.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-3291) Pass Jandex CompositeIndex into Hibernate 5.x
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3291?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-3291:
------------------------------------
[http://lists.jboss.org/pipermail/wildfly-dev/2015-March/003688.html] mentions that jandex indexes are not available on a partial restart (read earlier in the email thread for more details).
> Pass Jandex CompositeIndex into Hibernate 5.x
> ----------------------------------------------
>
> Key: WFLY-3291
> URL: https://issues.jboss.org/browse/WFLY-3291
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 9.0.0.Beta1
>
>
> 1. When creating the persistence unit for Hibernate 5.x, pass a Jandex composite index via:
> integrationMap.put( "hibernate.jandex_index", CompositeIndex.create( pu.getAnnotationIndex().values() ).
> 2. Also change from:
> integerationMap.put( "hibernate.ejb.resource_scanner", HibernateArchiveScanner.class )
> To:
> integrationMap.put( "hibernate.jpa.scanner_archive_delegate", VirtualFileSystemArchiveDescriptorFactory.INSTANCE )
> This may turn out to be a Jipajapa only change.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-1192) jboss-deployment-structure.xml top level exclusion does not work
by Gerry Matte (JIRA)
[ https://issues.jboss.org/browse/WFLY-1192?page=com.atlassian.jira.plugin.... ]
Gerry Matte commented on WFLY-1192:
-----------------------------------
I also reported this problem at https://issues.jboss.org/browse/WFLY-4439 while attempting to make logback work with Wildfly 8.2.0.Final
I considered it to be a Minor problem because I was able to implement a workaround solution - but I would much prefer using jboss-deployment-structure.xml with exclude-subsystems
> jboss-deployment-structure.xml top level exclusion does not work
> ----------------------------------------------------------------
>
> Key: WFLY-1192
> URL: https://issues.jboss.org/browse/WFLY-1192
> Project: WildFly
> Issue Type: Feature Request
> Components: Class Loading
> Environment: Windows, RedHat Linux
> Reporter: Markus Lindblom
> Fix For: Awaiting Volunteers
>
>
> When I try to exclude for example Log4J in the deployment structure I have to exclude it from every subdeployment in the deployment structure file, the top level exclusion should exclude it from the entire EAR and all of its subdeployments.
> Ed: The feature request is, to add a convenient way to cause exclusions to cascade to subdeployments. Right now it works per design.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4439) jboss-deployment-structure.xml does not exclude-subsystem named logging
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4439?page=com.atlassian.jira.plugin.... ]
James Perkins reassigned WFLY-4439:
-----------------------------------
Assignee: James Perkins (was: Jason Greene)
> jboss-deployment-structure.xml does not exclude-subsystem named logging
> -----------------------------------------------------------------------
>
> Key: WFLY-4439
> URL: https://issues.jboss.org/browse/WFLY-4439
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Environment: Microsoft Windows 7, Oracle JDK 7, Eclipse Luna
> Reporter: Gerry Matte
> Assignee: James Perkins
> Priority: Minor
>
> While attempting to use logback logging in a web application, I tried to use a jboss-deployment-structure.xml in my WEB-INF/classes folder to exclude the logging subsystem so that I could use logback configured in my webapp.
> That method failed to prevent the logging subsystem from being excluded from my deployment.
> However, when I added the tag add-logging-api-dependencies value="false" to the logging subsystem, logback began to work.
> I'm not sure if this solution would cause problems with other webapps - I would have preferred to use jboss-deployment-structure.xml instead so as to make the smallest change to my wildfly configuration.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4439) jboss-deployment-structure.xml does not exclude-subsystem named logging
by Gerry Matte (JIRA)
[ https://issues.jboss.org/browse/WFLY-4439?page=com.atlassian.jira.plugin.... ]
Gerry Matte updated WFLY-4439:
------------------------------
Description:
While attempting to use logback logging in a web application, I tried to use a jboss-deployment-structure.xml in my WEB-INF/classes folder to exclude the logging subsystem so that I could use logback configured in my webapp.
That method failed to prevent the logging subsystem from being excluded from my deployment.
However, when I added the tag add-logging-api-dependencies value="false" to the logging subsystem, logback began to work.
I'm not sure if this solution would cause problems with other webapps - I would have preferred to use jboss-deployment-structure.xml instead so as to make the smallest change to my wildfly configuration.
was:
While attempting to use logback logging in a web application, I tried to use a jboss-deployment-structure.xml in my WEB-INF/classes folder to exclude the logging subsystem so that I could use logback configured in my webapp.
That method failed to prevent the logging subsystem from being excluded from my deployment.
However, when I added the tag add-logging-api-dependencies value="false" to then logging subsystem, logback began to work.
I'm not sure if this solution would cause problems with other webapps - I would have preferred to use jboss-deployment-structure.xml instead so as to make the smallest change to my wildfly configuration.
> jboss-deployment-structure.xml does not exclude-subsystem named logging
> -----------------------------------------------------------------------
>
> Key: WFLY-4439
> URL: https://issues.jboss.org/browse/WFLY-4439
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Environment: Microsoft Windows 7, Oracle JDK 7, Eclipse Luna
> Reporter: Gerry Matte
> Assignee: Jason Greene
> Priority: Minor
>
> While attempting to use logback logging in a web application, I tried to use a jboss-deployment-structure.xml in my WEB-INF/classes folder to exclude the logging subsystem so that I could use logback configured in my webapp.
> That method failed to prevent the logging subsystem from being excluded from my deployment.
> However, when I added the tag add-logging-api-dependencies value="false" to the logging subsystem, logback began to work.
> I'm not sure if this solution would cause problems with other webapps - I would have preferred to use jboss-deployment-structure.xml instead so as to make the smallest change to my wildfly configuration.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4439) jboss-deployment-structure.xml does not exclude-subsystem named logging
by Gerry Matte (JIRA)
Gerry Matte created WFLY-4439:
---------------------------------
Summary: jboss-deployment-structure.xml does not exclude-subsystem named logging
Key: WFLY-4439
URL: https://issues.jboss.org/browse/WFLY-4439
Project: WildFly
Issue Type: Bug
Affects Versions: 8.2.0.Final
Environment: Microsoft Windows 7, Oracle JDK 7, Eclipse Luna
Reporter: Gerry Matte
Assignee: Jason Greene
Priority: Minor
While attempting to use logback logging in a web application, I tried to use a jboss-deployment-structure.xml in my WEB-INF/classes folder to exclude the logging subsystem so that I could use logback configured in my webapp.
That method failed to prevent the logging subsystem from being excluded from my deployment.
However, when I added the tag add-logging-api-dependencies value="false" to then logging subsystem, logback began to work.
I'm not sure if this solution would cause problems with other webapps - I would have preferred to use jboss-deployment-structure.xml instead so as to make the smallest change to my wildfly configuration.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1675:
--------------------------------
You could also try running the above probe.sh script which dumps the thread pool sizes every N seconds, to see if there's a trend (e.g. toward exhausting a particular pool)
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java, UPerf2.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months