[JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour for EJBs if JTS is enabled
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink updated WFLY-3801:
-----------------------------------
Attachment: reproducer.zip
mvn project for reproduce
> Wrong Transaction behaviour for EJBs if JTS is enabled
> ------------------------------------------------------
>
> Key: WFLY-3801
> URL: https://issues.jboss.org/browse/WFLY-3801
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Transactions
> Affects Versions: 8.1.0.Final
> Environment: standalone-full profile with JTS enabled
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Attachments: enableJTS.cli, reproducer.zip, server.log
>
>
> If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
> WARN [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
> This is only the case if other resources are involved, i.e. a DB via JPA.
> If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
> It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour for EJBs if JTS is enabled
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink updated WFLY-3801:
-----------------------------------
Attachment: enableJTS.cli
> Wrong Transaction behaviour for EJBs if JTS is enabled
> ------------------------------------------------------
>
> Key: WFLY-3801
> URL: https://issues.jboss.org/browse/WFLY-3801
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Transactions
> Affects Versions: 8.1.0.Final
> Environment: standalone-full profile with JTS enabled
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Attachments: enableJTS.cli, server.log
>
>
> If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
> WARN [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
> This is only the case if other resources are involved, i.e. a DB via JPA.
> If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
> It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour for EJBs if JTS is enabled
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink updated WFLY-3801:
-----------------------------------
Attachment: server.log
> Wrong Transaction behaviour for EJBs if JTS is enabled
> ------------------------------------------------------
>
> Key: WFLY-3801
> URL: https://issues.jboss.org/browse/WFLY-3801
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Transactions
> Affects Versions: 8.1.0.Final
> Environment: standalone-full profile with JTS enabled
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Attachments: server.log
>
>
> If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
> WARN [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
> This is only the case if other resources are involved, i.e. a DB via JPA.
> If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
> It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour for EJBs if JTS is enabled
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-3801:
--------------------------------------
Summary: Wrong Transaction behaviour for EJBs if JTS is enabled
Key: WFLY-3801
URL: https://issues.jboss.org/browse/WFLY-3801
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB, Transactions
Affects Versions: 8.1.0.Final
Environment: standalone-full profile with JTS enabled
Reporter: Wolf-Dieter Fink
Assignee: David Lloyd
If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
WARN [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
This is only the case if other resources are involved, i.e. a DB via JPA.
If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (DROOLS-586) Drools doesn't calculate maximum expiration time properly
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-586?page=com.atlassian.jira.plugin... ]
Davide Sottara updated DROOLS-586:
----------------------------------
Fix Version/s: (was: 6.1.0.Final)
Priority: Critical (was: Major)
Assignee: Edson Tirelli (was: Mark Proctor)
Affects Version/s: 6.2.0.Beta1
6.1.0.CR2
> Drools doesn't calculate maximum expiration time properly
> ---------------------------------------------------------
>
> Key: DROOLS-586
> URL: https://issues.jboss.org/browse/DROOLS-586
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.CR2, 6.2.0.Beta1
> Environment: Linux, Java SE 1.7
> Reporter: kairat kushaev
> Assignee: Edson Tirelli
> Priority: Critical
>
> Hello guys,
> we found some contradiction between actual Drools behavior,
> We use the following Rule:
> import drools.test.Event;
> dialect "mvel"
> declare Event
> @role(event)
> @expires(10s)
> end
> rule "ExampleRule"
> when
> ( $a : Event(name == "event a") ) and
> ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
> then
> System.out.println("bingo!");
> end
> In the code above Drools should wait for the second event when the first event came. But it turns out that Drools doesn't wait for the second event because of @expires tag. The value in this tag is less than this after value.
> According to documentation
> "The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two."
> but it is not calculating maximal expiration offset. Also we are using STREAM mode.
> Could you please clarify the situation?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (DROOLS-586) Drools doesn't calculate maximum expiration time properly
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-586?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-586:
---------------------------------------
It's confirmed, we are investigating
> Drools doesn't calculate maximum expiration time properly
> ---------------------------------------------------------
>
> Key: DROOLS-586
> URL: https://issues.jboss.org/browse/DROOLS-586
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Linux, Java SE 1.7
> Reporter: kairat kushaev
> Assignee: Mark Proctor
> Fix For: 6.1.0.Final
>
>
> Hello guys,
> we found some contradiction between actual Drools behavior,
> We use the following Rule:
> import drools.test.Event;
> dialect "mvel"
> declare Event
> @role(event)
> @expires(10s)
> end
> rule "ExampleRule"
> when
> ( $a : Event(name == "event a") ) and
> ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
> then
> System.out.println("bingo!");
> end
> In the code above Drools should wait for the second event when the first event came. But it turns out that Drools doesn't wait for the second event because of @expires tag. The value in this tag is less than this after value.
> According to documentation
> "The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two."
> but it is not calculating maximal expiration offset. Also we are using STREAM mode.
> Could you please clarify the situation?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3335) JAXB transformer initiation
by Fabien KOCIK (JIRA)
[ https://issues.jboss.org/browse/WFLY-3335?page=com.atlassian.jira.plugin.... ]
Fabien KOCIK commented on WFLY-3335:
------------------------------------
Hello,
Encountering the same issues applying some XSL templates on provided XML files in EJB bean startup context.
My EAR works fine in JBoss AS 7.
Regards.
> JAXB transformer initiation
> ---------------------------
>
> Key: WFLY-3335
> URL: https://issues.jboss.org/browse/WFLY-3335
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Class Loading
> Affects Versions: 8.0.0.Final, 8.1.0.CR1
> Environment: Ubuntu 14.04 with java 7 openjdk
> Reporter: Ghet Ghetolay
> Assignee: David Lloyd
> Priority: Blocker
>
> I'm not directly using JAXB and SaxTransformer, it's part of a the [dcm4chee-arc project|https://github.com/dcm4che/dcm4chee-arc] which I tried to use on Wildfly. It's a rather big and complicated project so I've create a test application to illustrate the bug. I've used a JAR-RS application to illustrate the bug (like the original case) but this should not be related to it.
> {code:title=TestRS.java}
> @Path("test")
> public class TestRS {
>
> private static SAXTransformerFactory factory =
> (SAXTransformerFactory) TransformerFactory.newInstance();
>
> @GET
> public Response test(){
> try {
> Templates template = factory.newTemplates(new StreamSource(
> TestRS.class.getResource("json_compact.xsl").toString()));
>
> factory.newTransformerHandler(template);
>
> } catch (TransformerConfigurationException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> return Response.ok().build();
> }
> }
> {code}
> {code:title=json_compact.xsl}
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
> <xsl:output method="text"/>
> <xsl:template match="/">
> <xsl:text>Test</xsl:text>
> </xsl:template>
> </xsl:stylesheet>
> {code}
> {quote}
> 15:24:48,564 ERROR [stderr] (default task-1) javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 15:24:48,564 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:369)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:383)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:418)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformerHandler(TransformerFactoryImpl.java:1062)
> 15:24:48,565 ERROR [stderr] (default task-1) at __redirected.__TransformerFactory.newTransformerHandler(__TransformerFactory.java:193)
> 15:24:48,566 ERROR [stderr] (default task-1) at test.TestRS.test(TestRS.java:25)
> {quote}
> I've discovered that the initial exception is :
> {quote}
> java.lang.NoClassDefFoundError: com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet
> {quote}
> Both my test case and dcm4che-arc project works fine on JBoss 7.1.1.Final.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (DROOLS-483) Repeated class loading of absent services
by Frank Pavageau (JIRA)
[ https://issues.jboss.org/browse/DROOLS-483?page=com.atlassian.jira.plugin... ]
Frank Pavageau commented on DROOLS-483:
---------------------------------------
Hi there.
It's been more than 3 months and neither this issue nor the pull request has seen any kind of response, so I was wondering if something important is missing (other than time of the Drools team side).
Should I continue rebasing the modification on master from time to time?
> Repeated class loading of absent services
> -----------------------------------------
>
> Key: DROOLS-483
> URL: https://issues.jboss.org/browse/DROOLS-483
> Project: Drools
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.1.Final, 6.1.0.Final
> Reporter: Frank Pavageau
> Assignee: Mark Proctor
>
> h3. Context
> The {{ServiceRegistry}} is used to get the providers for a number of services, several of which don't have an implementation in a Drools artifact but in jBPM, for example.
> Those providers include:
> - {{ProcessBuilderFactoryService}} (implemented by {{org.jbpm.process.builder.ProcessBuilderFactoryServiceImpl}}) called in the constructor of {{KnowledgeBuilderImpl}} through {{ProcessBuilderFactory}}
> - {{ProcessRuntimeFactoryService}} (implemented by {{org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl}}) called in the constructor of {{StatefulKnowledgeSessionImpl}} through {{ProcessRuntimeFactory}}, so this one especially can be called frequently
> Both {{ProcessBuilderFactory}} and {{ProcessRuntimeFactory}} use the fact that the static field containing the service is not null to know they've been initialized, which means they'll continuously try to load the class if it's not actually in the classpath.
> h3. Enhancement
> If this behavior is not needed for the OSGi support, I'd like to see the initialization test use a boolean field to only try loading the class once. And if it is needed for OSGi, maybe the behavior could be configured.
> h3. Rationale
> Attempting to load a class is a costly operation, especially in the context of a web application running on Tomcat. I've pushed a [JMH|http://openjdk.java.net/projects/code-tools/jmh/] benchmark on [Github|https://github.com/fpavageau/bench-for-name] to illustrate the point (see the [README.md|https://github.com/fpavageau/bench-for-name#results]): a failed call to Class.forName() takes ~22 microseconds using the context classloader of the benchmark (i.e. probably the system classloader), ~75 microseconds using a Tomcat classloader configured ({{WebappClassLoader}}) with 100 empty jars (that need to be scanned for the missing class). Combined with the fact that {{Class.forName()}} calls {{ClassLoader.loadClass()}} which in the case of {{WebappClassLoader}} is a synchronized method, it becomes a nice bottleneck in a high-traffic application creating {{StatefulKnowledgeSessions}} extensively, because of the lock contention.
> Another side-effect of this flow is that {{ServiceRegistryImpl}} continuously gets a {{ClassNotFoundException}}, then throws an {{IllegalArgumentException}}, which means 2 stacktraces to fill for each call, and that is also an [expensive operation|http://shipilev.net/blog/2014/exceptional-performance/] when throwing exceptions is not exceptional and becomes the regular control flow.
> I've been able to grab stacktraces from Drools to {{WebappClassLoader.loadClass()}} when doing thread dumps on an application with sufficient load, so it's frequent enough that it can be observed by sampling and not just a rhetorical question.
> I could create a pull request, but I'd like to get some feedback first.
> Note: most calls to {{ServiceRegistry.get()}} use the same pattern, but the 2 I have picked out are the ones which happen the most frequently for my use case.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (DROOLS-586) Drools doesn't calculate maximum expiration time properly
by kairat kushaev (JIRA)
[ https://issues.jboss.org/browse/DROOLS-586?page=com.atlassian.jira.plugin... ]
kairat kushaev commented on DROOLS-586:
---------------------------------------
Guys, do you have any updates?
> Drools doesn't calculate maximum expiration time properly
> ---------------------------------------------------------
>
> Key: DROOLS-586
> URL: https://issues.jboss.org/browse/DROOLS-586
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Linux, Java SE 1.7
> Reporter: kairat kushaev
> Assignee: Mark Proctor
> Fix For: 6.1.0.Final
>
>
> Hello guys,
> we found some contradiction between actual Drools behavior,
> We use the following Rule:
> import drools.test.Event;
> dialect "mvel"
> declare Event
> @role(event)
> @expires(10s)
> end
> rule "ExampleRule"
> when
> ( $a : Event(name == "event a") ) and
> ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
> then
> System.out.println("bingo!");
> end
> In the code above Drools should wait for the second event when the first event came. But it turns out that Drools doesn't wait for the second event because of @expires tag. The value in this tag is less than this after value.
> According to documentation
> "The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two."
> but it is not calculating maximal expiration offset. Also we are using STREAM mode.
> Could you please clarify the situation?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months