[JBoss JIRA] (DROOLS-1660) Temporal operator fails after serialization
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1660?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1660:
--------------------------------
Sprint: 2017 Week 28-29
> Temporal operator fails after serialization
> -------------------------------------------
>
> Key: DROOLS-1660
> URL: https://issues.jboss.org/browse/DROOLS-1660
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final, 7.0.0.Final
> Reporter: Christopher Brecht
> Assignee: Mario Fusco
> Fix For: 7.2.0.Final
>
> Attachments: EventA.java, Reproducer.java
>
>
> I attached a reproducer of the problem. If I am executing the rules without serialization everything is working correctly.
> If I am executing it with serialization the rules are firing to often. I expect the rule to fire only once. It should fire once at 03:06:00 but it fires 3 times, once at 3:04:00 and 2 times at 3:06:00.
> It have to be a problem with serialization of the temporal operators like after,before, etc.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (DROOLS-1663) Kie DMN doesn't support
by Stylianos Koussouris (JIRA)
Stylianos Koussouris created DROOLS-1663:
--------------------------------------------
Summary: Kie DMN doesn't support
Key: DROOLS-1663
URL: https://issues.jboss.org/browse/DROOLS-1663
Project: Drools
Issue Type: Bug
Components: dmn engine
Reporter: Stylianos Koussouris
Assignee: Edson Tirelli
Page 40.
import: Import [*] This attribute is used to import externally defined elements and
make them available for use by elements in this Definitions.
Section 6.3.3 Import metamodel
The aim here is to be able to import one Decision defined in a separate DMN into another where it is used as a supporting decision and is referenced (RequiredDecision)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-112:
------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1454564|https://bugzilla.redhat.com/show_bug.cgi?id=1454564] from MODIFIED to ON_QA
> Long server shut-dow with unresponsive client with opened JNDI Context
> ----------------------------------------------------------------------
>
> Key: WFCORE-112
> URL: https://issues.jboss.org/browse/WFCORE-112
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Miroslav Novak
> Assignee: David Lloyd
> Labels: remoting
> Attachments: JNDIContext.java, testcase.zip
>
>
> Description of problem:
> If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes.
> This scenario takes place, when network connections is lost between JMS clients with JNDI context and server.
> Version-Release number of selected component (if applicable):
> jboss-remoting-3.3.3.Final-redhat-1.jar
> How reproducible:
> always
> Steps to Reproduce:
> 1. Start EAP 6.3.1.CP.CR1 on first machine
> 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java)
> 3. Disconnect network between client and server
> 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c)
> Actual results:
> It takes 15 minutes for server to shutdown.
> Expected results:
> Server should shutdown almost immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8929) Race condition if timers overlap due to long running execution and short schedules if database persistence is used
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-8929?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-8929:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1461416|https://bugzilla.redhat.com/show_bug.cgi?id=1461416] from MODIFIED to ON_QA
> Race condition if timers overlap due to long running execution and short schedules if database persistence is used
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8929
> URL: https://issues.jboss.org/browse/WFLY-8929
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: Configure DB persistence for timers as file-persistence will not have a persistence check for shouldRun to lock the timer execution.
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Fix For: 11.0.0.Beta1
>
> Attachments: server-extract.log, server1.log
>
>
> If timers (here calendar timer) are running longer than scheduled, or the schedule/processing get stuck do to thread or cpu bottleneck, it is possible that the updates for persistence overlap.
> The issue seems that the task(1) try to finish the timer and task(2) is about to start but see the concurrency.
> The DB is updated with the 'old' next timeout, but the internal Timer instance will be updated with the next possible schedule due to a race condition between the two threads updating the object.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-9083) rewrite handler handles references to contextual values incorrect
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-9083:
------------------------------------
Summary: rewrite handler handles references to contextual values incorrect
Key: WFLY-9083
URL: https://issues.jboss.org/browse/WFLY-9083
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.1.0.Final
Environment: * Windows 10
* Wildfly 10.1.0 Final
* Undertow Subsystem 1.4.13
Reporter: Markus Stier
Assignee: Stuart Douglas
Context:
A URL in the form of "http://somehost.org/path/a/b" should be rewritten to "http://somehost.org/newpath?param1=a¶m2=b"
The following filter should perform this rewrite:
{code}
<expression-filter name="rewrite-path" expression="regex('^/path/([^/]+)/(.*)/?$') -> rewrite('/newpath'); set(attribute='%{QUERY_STRING}', value='param1=$1&param2=$2'); done()"/>
{code}
Problem:
The output is (according to access-log);
{code}
somehost.org "GET /newpath?param1=b
{code}
* param1 is assigned to the value of $2
* param2 is dropped completly
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (LOGTOOL-114) Add annotation to help reporting add links to resolution topics
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-114?page=com.atlassian.jira.plugi... ]
James Perkins reassigned LOGTOOL-114:
-------------------------------------
Assignee: James Perkins
> Add annotation to help reporting add links to resolution topics
> ---------------------------------------------------------------
>
> Key: LOGTOOL-114
> URL: https://issues.jboss.org/browse/LOGTOOL-114
> Project: Log Tool
> Issue Type: Enhancement
> Reporter: James Perkins
> Assignee: James Perkins
>
> It may be useful to add links to generated reports.
> For example in the below adoc report the {{CODE0001}} could be changed to a link which points to a resolution document.
> ||Message Id||Message||Log Level||Return Type||
> |CODE0001| Failed to start container: %s|—|java.lang.String|
> Resolution documents could be documents in the projects or full URL's. The annotation can be placed on the top level interface meaning every method will be generated or placed on a method.
> {code:title=Examples}
> @BaseURL("http://foo.com/codes#") // for anchors
> @BaseURL("http://foo.com/codes/") // for pages
> {code}
> {code}
> @ResolutionDoc(path = "CODE0001.adoc")
> @ResolutionDoc(url = "http://foo.com/code", suffix = ".adoc")
> @ResolutionDoc(suffix = ".adoc")
> {code}
> For {{suffix}} the generated id would be used. In the examples above the file name would be {{CODE0001.adoc}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (JASSIST-268) Gettig Java.lang.VerifyError with Latest Javassist, Powermock 1.7 and Java 1.8
by Rajesh Eagambaram (JIRA)
Rajesh Eagambaram created JASSIST-268:
-----------------------------------------
Summary: Gettig Java.lang.VerifyError with Latest Javassist, Powermock 1.7 and Java 1.8
Key: JASSIST-268
URL: https://issues.jboss.org/browse/JASSIST-268
Project: Javassist
Issue Type: Bug
Affects Versions: 3.20.0-GA
Environment: All
Reporter: Rajesh Eagambaram
Assignee: Shigeru Chiba
Hi Team,
We have our current JUnit development completed using Java 1.6 using Powermock1.7 and Javaassist 3.20.0-GA and it is working fine. When we upgrade the JDK to 1.8 we are getting the error "Java.lang.VerifyError: Expecting a stackmap frame at branch target 64".
Please help to fix the issue
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months