[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 commented on WFLY-3619:
-----------------------------------------
<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
[JBoss JIRA] (WFLY-3661) PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName arg
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3661?page=com.atlassian.jira.plugin.... ]
Kabir Khan edited comment on WFLY-3661 at 7/24/14 12:29 PM:
------------------------------------------------------------
I'm travelling with intermittent WiFi access, so I only really read the introduction. So apologies if I am about to miss something. Basically the PluggableMBeanServer has a set of delegates. One of these is the real underlying MBeanServer, the others are various read-only facades for things like the jmx representation of our management APIs, JSR77 etc. None of these facades allow registering anything.
So, I think it would be safe in this case to do something like
{code}
@Override
public ObjectInstance registerMBean(Object object, ObjectName name) throws InstanceAlreadyExistsException,
MBeanRegistrationException, NotCompliantMBeanException {
--SNIP--
//Your explanation here :-)
delegate = name == null ? rootMBeanServer : findDelegateForNewObject(name);
--SNIP--
}
{code}
I am on PTO for the next week or so, but if you feel like opening a pull request, please go ahead.
was (Author: kabirkhan):
I'm travelling with intermittent WiFi access, so I only really read the introduction. So apologies if I am about to miss something. Basically the PluggableMBeanServer has a set of delegates. One of these is the real underlying MBeanServer, the others are various read-only facades for things like the jmx representation of our management APIs, JSR77 etc. None of these facades allow registering anything.
So, I think it would be safe in this case to do something like
{code}
@Override
public ObjectInstance registerMBean(Object object, ObjectName name) throws InstanceAlreadyExistsException,
MBeanRegistrationException, NotCompliantMBeanException {
--SNIP--
//Your explanation here :-)
delegate = name == null ? rootMBeanServer : findDelegateForNewObject(name);
--SNIP--
}
{code}
> PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName arg
> -------------------------------------------------------------------------------
>
> Key: WFLY-3661
> URL: https://issues.jboss.org/browse/WFLY-3661
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX
> Affects Versions: 8.0.0.Final
> Reporter: Jess Holle
> Assignee: Kabir Khan
>
> According to the Javadoc on MBeanRegistration.preRegister(), one may register an MBean with a null ObjectName and let the MBean's preRegister() method compute the ObjectName.
> Unfortunately, org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegateForNewObject() violates this contract -- throwing an exception when the incoming ObjectName is null.
> This is a clear bug which breaks numerous JMX MBeans I've authored, which compute their own ObjectNames within preRegister().
> Ideally the result of preRegister would be used as an input to findDelegateForNewObject(), but unfortunately one of the inputs to preRegister() is the MBeanServer, which is, of course, what findDelegateForNewObject() is looking up. Given this circularity, it would seem that findDelegateForNewObject() should simply return rootMBeanServer for null ObjectName inputs. In any case it should not entirely fail to register such MBeans.
> Fortunately, I have a utility wrapper around MBean registration, so I've added the following hack immediately prior to actually registering the MBean to workaround this issue:
> /* Hack to work around JBoss Wildfly bug (https://issues.jboss.org/browse/WFLY-3661).
> This isn't really quite correct, of course, since this means preRegister() will get called twice,
> but it appears to be about the best we can do.
> */
> if ( objectName == null )
> if ( mbean instanceof MBeanRegistration )
> if ( "org.jboss.as.jmx.PluggableMBeanServerImpl".equals( mbeanserver.getClass().getName() ) )
> objectName = ((MBeanRegistration)mbean).preRegister( mbeanserver, objectName );
> where mbeanserver is obtained via ManagementFactory.getPlatformMBeanServer().
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3661) PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName arg
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3661?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-3661:
----------------------------------
I'm travelling with intermittent WiFi access, so I only really read the introduction. So apologies if I am about to miss something. Basically the PluggableMBeanServer has a set of delegates. One of these is the real underlying MBeanServer, the others are various read-only facades for things like the jmx representation of our management APIs, JSR77 etc. None of these facades allow registering anything.
So, I think it would be safe in this case to do something like
{code}
@Override
public ObjectInstance registerMBean(Object object, ObjectName name) throws InstanceAlreadyExistsException,
MBeanRegistrationException, NotCompliantMBeanException {
--SNIP--
//Your explanation here :-)
delegate = name == null ? rootMBeanServer : findDelegateForNewObject(name);
--SNIP--
}
{code}
> PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName arg
> -------------------------------------------------------------------------------
>
> Key: WFLY-3661
> URL: https://issues.jboss.org/browse/WFLY-3661
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX
> Affects Versions: 8.0.0.Final
> Reporter: Jess Holle
> Assignee: Kabir Khan
>
> According to the Javadoc on MBeanRegistration.preRegister(), one may register an MBean with a null ObjectName and let the MBean's preRegister() method compute the ObjectName.
> Unfortunately, org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegateForNewObject() violates this contract -- throwing an exception when the incoming ObjectName is null.
> This is a clear bug which breaks numerous JMX MBeans I've authored, which compute their own ObjectNames within preRegister().
> Ideally the result of preRegister would be used as an input to findDelegateForNewObject(), but unfortunately one of the inputs to preRegister() is the MBeanServer, which is, of course, what findDelegateForNewObject() is looking up. Given this circularity, it would seem that findDelegateForNewObject() should simply return rootMBeanServer for null ObjectName inputs. In any case it should not entirely fail to register such MBeans.
> Fortunately, I have a utility wrapper around MBean registration, so I've added the following hack immediately prior to actually registering the MBean to workaround this issue:
> /* Hack to work around JBoss Wildfly bug (https://issues.jboss.org/browse/WFLY-3661).
> This isn't really quite correct, of course, since this means preRegister() will get called twice,
> but it appears to be about the best we can do.
> */
> if ( objectName == null )
> if ( mbean instanceof MBeanRegistration )
> if ( "org.jboss.as.jmx.PluggableMBeanServerImpl".equals( mbeanserver.getClass().getName() ) )
> objectName = ((MBeanRegistration)mbean).preRegister( mbeanserver, objectName );
> where mbeanserver is obtained via ManagementFactory.getPlatformMBeanServer().
--
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 Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-3619:
------------------------------------
Some questions that I have:
1. What does the datasource definition contain?
2. In what order is the Synchronization.beforeCompletion() running for org.hibernate + org.jboss.jca? I'm not sure if we will get the answer from enabling TRACE for org.jboss.jca, org.hibernate, org.jboss.as.jpa + com.arjuna but that will be a good start (when you have time to try that). No need to include the entire server.log. Just the part that shows the com.arjuna messages for transaction start and transaction ended.
> 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
[JBoss JIRA] (DROOLS-562) Can't install migration tool
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-562?page=com.atlassian.jira.plugin... ]
Petr Široký closed DROOLS-562.
------------------------------
Assignee: Petr Široký (was: Mark Proctor)
Resolution: Rejected
Closing this issue as it is build-related problem, which can be solved by custom settings.xml. Please re-open if you think the problem is elsewhere or the proposed solution does not work.
> Can't install migration tool
> ----------------------------
>
> Key: DROOLS-562
> URL: https://issues.jboss.org/browse/DROOLS-562
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Windows 7 Enterprise
> Reporter: Skip Skip
> Assignee: Petr Široký
> Priority: Blocker
>
> We are migrating some DROOLs from DROOLs 5.0 to the latest version, and moving our applications to JBoss AS 7.
> Looking into how to migrate these DROOLs, I found it recommended to use the migration tool that is located here drools-wb/drools-wb-jcr2vfs-migration at master · droolsjbpm/drools-wb · GitHub which is a sub-project of https://github.com/droolsjbpm/drools-wb
>
> When I try to build drools-wb with maven (mvn install), I keep dying here: Failure to find org.kie:kie-parent-with-dependencies:pom:6.2.0-SNAPSHOT
> When I try to just make the migration tool, I get this error:
> Unresolveable build extension: Plugin org.jboss.maven.plugins:maven-jdocbook-plugin:2.3.8 or one of its dependencies could not be resolved: The following artifacts could not be resolved: net.sf.docbook:docbook-xsl-ns:jar:1.74.0, net.socialchange.doctype:doctype-changer:jar:1.1: Could not find artifact net.sf.docbook:docbook-xsl-ns:jar:1.74.0 in gtrepositories
> Is the package 6.2.0-SNAPSHOT available anywhere publicly? If I don't have access to that code, is there a way for me to just get the migration utility?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (DROOLS-562) Can't install migration tool
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-562?page=com.atlassian.jira.plugin... ]
Petr Široký commented on DROOLS-562:
------------------------------------
If you are building directly the https://github.com/droolsjbpm/drools-wb, Maven won't find the `org.kie:kie-parent-with-dependencies:pom:6.2.0-SNAPSHOT`, because it is in jboss-public repo and Maven does not about it (the drools-wb pom is not listing it). I think you should use custom settings.xml and place the jboss-public repo there. The use `mvn install -s settings.xml` and the build should succeed. Or you can just download SNAPSHOTS directly.
> Can't install migration tool
> ----------------------------
>
> Key: DROOLS-562
> URL: https://issues.jboss.org/browse/DROOLS-562
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Windows 7 Enterprise
> Reporter: Skip Skip
> Assignee: Mark Proctor
> Priority: Blocker
>
> We are migrating some DROOLs from DROOLs 5.0 to the latest version, and moving our applications to JBoss AS 7.
> Looking into how to migrate these DROOLs, I found it recommended to use the migration tool that is located here drools-wb/drools-wb-jcr2vfs-migration at master · droolsjbpm/drools-wb · GitHub which is a sub-project of https://github.com/droolsjbpm/drools-wb
>
> When I try to build drools-wb with maven (mvn install), I keep dying here: Failure to find org.kie:kie-parent-with-dependencies:pom:6.2.0-SNAPSHOT
> When I try to just make the migration tool, I get this error:
> Unresolveable build extension: Plugin org.jboss.maven.plugins:maven-jdocbook-plugin:2.3.8 or one of its dependencies could not be resolved: The following artifacts could not be resolved: net.sf.docbook:docbook-xsl-ns:jar:1.74.0, net.socialchange.doctype:doctype-changer:jar:1.1: Could not find artifact net.sf.docbook:docbook-xsl-ns:jar:1.74.0 in gtrepositories
> Is the package 6.2.0-SNAPSHOT available anywhere publicly? If I don't have access to that code, is there a way for me to just get the migration utility?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JBMESSAGING-1954) MessagePostOffice.routeInternal() method may fail to release the readlock
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1954?page=com.atlassian.jira.... ]
Yong Hao Gao closed JBMESSAGING-1954.
-------------------------------------
Resolution: Done
revision 8631
> MessagePostOffice.routeInternal() method may fail to release the readlock
> -------------------------------------------------------------------------
>
> Key: JBMESSAGING-1954
> URL: https://issues.jboss.org/browse/JBMESSAGING-1954
> Project: JBoss Messaging
> Issue Type: Bug
> Components: Messaging Core
> Affects Versions: 1.4.8.SP11
> Reporter: Yong Hao Gao
> Assignee: Yong Hao Gao
> Fix For: 1.4.8.SP12
>
>
> This method first grabs the read lock and then release it in the finally block. However some statements are outside the try{}finally block so there is a chance the lock will never be released. The code is something like:
> private RouteResult routeInternal(...) throws Exception
> {
> //get the read lock
> lock.readLock().acquire();
> ...
> //check inactive condition
> if (inactiveConditions.contains(condition))
> {
> //look if this happens the readlock will NEVER be released!!!!
> throw new IllegalStateException("Destination " + condition + " not active!");
> }
>
> try
> {
> //do somework
> ......
> }
> finally
> {
> //release lock here
> lock.readLock().release();
> }
> Once it happens, it will block any attempts to get the write lock, and also block any further attempts to get read lock. Make those threads blocking forever.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (DROOLS-479) Pseudo Clock doesn't work for 2 not statements
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-479?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-479:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Pseudo Clock doesn't work for 2 not statements
> ----------------------------------------------
>
> Key: DROOLS-479
> URL: https://issues.jboss.org/browse/DROOLS-479
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final, 6.1.0.Beta3
> Environment: linux 14.04
> Reporter: Richard Ambridge
> Assignee: Mario Fusco
> Labels: pseudoclock
>
> If a rule (event) has the following:
> + "when\n"
> + " $s : Cheese(type==\"stinky\")\n"
> + " not( Cheese(type==\"a\", this after [0s,3s] $s ) )\n"
> + " not( Cheese(type==\"b\", this after [0s,5s] $s ) )\n" //2 * not
> and pseudo clock is used, the rule doesn't fire.
> If realtime clock is used, the rule works.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months