[JBoss JIRA] Created: (AS7-723) Creating XA datasource requires driver name and version
by Heiko Braun (JIRA)
Creating XA datasource requires driver name and version
-------------------------------------------------------
Key: AS7-723
URL: https://issues.jboss.org/browse/AS7-723
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Heiko Braun
Assignee: Heiko Braun
Fix For: 7.0.0.CR1
It's weird, because the XA datasource itself just relies on the DataSource class. The driver and version info is only needed to identify the module/service:
Request
{
"operation" => "add",
"address" => [
("profile" => "default"),
("subsystem" => "datasources"),
("xa-data-source" => "H2XADS")
],
"name" => "H2XADS",
"jndi-name" => "H2XADS",
"enabled" => true,
"xa-data-source-class" => "org.h2.jdbcx.JdbcDataSource",
"pool-name" => "H2XADS_Pool",
"user-name" => "sa",
"password" => "sa",
"xa-data-source-properties" => [("URL" => "jdbc:h2:mem:test")],
"child-type" => undefined
}
Response
Internal Server Error
{
"outcome" => "failed",
"result" => {"server-groups" => {"main-server-group" => {
"server-two" => {
"host" => "local",
"response" => {
"outcome" => "failed",
"failure-description" => "java.util.NoSuchElementException: No child 'driver' exists"
}
},
"server-one" => {
"host" => "local",
"response" => {
"outcome" => "failed",
"failure-description" => "java.util.NoSuchElementException: No child 'driver' exists"
}
}
}}},
"failure-description" => "Operation was not applied successfully to any servers"
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (JBRULES-2238) Accumulate should be implemented with left-input incremental so they don't start from scratch on every left-input retraction/assertion
by Geoffrey De Smet (JIRA)
Accumulate should be implemented with left-input incremental so they don't start from scratch on every left-input retraction/assertion
--------------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-2238
URL: https://jira.jboss.org/jira/browse/JBRULES-2238
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-core (expert)
Affects Versions: 5.0.1.FINAL
Reporter: Geoffrey De Smet
Assignee: Mark Proctor
The current accumulate implementation has a severe performance loss in the drools-solver context.
Edson said that this issue could be the culprit.
However, for this to be implemented the true modify feature should first be implemented.
See the discussion "Why is this DRL twice as slow?" on the dev user list.
>From IRC:
<ge0ffrey> more and more of my experiments show the poisones nature of accumulate for drools-solver. Probably because they are backwards chained (as I understand it?). Of course accummulate is great for many use cases, just not drools-solver.
<ge0ffrey> The problem is, I have no way to workaround them. I need the sum of my logically inserted objects.
<etirelli> ge0ffrey: no, accumulate are implemented as forward chain as usual
<etirelli> the problem is that a left-input retraction on an accumulate node will throw away any result and a leftinput assert will recalculate everything from scratch
<ge0ffrey> What do you mean by "must fully recalculate"?
<etirelli> mean from scratch
<ge0ffrey> Why does it do that?
<etirelli> remember that modify = retract+assert
<ge0ffrey> And right-input retractions won't recalculate everything from scratch?
<etirelli> no... right input are incremental
<ge0ffrey> would making leftinput assert incremental too be possible?
<etirelli> ge0ffrey: the only way to do left-input incremental is with a feature called "true modify"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (JBMESSAGING-1864) Deadlock in creating consumer during failover time
by Yong Hao Gao (JIRA)
Deadlock in creating consumer during failover time
--------------------------------------------------
Key: JBMESSAGING-1864
URL: https://issues.jboss.org/browse/JBMESSAGING-1864
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Clustering
Affects Versions: 1.4.8.GA, 1.4.0.SP3.CP12
Reporter: Yong Hao Gao
Assignee: Yong Hao Gao
Fix For: 1.4.0.SP3.CP13, 1.4.8.SP1
When a node is performing failover for the dead node, there is a possible condition where a dead lock could happen if a new binding is created at that time (triggered by creating a new subscription on a topic). To reproduce you need manually 'instrument' the code to create a suitable timing:
1 set up a 2 node cluster node0 and node1
2 kill node0 and let the failover happen. Let it stops at MessagingPostOffice.performFailover(), after the line
pm.mergeTransactions(failedNodeID.intValue(), thisNodeID);
So at this point the write lock is just about to be obtained.
3 create a consumer (must be a new subscriber) on node1, let the calling thread proceed to MessagingPostOffice.addBindingInMemory(), before the line:
clusterNotifier.sendNotification(notification);
The ClusterConnectionManager is the listener to handle the notification, meaning this call will result in holding the lock on ClusterConnectionManager (its notify() mehtod is synchronized)
4 then resume Step 2, the failover thread will grab the write lock and proceed. Along the way let it stop for another time at MessagingPostOffice.removeBindingInMemory(), before the line:
clusterNotifier.sendNotification(notification);
Now this failover thread holds the write lock of the post office and is about to get the lock on ClusterConnectionManager (because it is the listener to handle the notification in its synchronized notify() method).
5 Resume step 3, the consumer creating thread grabs the lock on ClusterConnectionManager. As it goes on, it calls MessagingPostOffice.getBindings() method, which is going to get the read lock of MessagingPostOffice. However at this moment the failover thread is holding the write lock, which prevents it from getting the read lock. It has to wait for it.
6. Now resume step 4. As it happens, in step 5 the consumer creating thread already gets the lock on ClusterConnectionManager, so it cannot proceed. In the meantime it holds the write lock and never get released, so the consumer creating thread will never get it. The two thread get dead-locked.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month