[JBoss JIRA] (JBSEAM-4993) Deadlock between SFSB EJB lock and Component.getInstanceFromFactory factoryLock
4:28 p.m.
[
https://issues.jboss.org/browse/JBSEAM-4993?page=com.atlassian.jira.plugi...
]
Marek Schmidt updated JBSEAM-4993:
----------------------------------
Priority: Major (was: Critical)
Description:
The following sample demonstrates a deadlock between SFSB lock and the
Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("testString", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.SESSION)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the
same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and
then the Seam factory lock in the Component.getInstance call, while #{testString} locks
the factoryLock first.
was:
The following sample demonstrates a deadlock between SFSB lock and the
Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("foo", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.EVENT)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
{code}
@Name("testProducer")
public class TestProducer {
@Factory(scope=ScopeType.EVENT)
public String getFoo() {
return "foo";
}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the
same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and
then the Seam factoryLock in the Component.getInstance call, while #{testString} locks the
factoryLock first.
Forum Reference: https://community.jboss.org/message/741120#741120 (was:
https://community.jboss.org/message/741120#741120)
Deadlock between SFSB EJB lock and Component.getInstanceFromFactory
factoryLock
-------------------------------------------------------------------------------
Key: JBSEAM-4993
URL: https://issues.jboss.org/browse/JBSEAM-4993
Project: Seam 2
Issue Type: Bug
Components: Core
Affects Versions: 2.3.0.BETA2
Environment: JBoss AS 7.1.2.Final
Reporter: Marek Schmidt
Assignee: Marek Novotny
Fix For: 2.3.0.CR1
Attachments: jstack.txt, registration.tar.bz2, seam-registration.ear,
server.log.bz2, test.py
The following sample demonstrates a deadlock between SFSB lock and the
Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("testString", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.SESSION)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the
same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and
then the Seam factory lock in the Component.getInstance call, while #{testString} locks
the factoryLock first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:31 p.m.
[
https://issues.jboss.org/browse/JBSEAM-4993?page=com.atlassian.jira.plugi...
]
Marek Schmidt updated JBSEAM-4993:
----------------------------------
Attachment: seam-registration.ear
(attaching updated version of the EAR)
Deadlock between SFSB EJB lock and Component.getInstanceFromFactory
factoryLock
-------------------------------------------------------------------------------
Key: JBSEAM-4993
URL: https://issues.jboss.org/browse/JBSEAM-4993
Project: Seam 2
Issue Type: Bug
Components: Core
Affects Versions: 2.3.0.BETA2
Environment: JBoss AS 7.1.2.Final
Reporter: Marek Schmidt
Assignee: Marek Novotny
Fix For: 2.3.0.CR1
Attachments: JBSEAM-4993.tar.gz, jstack.txt, registration.tar.bz2,
seam-registration.ear, seam-registration.ear, server.log.bz2, test.py
The following sample demonstrates a deadlock between SFSB lock and the
Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("testString", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.SESSION)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the
same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and
then the Seam factory lock in the Component.getInstance call, while #{testString} locks
the factoryLock first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:31 p.m.
[
https://issues.jboss.org/browse/JBSEAM-4993?page=com.atlassian.jira.plugi...
]
Marek Schmidt updated JBSEAM-4993:
----------------------------------
Attachment: JBSEAM-4993.tar.gz
(attaching updated reproducer source)
Deadlock between SFSB EJB lock and Component.getInstanceFromFactory
factoryLock
-------------------------------------------------------------------------------
Key: JBSEAM-4993
URL: https://issues.jboss.org/browse/JBSEAM-4993
Project: Seam 2
Issue Type: Bug
Components: Core
Affects Versions: 2.3.0.BETA2
Environment: JBoss AS 7.1.2.Final
Reporter: Marek Schmidt
Assignee: Marek Novotny
Fix For: 2.3.0.CR1
Attachments: JBSEAM-4993.tar.gz, jstack.txt, registration.tar.bz2,
seam-registration.ear, seam-registration.ear, server.log.bz2, test.py
The following sample demonstrates a deadlock between SFSB lock and the
Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("testString", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.SESSION)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the
same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and
then the Seam factory lock in the Component.getInstance call, while #{testString} locks
the factoryLock first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:33 p.m.
[
https://issues.jboss.org/browse/JBSEAM-4993?page=com.atlassian.jira.plugi...
]
Marek Schmidt edited comment on JBSEAM-4993 at 7/3/12 10:32 AM:
----------------------------------------------------------------
(attaching updated reproducer source JBSEAM-4993.tar.gz)
was (Author: maschmid):
(attaching updated reproducer source)
Deadlock between SFSB EJB lock and Component.getInstanceFromFactory
factoryLock
-------------------------------------------------------------------------------
Key: JBSEAM-4993
URL: https://issues.jboss.org/browse/JBSEAM-4993
Project: Seam 2
Issue Type: Bug
Components: Core
Affects Versions: 2.3.0.BETA2
Environment: JBoss AS 7.1.2.Final
Reporter: Marek Schmidt
Assignee: Marek Novotny
Fix For: 2.3.0.CR1
Attachments: JBSEAM-4993.tar.gz, jstack.txt, registration.tar.bz2,
seam-registration.ear, seam-registration.ear, server.log.bz2, test.py, test.py
The following sample demonstrates a deadlock between SFSB lock and the
Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("testString", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.SESSION)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the
same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and
then the Seam factory lock in the Component.getInstance call, while #{testString} locks
the factoryLock first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:33 p.m.
[
https://issues.jboss.org/browse/JBSEAM-4993?page=com.atlassian.jira.plugi...
]
Marek Schmidt updated JBSEAM-4993:
----------------------------------
Attachment: test.py
Deadlock between SFSB EJB lock and Component.getInstanceFromFactory
factoryLock
-------------------------------------------------------------------------------
Key: JBSEAM-4993
URL: https://issues.jboss.org/browse/JBSEAM-4993
Project: Seam 2
Issue Type: Bug
Components: Core
Affects Versions: 2.3.0.BETA2
Environment: JBoss AS 7.1.2.Final
Reporter: Marek Schmidt
Assignee: Marek Novotny
Fix For: 2.3.0.CR1
Attachments: JBSEAM-4993.tar.gz, jstack.txt, registration.tar.bz2,
seam-registration.ear, seam-registration.ear, server.log.bz2, test.py, test.py
The following sample demonstrates a deadlock between SFSB lock and the
Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("testString", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.SESSION)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the
same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and
then the Seam factory lock in the Component.getInstance call, while #{testString} locks
the factoryLock first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:05 a.m.
[
https://issues.jboss.org/browse/JBSEAM-4993?page=com.atlassian.jira.plugi...
]
Marek Novotny resolved JBSEAM-4993.
-----------------------------------
Resolution: Partially Completed
Remaining issue is tracked in JBSEAM-4993
Deadlock between SFSB EJB lock and Component.getInstanceFromFactory
factoryLock
-------------------------------------------------------------------------------
Key: JBSEAM-4993
URL: https://issues.jboss.org/browse/JBSEAM-4993
Project: Seam 2
Issue Type: Bug
Components: Core
Affects Versions: 2.3.0.BETA2
Environment: JBoss AS 7.1.2.Final
Reporter: Marek Schmidt
Assignee: Marek Novotny
Fix For: 2.3.0.CR1
Attachments: JBSEAM-4993.tar.gz, jstack.txt, registration.tar.bz2,
seam-registration.ear, seam-registration.ear, server.log.bz2, test.py, test.py
The following sample demonstrates a deadlock between SFSB lock and the
Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("testString", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.SESSION)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the
same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and
then the Seam factory lock in the Component.getInstance call, while #{testString} locks
the factoryLock first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:07 a.m.
[
https://issues.jboss.org/browse/JBSEAM-4993?page=com.atlassian.jira.plugi...
]
Marek Novotny edited comment on JBSEAM-4993 at 7/18/12 4:06 AM:
----------------------------------------------------------------
Remaining issue will be on new issue.
was (Author: manaRH):
Remaining issue is tracked in JBSEAM-4993
Deadlock between SFSB EJB lock and Component.getInstanceFromFactory
factoryLock
-------------------------------------------------------------------------------
Key: JBSEAM-4993
URL: https://issues.jboss.org/browse/JBSEAM-4993
Project: Seam 2
Issue Type: Bug
Components: Core
Affects Versions: 2.3.0.BETA2
Environment: JBoss AS 7.1.2.Final
Reporter: Marek Schmidt
Assignee: Marek Novotny
Fix For: 2.3.0.CR1
Attachments: JBSEAM-4993.tar.gz, jstack.txt, registration.tar.bz2,
seam-registration.ear, seam-registration.ear, server.log.bz2, test.py, test.py
The following sample demonstrates a deadlock between SFSB lock and the
Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("testString", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.SESSION)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the
same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and
then the Seam factory lock in the Component.getInstance call, while #{testString} locks
the factoryLock first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:20 p.m.
[
https://issues.jboss.org/browse/JBSEAM-4993?page=com.atlassian.jira.plugi...
]
Marek Schmidt updated JBSEAM-4993:
----------------------------------
Description:
The following sample demonstrates a deadlock between SFSB lock and the
Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("foo", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.EVENT)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
{code}
@Name("testProducer")
public class TestProducer {
@Factory(scope=ScopeType.EVENT)
public String getFoo() {
return "foo";
}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the
same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and
then the Seam factoryLock in the Component.getInstance call, while #{testString} locks the
factoryLock first.
was:
The following sample demonstrates a deadlock between SFSB lock and the
Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("testString", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.SESSION)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the
same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and
then the Seam factory lock in the Component.getInstance call, while #{testString} locks
the factoryLock first.
Forum Reference: https://community.jboss.org/message/741120#741120 (was:
https://community.jboss.org/message/741120#741120)
(reverting to the original description, as this specific case is to be tracked by a
separate issue)
Deadlock between SFSB EJB lock and Component.getInstanceFromFactory
factoryLock
-------------------------------------------------------------------------------
Key: JBSEAM-4993
URL: https://issues.jboss.org/browse/JBSEAM-4993
Project: Seam 2
Issue Type: Bug
Components: Core
Affects Versions: 2.3.0.BETA2
Environment: JBoss AS 7.1.2.Final
Reporter: Marek Schmidt
Assignee: Marek Novotny
Fix For: 2.3.0.CR1
Attachments: JBSEAM-4993.tar.gz, jstack.txt, registration.tar.bz2,
seam-registration.ear, seam-registration.ear, server.log.bz2, test.py, test.py
The following sample demonstrates a deadlock between SFSB lock and the
Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("foo", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.EVENT)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
{code}
@Name("testProducer")
public class TestProducer {
@Factory(scope=ScopeType.EVENT)
public String getFoo() {
return "foo";
}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the
same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and
then the Seam factoryLock in the Component.getInstance call, while #{testString} locks the
factoryLock first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:03 p.m.
[
https://issues.jboss.org/browse/JBSEAM-4993?page=com.atlassian.jira.plugi...
]
Marek Novotny closed JBSEAM-4993.
---------------------------------
Deadlock between SFSB EJB lock and Component.getInstanceFromFactory
factoryLock
-------------------------------------------------------------------------------
Key: JBSEAM-4993
URL: https://issues.jboss.org/browse/JBSEAM-4993
Project: Seam 2
Issue Type: Bug
Components: Core
Affects Versions: 2.3.0.BETA2
Environment: JBoss AS 7.1.2.Final
Reporter: Marek Schmidt
Assignee: Marek Novotny
Fix For: 2.3.0.CR1
Attachments: JBSEAM-4993.tar.gz, jstack.txt, registration.tar.bz2,
seam-registration.ear, seam-registration.ear, server.log.bz2, test.py, test.py
The following sample demonstrates a deadlock between SFSB lock and the
Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("foo", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.EVENT)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
{code}
@Name("testProducer")
public class TestProducer {
@Factory(scope=ScopeType.EVENT)
public String getFoo() {
return "foo";
}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the
same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and
then the Seam factoryLock in the Component.getInstance call, while #{testString} locks the
factoryLock first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4254
days inactive
4352
days old
18 comments
3 participants
participants (3)
-
Marek Novotny (JIRA) -
Marek Schmidt (JIRA)
-
SBS JIRA Integration (JIRA)