[JBoss JIRA] Created: (JBAS-4025) failing org.jboss.test.web.test.ssl.SSLUnitTestCase
by Dimitris Andreadis (JIRA)
failing org.jboss.test.web.test.ssl.SSLUnitTestCase
---------------------------------------------------
Key: JBAS-4025
URL: http://jira.jboss.com/jira/browse/JBAS-4025
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Test Suite
Environment: Java Version 1.5.0_10
Java Vendor Sun Microsystems Inc.
Java VM Name Java HotSpot(TM) Server VM
Java VM Version 1.5.0_10-b03
Java VM Info mixed mode
OS Name Linux
OS Version 2.6.9-42.0.2.ELsmp
OS Arch i386
Reporter: Dimitris Andreadis
Assigned To: Stan Silvert
Priority: Critical
Fix For: JBossAS-4.2.0.CR1
It seems the SSL connector of jboss-web is not configured properly?
In fact, a lot of other ssl security tests seem to fail.
Can you take a look Stan?
unknown Error Timeout occurred
junit.framework.AssertionFailedError: Timeout occurred
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months
[JBoss JIRA] Created: (JBAS-4015) failing org.jboss.test.invokers.test.MultiInvokersUnitTestCase
by Dimitris Andreadis (JIRA)
failing org.jboss.test.invokers.test.MultiInvokersUnitTestCase
--------------------------------------------------------------
Key: JBAS-4015
URL: http://jira.jboss.com/jira/browse/JBAS-4015
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Test Suite
Reporter: Dimitris Andreadis
Assigned To: Tom Elrod
Priority: Critical
Fix For: JBossAS-4.2.0.CR1
Testsuite: org.jboss.test.invokers.test.MultiInvokersUnitTestCase
Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 3.915 sec
Testcase: testMultiInvokers took 1.222 sec
Testcase: testClientContainer took 0.14 sec
Caused an ERROR
$Proxy7
java.lang.ClassCastException: $Proxy7
at org.jboss.test.invokers.test.MultiInvokersUnitTestCase.testClientContainer(MultiInvokersUnitTestCase.java:103)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months
[JBoss JIRA] Created: (JBCACHE-955) Restore ability to insert and remove child nodes with only a read lock on the parent
by Brian Stansberry (JIRA)
Restore ability to insert and remove child nodes with only a read lock on the parent
------------------------------------------------------------------------------------
Key: JBCACHE-955
URL: http://jira.jboss.com/jira/browse/JBCACHE-955
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 1.4.1.GA
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Priority: Critical
Fix For: 2.0.0.BETA1, 1.4.1.SP1
In 1.4.1.GA JBC introduced tighter locking semantics wherein the insertion or removal of a node required a write lock on the parent. In recent previous versions (and maybe always) only a read lock was required.
The 1.4.1.GA behavior provides greater correctness, but at a cost of lesser concurrency. Some applications written assuming the old behavior will not function properly with the new behavior.
Speaking in db isolation terms, let's say a non-repeatable-read means a tx reads a node's *data map* twice and gets different results. A phantom read means a tx reads a node's *child map* twice and gets different results. Conceptually, a JBC node represents both a "row" (data map) and a query result set (children map -- set of rows that share a common characteristic that the parent represents). (I know this analogy is inexact, but, ...).
In 1.4.0.SP1, REPEATABLE_READ meant you wouldn't get non-repeatable-reads, but could get phantom reads. With 1.4.1, you also don't get phantom reads (at least with respect to a node's immediate children). But, in many cases this behavior is unneeded and undesirable, and JBC no longer offers the old behavior.
This JIRA will restore the old behavior for the pessimistic locking use case. A new cache configuration flag LockParentForChildInsertRemove will be added. If set to false, the 1.4.0.SP1 behavior of only requiring the RL will be restored. The default value of the flag will be true.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months