[JBoss JIRA] (JBRULES-1751) Issue in Drools 4.0.7 when run in Multithreaded environment
by Vlastimil Eliáš (JIRA)
[ https://issues.jboss.org/browse/JBRULES-1751?page=com.atlassian.jira.plug... ]
Vlastimil Eliáš closed JBRULES-1751.
------------------------------------
Resolution: Done
> Issue in Drools 4.0.7 when run in Multithreaded environment
> -----------------------------------------------------------
>
> Key: JBRULES-1751
> URL: https://issues.jboss.org/browse/JBRULES-1751
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.0.7
> Environment: OS AIX 1.5
> Reporter: Sitaraman Balaraman
> Assignee: Edson Tirelli
> Fix For: 5.0.1.FINAL
>
>
> Hi
> We have a batch program(Informatica mapping) which uses Jars taken from an application which uses JBoss Drools 4.0.7 and MVEL 1.3.7. The informatica Integration service runs in AIX Machine with JRE Version 1.5. The batch program process millions of records which in turn calls the Drools API. To improve the performance, we tried running our informatica process in a multi threaded environment(4 threads). While running we got the following exception for every record that we process(across all the threads).
> : Exception executing predicate eval( $terDate.before(ExtDateTimeUtils.getDate("01/01/1900")) )
> at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:216)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:162)
> at org.drools.reteoo.Rete.assertObject(Rete.java:175)
> at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:192)
> at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:71)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:911)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:883)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:684)
> at org.drools.reteoo.ReteooStatelessSession.execute(ReteooStatelessSession.java:160)
> ...
> Caused by: org.mvel.CompileException: cannot invoke method
> at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:54)
> at org.mvel.optimizers.impl.refl.VariableAccessor.getValue(VariableAccessor.java:39)
> at org.mvel.ast.VariableDeepPropertyNode.getReducedValueAccelerated(VariableDeepPropertyNode.java:22)
> at org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:21)
> at org.mvel.MVELRuntime.execute(MVELRuntime.java:90)
> at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111)
> at org.mvel.MVEL.executeExpression(MVEL.java:235)
> at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:45)
> at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:209)
> ... 20 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:46)
> ... 28 more
> Caused by: java.lang.NullPointerException
> at java.util.Date.getMillisOf(Date.java:953)
> at java.util.Date.before(Date.java:912)
> ... 32 more
> ].
> Could you please let me know if this is a known issue or is there any workaround for this problem?
> Thanks
> Sitaraman
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JGRP-1863) Excessive dropped messages due to missing physical address
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1863?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1863 at 7/25/14 3:15 AM:
---------------------------------------------------------
The error message "no physical address for SiteMaster(SFO)" means that a message with a target address of {{SiteMaster}} managed to reach the transport. This should not be possible as {{SiteMaster}} target addresses should be caught and handled by {{RELAY2}} at the top of the stack. There are 2 scenarios where this can happen:
# There was no {{RELAY2}} in the stack (can you confirm this?)
# An {{AddressGenerator}} was used that turned the target address into something else ({{ExtendedUUID}}?) and therefore {{RELAY2}} didn't catch it.
I'll take a closer look at your test case...
was (Author: belaban):
The error message "no physical address for SiteMaster(SFO)' means that a message with a target address of {{SiteMaster}} managed to reach the transport. This should not be possible as {{SiteMaster}} target addresses should be caught and handled by {{RELAY2}} at the top of the stack. There are 2 scenarios where this can happen:
# There was no {{RELAY2}} in the stack (can you confirm this?)
# An {{AddressGenerator}} was used that turned the target address into something else ({{ExtendedUUID}}?) and therefore {{RELAY2}} didn't catch it.
I'll take a closer look at your test case...
> Excessive dropped messages due to missing physical address
> ----------------------------------------------------------
>
> Key: JGRP-1863
> URL: https://issues.jboss.org/browse/JGRP-1863
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.5
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 3.5
>
>
> When running the x-site replication tests (and only those tests - the others run fine) from the clustering testsuite in WildFly against JGroups 3.5, I encounter failures due to:
> {noformat}
> 12:15:48,537 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site SFO: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from SFO (sync, timeout=10000)
> {noformat}
> The logs preceding this indicate the cause of the timeout:
> {noformat}
> 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message
> 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message
> 12:15:39,506 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message
> 12:15:39,507 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message
> {noformat}
> These messages repeat about 100 or so times over a period of 10 seconds.
> A little investigation reveals that the process for fetching physical addresses for a given logical destination address has changed. In 3.4, a given call to sendToSingleMember(...) would attempt to lookup the physical address by sending a Event.GET_PHYSICAL_ADDRESS up the stack and wait a predetermined period for a response. Any concurrent calls to sendToSingleMember(...) would also wait, but only one thread in a given time period would ever send the Event.GET_PHYSICAL_ADDRESS event up the stack.
> In 3.5 the process is different. In org.jgroups.protocols.TP, the FIND_MBRS event is used to lookup the phsyical addresses, instead of directly sending up a GET_PHYSICAL_ADDRESS event. However, looking at the implementation of the FIND_MBRS event handling within org.jgroups.protocols.Discovery, I see that this triggers a asynchronous GET_MBRS_REQ message. Since this message is sent asynchronously, this means that the response from the original FIND_MBRS event will most certainly be empty. Thus the thread that initiated the FIND_MBRS will most certainly log the PhysicalAddrMissing warning, as will any concurrent/subsequent calls to sendToSingleMember(...) for the same destination until that asynchronous processing completes. This is a departure from the logic in 3.4, where the thread initiating the physical address lookup would wait for some time for the address cache to be updated. I should think that the PhysicalAddrMissing warnings should stop once the original GET_MBRS_REQ message is handled, but that doesn't seem to be happening (hence the 100 or so sequential warning messages over a period of 10 seconds preceding the timeout log message from infinispan).
> Curiously, I see a org.jgroups.protocols.TP.setPingData(...) method, which seems to be responsible for populating the physical address cache from the FIND_MBRS event results from org.jgroups.protocols.Discovery - however, this method doesn't seem to be referenced anywhere. Might that be the source of the problem?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JGRP-1863) Excessive dropped messages due to missing physical address
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1863?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1863:
--------------------------------
The error message "no physical address for SiteMaster(SFO)' means that a message with a target address of {{SiteMaster}} managed to reach the transport. This should not be possible as {{SiteMaster}} target addresses should be caught and handled by {{RELAY2}} at the top of the stack. There are 2 scenarios where this can happen:
# There was no {{RELAY2}} in the stack (can you confirm this?)
# An {{AddressGenerator}} was used that turned the target address into something else ({{ExtendedUUID}}?) and therefore {{RELAY2}} didn't catch it.
I'll take a closer look at your test case...
> Excessive dropped messages due to missing physical address
> ----------------------------------------------------------
>
> Key: JGRP-1863
> URL: https://issues.jboss.org/browse/JGRP-1863
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.5
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 3.5
>
>
> When running the x-site replication tests (and only those tests - the others run fine) from the clustering testsuite in WildFly against JGroups 3.5, I encounter failures due to:
> {noformat}
> 12:15:48,537 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site SFO: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from SFO (sync, timeout=10000)
> {noformat}
> The logs preceding this indicate the cause of the timeout:
> {noformat}
> 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message
> 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message
> 12:15:39,506 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message
> 12:15:39,507 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message
> {noformat}
> These messages repeat about 100 or so times over a period of 10 seconds.
> A little investigation reveals that the process for fetching physical addresses for a given logical destination address has changed. In 3.4, a given call to sendToSingleMember(...) would attempt to lookup the physical address by sending a Event.GET_PHYSICAL_ADDRESS up the stack and wait a predetermined period for a response. Any concurrent calls to sendToSingleMember(...) would also wait, but only one thread in a given time period would ever send the Event.GET_PHYSICAL_ADDRESS event up the stack.
> In 3.5 the process is different. In org.jgroups.protocols.TP, the FIND_MBRS event is used to lookup the phsyical addresses, instead of directly sending up a GET_PHYSICAL_ADDRESS event. However, looking at the implementation of the FIND_MBRS event handling within org.jgroups.protocols.Discovery, I see that this triggers a asynchronous GET_MBRS_REQ message. Since this message is sent asynchronously, this means that the response from the original FIND_MBRS event will most certainly be empty. Thus the thread that initiated the FIND_MBRS will most certainly log the PhysicalAddrMissing warning, as will any concurrent/subsequent calls to sendToSingleMember(...) for the same destination until that asynchronous processing completes. This is a departure from the logic in 3.4, where the thread initiating the physical address lookup would wait for some time for the address cache to be updated. I should think that the PhysicalAddrMissing warnings should stop once the original GET_MBRS_REQ message is handled, but that doesn't seem to be happening (hence the 100 or so sequential warning messages over a period of 10 seconds preceding the timeout log message from infinispan).
> Curiously, I see a org.jgroups.protocols.TP.setPingData(...) method, which seems to be responsible for populating the physical address cache from the FIND_MBRS event results from org.jgroups.protocols.Discovery - however, this method doesn't seem to be referenced anywhere. Might that be the source of the problem?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3664) Exceptions during download of webstart libraries
by Markus Schwarz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3664?page=com.atlassian.jira.plugin.... ]
Markus Schwarz updated WFLY-3664:
---------------------------------
Attachment: server.log
demo-src.zip
Attached
* The full server log file containing all the exceptions
* Demo project which creates a WAR for the webstart application
> Exceptions during download of webstart libraries
> ------------------------------------------------
>
> Key: WFLY-3664
> URL: https://issues.jboss.org/browse/WFLY-3664
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.2.0.CR1
> Environment: Windows 7 (64bit), Windows Server 2012 R2 (64bit)
> Reporter: Markus Schwarz
> Assignee: Stuart Douglas
> Priority: Minor
> Attachments: demo-src.zip, server.log
>
>
> I have a webstart application using the JnlpDownloadServlet. If the client cache is empty, launching the JNLP will download the libraries. The webstart application works as expected, but in the server logs there are many errors regarding download of the libraries.
> Just to mention: Not always the same libraries are listed with erros in the logs files. Sometimes I even got now exceptions.
> For my tests I used Wildfly 8.1.0.FINAL as well as a nightly build from 24. of July without any further changes of the configuration files (https://ci.jboss.org/hudson/job/WildFly-latest-master/).
> I tested it under Windows 7 and Windows Server 2012 R2. The demo contains an older JnlpDownloadServlet, but I tested it also with the one coming with JDK 7u65.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3664) Exceptions during download of webstart libraries
by Markus Schwarz (JIRA)
Markus Schwarz created WFLY-3664:
------------------------------------
Summary: Exceptions during download of webstart libraries
Key: WFLY-3664
URL: https://issues.jboss.org/browse/WFLY-3664
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.2.0.CR1
Environment: Windows 7 (64bit), Windows Server 2012 R2 (64bit)
Reporter: Markus Schwarz
Assignee: Stuart Douglas
Priority: Minor
I have a webstart application using the JnlpDownloadServlet. If the client cache is empty, launching the JNLP will download the libraries. The webstart application works as expected, but in the server logs there are many errors regarding download of the libraries.
Just to mention: Not always the same libraries are listed with erros in the logs files. Sometimes I even got now exceptions.
For my tests I used Wildfly 8.1.0.FINAL as well as a nightly build from 24. of July without any further changes of the configuration files (https://ci.jboss.org/hudson/job/WildFly-latest-master/).
I tested it under Windows 7 and Windows Server 2012 R2. The demo contains an older JnlpDownloadServlet, but I tested it also with the one coming with JDK 7u65.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3640) EJB injection does not work in components added via Servlet Context
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3640?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-3640:
---------------------------------
Fix Version/s: Awaiting Volunteers
Assignee: (was: Stuart Douglas)
This could be implemented by hacking up some injection support in org.jboss.as.ee.component.ReflectiveClassIntrospector, however given that this only affects components added manually when CDI has been disabled this is not a priority at the moment, and is unlikely to be fixed in the WF9 time frame.
> EJB injection does not work in components added via Servlet Context
> -------------------------------------------------------------------
>
> Key: WFLY-3640
> URL: https://issues.jboss.org/browse/WFLY-3640
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: James Livingston
> Fix For: Awaiting Volunteers
>
> Attachments: reproducer.zip
>
>
> You can add web components at runtime ServletContext.addListener() and similar methods. @EJB injection inside those components does not work and the field remains null. I have not yet tested whether other forms of injection work or not.
> I'm attaching a reproducer which adds a listener via a ServletContainerInitializer. Deploying the WAR and going to the root of the web app context (/scilistener-0.0.1-SNAPSHOT) will cause a NullPointerException
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JBWEB-301) When custom error pages are used in web.xml wrong status codes are returned
by Troy Longo (JIRA)
[ https://issues.jboss.org/browse/JBWEB-301?page=com.atlassian.jira.plugin.... ]
Troy Longo updated JBWEB-301:
-----------------------------
Environment:
JBoss EAP 6.1.0
Red Hat Linux 6.1
CamelServlet 2.13.0
> When custom error pages are used in web.xml wrong status codes are returned
> ---------------------------------------------------------------------------
>
> Key: JBWEB-301
> URL: https://issues.jboss.org/browse/JBWEB-301
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.2.1.GA
> Environment: JBoss EAP 6.1.0
> Red Hat Linux 6.1
> CamelServlet 2.13.0
> Reporter: Troy Longo
> Assignee: Remy Maucherat
>
> I have the following code in my ServletFilter
> if(request instanceof HttpServletRequest)
> {
> isHttpRequest = true;
>
> if(!(((HttpServletRequest)request).getMethod().equals("POST")))
> {
> ((HttpServletResponse)response).sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED);
> return;
> }
> }
> When I send a GET request, everything works fine and I am receive a response with a 405 status code. However when I send a PUT or DELETE, I receive a 403 and 501 status code respectively. I have debugged through my code and verified that I am hitting the same line above in my code. What I noticed is that this code was working nicely until I added some custom error pages into my web.xml. My web xml error page definitions are as follows. Removing these custom error pages from the web.xml cause the code to work as expected.
> <!--<error-page>
> <error-code>500</error-code>
> <location>/WEB-INF/500Error.html</location>
> </error-page>
> <error-page>
> <error-code>404</error-code>
> <location>/WEB-INF/404Error.html</location>
> </error-page>
> <error-page>
> <error-code>413</error-code>
> <location>/WEB-INF/413Error.html</location>
> </error-page>
> <error-page>
> <error-code>405</error-code>
> <location>/WEB-INF/405Error.html</location>
> </error-page>-->
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JBWEB-301) When custom error pages are used in web.xml wrong status codes are returned
by Troy Longo (JIRA)
Troy Longo created JBWEB-301:
--------------------------------
Summary: When custom error pages are used in web.xml wrong status codes are returned
Key: JBWEB-301
URL: https://issues.jboss.org/browse/JBWEB-301
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossWeb-7.2.1.GA
Reporter: Troy Longo
Assignee: Remy Maucherat
I have the following code in my ServletFilter
if(request instanceof HttpServletRequest)
{
isHttpRequest = true;
if(!(((HttpServletRequest)request).getMethod().equals("POST")))
{
((HttpServletResponse)response).sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED);
return;
}
}
When I send a GET request, everything works fine and I am receive a response with a 405 status code. However when I send a PUT or DELETE, I receive a 403 and 501 status code respectively. I have debugged through my code and verified that I am hitting the same line above in my code. What I noticed is that this code was working nicely until I added some custom error pages into my web.xml. My web xml error page definitions are as follows. Removing these custom error pages from the web.xml cause the code to work as expected.
<!--<error-page>
<error-code>500</error-code>
<location>/WEB-INF/500Error.html</location>
</error-page>
<error-page>
<error-code>404</error-code>
<location>/WEB-INF/404Error.html</location>
</error-page>
<error-page>
<error-code>413</error-code>
<location>/WEB-INF/413Error.html</location>
</error-page>
<error-page>
<error-code>405</error-code>
<location>/WEB-INF/405Error.html</location>
</error-page>-->
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3663) WildFly should manage JGroups and Infinispan thread pools by default
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3663?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3663:
-----------------------------------
On releated topic, you should stop refering to executor in threads subsystem but rather embed executor configuration from threads subsystem in ispn / jgrups subsystems.
> WildFly should manage JGroups and Infinispan thread pools by default
> --------------------------------------------------------------------
>
> Key: WFLY-3663
> URL: https://issues.jboss.org/browse/WFLY-3663
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Beta1
>
>
> In our default configuration, both JGroups and Infinispan manage their own thread pools. Unfortunately, both projects do not handle thread pool lifecycle so well. Both projects use ExecutorService.shutdownNow() to end their thread pool lifecycles. This means that a channel or cache can stop, but still leave active threads running (albeit interrupted). We should have services that manage the lifecycle of our thread pools which ensure that all threads have terminated during Service.stop().
> This causes occasional OOMs in the Windows CI testsuite runs, due to too many threads lying around.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called to early
by Andreas Liebscher (JIRA)
[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ]
Andreas Liebscher edited comment on WFLY-3619 at 7/24/14 5:48 PM:
------------------------------------------------------------------
<xa-datasource jndi-name="java:/jdbc/***2" pool-name="***2" enabled="true" spy="true">
<xa-datasource-property name="URL">
jdbc:sqlserver://127.0.0.1:1433;DatabaseName=***
</xa-datasource-property>
<xa-datasource-property name="DatabaseName">
***
</xa-datasource-property>
<xa-datasource-property name="PortNumber">
1433
</xa-datasource-property>
<xa-datasource-property name="ApplicationName">
***
</xa-datasource-property>
<xa-datasource-property name="LoginTimeout">
60
</xa-datasource-property>
<xa-datasource-property name="LockTimeout">
60000
</xa-datasource-property>
<xa-datasource-property name="SelectMethod">
cursor
</xa-datasource-property>
<xa-datasource-property name="ResponseBuffering">
full
</xa-datasource-property>
<xa-datasource-property name="User">
product-mip-dev-ali
</xa-datasource-property>
<xa-datasource-property name="Password">
xxx
</xa-datasource-property>
<xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
<driver>sqljdbc4xa</driver>
<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
<xa-pool>
<min-pool-size>5</min-pool-size>
<max-pool-size>30</max-pool-size>
<use-strict-min>false</use-strict-min>
<interleaving>false</interleaving>
<pad-xid>false</pad-xid>
<wrap-xa-resource>false</wrap-xa-resource>
</xa-pool>
<security>
<user-name>***</user-name>
<password>***</password>
</security>
<validation>
<validate-on-match>false</validate-on-match>
<background-validation>false</background-validation>
</validation>
<timeout>
<xa-resource-timeout>3600</xa-resource-timeout>
</timeout>
<statement>
<share-prepared-statements>false</share-prepared-statements>
</statement>
</xa-datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
<driver name="sqljdbc4xa" module="com.microsoft.sqlserver">
<xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
</driver>
</drivers>
was (Author: aliebscher):
<xa-datasource jndi-name="java:/jdbc/centerware2" pool-name="centerware2" enabled="true" spy="true">
<xa-datasource-property name="URL">
jdbc:sqlserver://127.0.0.1:1433;DatabaseName=ProductDevALiMIP
</xa-datasource-property>
<xa-datasource-property name="DatabaseName">
ProductDevALiMIP
</xa-datasource-property>
<xa-datasource-property name="PortNumber">
1433
</xa-datasource-property>
<xa-datasource-property name="ApplicationName">
mobileX MIP - Centerware2 XA
</xa-datasource-property>
<xa-datasource-property name="LoginTimeout">
60
</xa-datasource-property>
<xa-datasource-property name="LockTimeout">
60000
</xa-datasource-property>
<xa-datasource-property name="SelectMethod">
cursor
</xa-datasource-property>
<xa-datasource-property name="ResponseBuffering">
full
</xa-datasource-property>
<xa-datasource-property name="User">
product-mip-dev-ali
</xa-datasource-property>
<xa-datasource-property name="Password">
xxx
</xa-datasource-property>
<xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
<driver>sqljdbc4xa</driver>
<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
<xa-pool>
<min-pool-size>5</min-pool-size>
<max-pool-size>30</max-pool-size>
<use-strict-min>false</use-strict-min>
<interleaving>false</interleaving>
<pad-xid>false</pad-xid>
<wrap-xa-resource>false</wrap-xa-resource>
</xa-pool>
<security>
<user-name>product-mip-dev-ali</user-name>
<password>mobilex</password>
</security>
<validation>
<validate-on-match>false</validate-on-match>
<background-validation>false</background-validation>
</validation>
<timeout>
<xa-resource-timeout>3600</xa-resource-timeout>
</timeout>
<statement>
<share-prepared-statements>false</share-prepared-statements>
</statement>
</xa-datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
<driver name="sqljdbc4xa" module="com.microsoft.sqlserver">
<xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
</driver>
</drivers>
> XA END / un-enlist for database connection called to early
> ----------------------------------------------------------
>
> Key: WFLY-3619
> URL: https://issues.jboss.org/browse/WFLY-3619
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, JCA, JPA / Hibernate, Transactions
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 64-bit
> JDK 1.8.0_05-b13 64-Bit
> MS SQL Server 2012 database
> Latest MS JDBC driver
> XA datasource
> Reporter: Andreas Liebscher
> Assignee: Scott Marlow
> Priority: Blocker
> Attachments: server.jca.log, server_MSSQL_Trace.log
>
>
> While trying to port an EE application from JBoss5 to WF8 the following problem occurred:
> EJBs (@Required) using JPA to do some data changes.
> Some changes get already written to the database, others reside in the session cache.
> After the top EJB call returns, a Hibernate Session flush is triggered in beforeCompletion.
> Then more changes are flushed to the database, but I run in a reproduceable database locking problem.
> After some time an update of a row fails with lock wait timeout. This row has been inserted prior during the EJB call.
> There should be exactly one xa transaction active processing all data changes.
> But the database shows two active session, one is an xa transaction with sessionId -2 (orphaned), the other session is a local transaction.
> After analyzing all database communication with the help of the JDBC driver logging I found the following behaviour:
> - a connection is enlisted and xa start called
> - the same connection is used for several select / insert / update statements
> - after return of the top EJB call on the same connection xa end and connection un-enlist is called
> - the same connection is used for session flush (beforeCompletion) but with local transaction because the connection is no longer associated with the xa transaction, so locks can be expected.
> Shouldn't xa end be called AFTER beforeCompletion / session flush!?!
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months