6:02 a.m.
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Ales Justin
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to test
this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody here
who could confirm this. Please pay attention to it and comment this issue if it's not
correct.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:02 a.m.
New subject: [JBoss JIRA] Updated: (WELD-863) Replication of EJB Session Beans does not work in cluster
[
https://issues.jboss.org/browse/WELD-863?page=com.atlassian.jira.plugin.s...
]
Martin Gencur updated WELD-863:
-------------------------------
Attachment: weld-translator.ear
Attaching the ear file which I used for testing.
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Ales Justin
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to
test this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody
here who could confirm this. Please pay attention to it and comment this issue if it's
not correct.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:06 a.m.
New subject: [JBoss JIRA] Commented: (WELD-863) Replication of EJB Session Beans does not work in cluster
[
https://issues.jboss.org/browse/WELD-863?page=com.atlassian.jira.plugin.s...
]
Martin Gencur commented on WELD-863:
------------------------------------
I forgot to mention that a weld-numberguess example, which is not using EJBs, is working
just fine in a cluster.
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Ales Justin
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to
test this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody
here who could confirm this. Please pay attention to it and comment this issue if it's
not correct.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:13 a.m.
New subject: [JBoss JIRA] Updated: (WELD-863) Replication of EJB Session Beans does not work in cluster
[
https://issues.jboss.org/browse/WELD-863?page=com.atlassian.jira.plugin.s...
]
Jozef Hartinger updated WELD-863:
---------------------------------
Affects Version/s: 1.1.1.Final
15:11:23,150 DEBUG
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [6u****2V4A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
at
org.jboss.weld.bean.proxy.util.SerializableProxy.readObject(SerializableProxy.java:122)
[:6.1.0-SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
[:1.6.0_26]
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848)
[:1.6.0_26]
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
[:1.6.0_26]
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_26]
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
[:1.6.0_26]
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
[:1.6.0_26]
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
[:1.6.0_26]
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_26]
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_26]
at java.util.HashMap.readObject(HashMap.java:1030) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
[:1.6.0_26]
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848)
[:1.6.0_26]
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
[:1.6.0_26]
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_26]
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_26]
at
org.jboss.ha.framework.server.SimpleCachableMarshalledValue.get(SimpleCachableMarshalledValue.java:165)
[:2.0.0.Final]
at
org.jboss.web.tomcat.service.session.distributedcache.impl.SessionAttributeMarshallerImpl.unmarshal(SessionAttributeMarshallerImpl.java:89)
[:3.0.0.Final]
at
org.jboss.web.tomcat.service.session.distributedcache.ispn.CoarseSessionAttributeStorage.load(CoarseSessionAttributeStorage.java:66)
[:1.0.0.Final]
at
org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager$2.invoke(DistributedCacheManager.java:270)
[:1.0.0.Final]
at
org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager$2.invoke(DistributedCacheManager.java:252)
[:1.0.0.Final]
at
org.jboss.ha.ispn.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:69)
[:1.0.0.Final]
at
org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager.getData(DistributedCacheManager.java:284)
[:1.0.0.Final]
at
org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager.getSessionData(DistributedCacheManager.java:234)
[:1.0.0.Final]
at
org.jboss.web.tomcat.service.session.JBossCacheManager.loadSession(JBossCacheManager.java:2228)
[:6.1.0-SNAPSHOT]
at
org.jboss.web.tomcat.service.session.JBossCacheManager.findSession(JBossCacheManager.java:629)
[:6.1.0-SNAPSHOT]
at org.apache.catalina.connector.Request.doGetSession(Request.java:2558) [:]
at org.apache.catalina.connector.Request.getSession(Request.java:2315) [:]
at
org.jboss.web.tomcat.service.session.JvmRouteValve.checkJvmRoute(JvmRouteValve.java:95)
[:6.1.0-SNAPSHOT]
at
org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:85)
[:6.1.0-SNAPSHOT]
at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62)
[:6.1.0-SNAPSHOT]
at
org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
[:1.1.0.Final]
at
org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
[:1.1.0.Final]
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88)
[:6.1.0-SNAPSHOT]
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100)
[:6.1.0-SNAPSHOT]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
[:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
[:]
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
[:6.1.0-SNAPSHOT]
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:]
at
org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53)
[:6.1.0-SNAPSHOT]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
[:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:]
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654)
[:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at
org.jboss.weld.bean.proxy.util.SerializableProxy.readObject(SerializableProxy.java:118)
[:6.1.0-SNAPSHOT]
... 52 more
Caused by: java.lang.ClassNotFoundException:
org.jboss.weld.examples.translator.org$jboss$weld$bean-jboss$classloader$id="vfs$$$-JBossAS-farm$weld-translator$ear"-SessionBean-TranslatorControllerBean_$$_WeldProxy
at java.net.URLClassLoader$1.run(URLClassLoader.java:202) [:1.6.0_26]
at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
at java.net.URLClassLoader.findClass(URLClassLoader.java:190) [:1.6.0_26]
at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [:1.6.0_26]
at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [:1.6.0_26]
at java.lang.Class.forName0(Native Method) [:1.6.0_26]
at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
at
org.jboss.util.stream.MarshalledValueInputStream.resolveClass(MarshalledValueInputStream.java:81)
[jboss-common-core.jar:2.2.17.GA]
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574)
[:1.6.0_26]
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495)
[:1.6.0_26]
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731)
[:1.6.0_26]
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_26]
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_26]
at
org.jboss.weld.examples.translator.org$jboss$weld$bean-jboss$classloader$id="vfs$$$-JBossAS-farm$weld-translator$ear"-SessionBean-TranslatorControllerBean_$$_WeldProxy.deserializeProxy(org$jboss$weld$bean-jboss$classloader$id="vfs$$$-JBossAS-farm$weld-translator$ear"-SessionBean-TranslatorControllerBean_$$_WeldProxy.java)
[:]
... 57 more
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final, 1.1.1.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Ales Justin
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to
test this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody
here who could confirm this. Please pay attention to it and comment this issue if it's
not correct.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:59 a.m.
New subject: [JBoss JIRA] Updated: (WELD-863) Replication of EJB Session Beans does not work in cluster
[
https://issues.jboss.org/browse/WELD-863?page=com.atlassian.jira.plugin.s...
]
Jozef Hartinger updated WELD-863:
---------------------------------
Workaround Description: Package the application as a single war file.
Workaround: [Workaround Exists]
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final, 1.1.1.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Ales Justin
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to
test this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody
here who could confirm this. Please pay attention to it and comment this issue if it's
not correct.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:59 a.m.
New subject: [JBoss JIRA] Commented: (WELD-863) Replication of EJB Session Beans does not work in cluster
[
https://issues.jboss.org/browse/WELD-863?page=com.atlassian.jira.plugin.s...
]
Jozef Hartinger commented on WELD-863:
--------------------------------------
Note that the application works as expected when deployed as a single war file.
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final, 1.1.1.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Ales Justin
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to
test this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody
here who could confirm this. Please pay attention to it and comment this issue if it's
not correct.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:01 a.m.
New subject: [JBoss JIRA] Commented: (WELD-863) Replication of EJB Session Beans does not work in cluster
[
https://issues.jboss.org/browse/WELD-863?page=com.atlassian.jira.plugin.s...
]
Ales Justin commented on WELD-863:
----------------------------------
Did we try this .ear with latest AS7 (its cluster setup)?
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final, 1.1.1.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Ales Justin
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to
test this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody
here who could confirm this. Please pay attention to it and comment this issue if it's
not correct.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:22 a.m.
New subject: [JBoss JIRA] Commented: (WELD-863) Replication of EJB Session Beans does not work in cluster
[
https://issues.jboss.org/browse/WELD-863?page=com.atlassian.jira.plugin.s...
]
Jozef Hartinger commented on WELD-863:
--------------------------------------
I tested the .ear with two standalone as7 instances with standalone-ha configuration and
replication still does not work. I can see the following message in the server log:
10:19:06,933 WARN [org.jboss.as.clustering.web.infinispan.DistributedCacheManager]
(http--127.0.0.1-8180-1) Problem accessing session [nQ****V2mfaX]:
java.lang.RuntimeException: Failed to load session attributes for session: nQ****V2mfaX
10:19:06,933 DEBUG [org.jboss.as.clustering.web.infinispan.DistributedCacheManager]
(http--127.0.0.1-8180-1) Problem accessing session [nQ****V2mfaX]:
java.lang.RuntimeException: Failed to load session attributes for session: nQ****V2mfaX:
java.lang.RuntimeException: Failed to load session attributes for session: nQ****V2mfaX
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getRuntimeException(DistributedCacheManager.java:82)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager$3.invoke(DistributedCacheManager.java:285)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager$3.invoke(DistributedCacheManager.java:268)
at
org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:67)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getData(DistributedCacheManager.java:294)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionData(DistributedCacheManager.java:250)
at
org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1410)
[jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:701)
[jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84)
[jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.Request.doGetSession(Request.java:2618)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.Request.getSession(Request.java:2375)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:68)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:60)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:36)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:17)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:154)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.ClassNotFoundException:
ss.weld.examples.translator.SentenceParsernslator from [Module
"deployment.weld-translator.ear.weld-translator.war:main" from Service Module
Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
at
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
at java.lang.Class.forName0(Native Method) [:1.6.0_24]
at java.lang.Class.forName(Class.java:247) [:1.6.0_24]
at
org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
at
org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:868)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:898)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:898)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1310)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadMapObject(RiverUnmarshaller.java:195)
at
org.jboss.marshalling.river.RiverUnmarshaller.readMapData(RiverUnmarshaller.java:791)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:682)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at
org.jboss.as.clustering.SimpleMarshalledValue.get(SimpleMarshalledValue.java:84)
at
org.jboss.as.clustering.web.impl.SessionAttributeMarshallerImpl.unmarshal(SessionAttributeMarshallerImpl.java:70)
at
org.jboss.as.clustering.web.infinispan.CoarseSessionAttributeStorage.load(CoarseSessionAttributeStorage.java:65)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager$3.invoke(DistributedCacheManager.java:283)
... 23 more
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final, 1.1.1.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Ales Justin
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to
test this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody
here who could confirm this. Please pay attention to it and comment this issue if it's
not correct.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:24 a.m.
New subject: [JBoss JIRA] Issue Comment Edited: (WELD-863) Replication of EJB Session Beans does not work in cluster
[
https://issues.jboss.org/browse/WELD-863?page=com.atlassian.jira.plugin.s...
]
Jozef Hartinger edited comment on WELD-863 at 8/9/11 4:22 AM:
--------------------------------------------------------------
I tested the .ear with two standalone as7 instances with standalone-ha configuration and
replication still does not work. I can see the following message in the server log:
{noformat}
10:19:06,933 WARN [org.jboss.as.clustering.web.infinispan.DistributedCacheManager]
(http--127.0.0.1-8180-1) Problem accessing session [nQ****V2mfaX]:
java.lang.RuntimeException: Failed to load session attributes for session: nQ****V2mfaX
10:19:06,933 DEBUG [org.jboss.as.clustering.web.infinispan.DistributedCacheManager]
(http--127.0.0.1-8180-1) Problem accessing session [nQ****V2mfaX]:
java.lang.RuntimeException: Failed to load session attributes for session: nQ****V2mfaX:
java.lang.RuntimeException: Failed to load session attributes for session: nQ****V2mfaX
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getRuntimeException(DistributedCacheManager.java:82)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager$3.invoke(DistributedCacheManager.java:285)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager$3.invoke(DistributedCacheManager.java:268)
at
org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:67)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getData(DistributedCacheManager.java:294)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionData(DistributedCacheManager.java:250)
at
org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1410)
[jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:701)
[jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84)
[jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.Request.doGetSession(Request.java:2618)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.Request.getSession(Request.java:2375)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:68)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:60)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:36)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:17)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:154)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.ClassNotFoundException:
ss.weld.examples.translator.SentenceParsernslator from [Module
"deployment.weld-translator.ear.weld-translator.war:main" from Service Module
Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
at
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
at java.lang.Class.forName0(Native Method) [:1.6.0_24]
at java.lang.Class.forName(Class.java:247) [:1.6.0_24]
at
org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
at
org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:868)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:898)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:898)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1310)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadMapObject(RiverUnmarshaller.java:195)
at
org.jboss.marshalling.river.RiverUnmarshaller.readMapData(RiverUnmarshaller.java:791)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:682)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at
org.jboss.as.clustering.SimpleMarshalledValue.get(SimpleMarshalledValue.java:84)
at
org.jboss.as.clustering.web.impl.SessionAttributeMarshallerImpl.unmarshal(SessionAttributeMarshallerImpl.java:70)
at
org.jboss.as.clustering.web.infinispan.CoarseSessionAttributeStorage.load(CoarseSessionAttributeStorage.java:65)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager$3.invoke(DistributedCacheManager.java:283)
... 23 more
{noformat}
was (Author: jharting):
I tested the .ear with two standalone as7 instances with standalone-ha configuration
and replication still does not work. I can see the following message in the server log:
10:19:06,933 WARN [org.jboss.as.clustering.web.infinispan.DistributedCacheManager]
(http--127.0.0.1-8180-1) Problem accessing session [nQ****V2mfaX]:
java.lang.RuntimeException: Failed to load session attributes for session: nQ****V2mfaX
10:19:06,933 DEBUG [org.jboss.as.clustering.web.infinispan.DistributedCacheManager]
(http--127.0.0.1-8180-1) Problem accessing session [nQ****V2mfaX]:
java.lang.RuntimeException: Failed to load session attributes for session: nQ****V2mfaX:
java.lang.RuntimeException: Failed to load session attributes for session: nQ****V2mfaX
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getRuntimeException(DistributedCacheManager.java:82)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager$3.invoke(DistributedCacheManager.java:285)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager$3.invoke(DistributedCacheManager.java:268)
at
org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:67)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getData(DistributedCacheManager.java:294)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionData(DistributedCacheManager.java:250)
at
org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1410)
[jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:701)
[jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84)
[jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.Request.doGetSession(Request.java:2618)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.Request.getSession(Request.java:2375)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:68)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:60)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:36)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:17)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:154)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952)
[jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.ClassNotFoundException:
ss.weld.examples.translator.SentenceParsernslator from [Module
"deployment.weld-translator.ear.weld-translator.war:main" from Service Module
Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
at
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
at java.lang.Class.forName0(Native Method) [:1.6.0_24]
at java.lang.Class.forName(Class.java:247) [:1.6.0_24]
at
org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
at
org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:868)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:898)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:898)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1310)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadMapObject(RiverUnmarshaller.java:195)
at
org.jboss.marshalling.river.RiverUnmarshaller.readMapData(RiverUnmarshaller.java:791)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:682)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at
org.jboss.as.clustering.SimpleMarshalledValue.get(SimpleMarshalledValue.java:84)
at
org.jboss.as.clustering.web.impl.SessionAttributeMarshallerImpl.unmarshal(SessionAttributeMarshallerImpl.java:70)
at
org.jboss.as.clustering.web.infinispan.CoarseSessionAttributeStorage.load(CoarseSessionAttributeStorage.java:65)
at
org.jboss.as.clustering.web.infinispan.DistributedCacheManager$3.invoke(DistributedCacheManager.java:283)
... 23 more
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final, 1.1.1.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Ales Justin
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to
test this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody
here who could confirm this. Please pay attention to it and comment this issue if it's
not correct.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:58 a.m.
New subject: [JBoss JIRA] Commented: (WELD-863) Replication of EJB Session Beans does not work in cluster
[
https://issues.jboss.org/browse/WELD-863?page=com.atlassian.jira.plugin.s...
]
Stuart Douglas commented on WELD-863:
-------------------------------------
AFAIK ejb replication is not implemented in AS7 yet, it will be in 7.1
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final, 1.1.1.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Ales Justin
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to
test this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody
here who could confirm this. Please pay attention to it and comment this issue if it's
not correct.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:19 a.m.
New subject: [JBoss JIRA] Commented: (WELD-863) Replication of EJB Session Beans does not work in cluster
[
https://issues.jboss.org/browse/WELD-863?page=com.atlassian.jira.plugin.s...
]
Paul Ferraro commented on WELD-863:
-----------------------------------
Stuart is correct.
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final, 1.1.1.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Ales Justin
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to
test this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody
here who could confirm this. Please pay attention to it and comment this issue if it's
not correct.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:18 a.m.
New subject: [JBoss JIRA] (WELD-863) Replication of EJB Session Beans does not work in cluster
[
https://issues.jboss.org/browse/WELD-863?page=com.atlassian.jira.plugin.s...
]
Ales Justin reassigned WELD-863:
--------------------------------
Assignee: Tomaz Cerar (was: Ales Justin)
Tomaz, can you please test this?
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final, 1.1.1.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Tomaz Cerar
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to
test this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody
here who could confirm this. Please pay attention to it and comment this issue if it's
not correct.
--
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:14 p.m.
New subject: [JBoss JIRA] (WELD-863) Replication of EJB Session Beans does not work in cluster
[
https://issues.jboss.org/browse/WELD-863?page=com.atlassian.jira.plugin.s...
]
Stuart Douglas commented on WELD-863:
-------------------------------------
There are already tests in AS7 for this.
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final, 1.1.1.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Tomaz Cerar
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to
test this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody
here who could confirm this. Please pay attention to it and comment this issue if it's
not correct.
--
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:57 p.m.
New subject: [JBoss JIRA] (WELD-863) Replication of EJB Session Beans does not work in cluster
[
https://issues.jboss.org/browse/WELD-863?page=com.atlassian.jira.plugin.s...
]
Ales Justin resolved WELD-863.
------------------------------
Assignee: (was: Tomaz Cerar)
Resolution: Done
Per Stuart - already done in AS7.
(although we should still add some clustering tests directly into Weld_Core)
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final, 1.1.1.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to
test this feature. My fork of weld-core with the changes can be found at:
https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of
the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and
build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at
https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click
"Translate"
6) now change the port number in the address to 8180 and refresh (note that there should
be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is
stored in a field of SFSB which is clustered, but instead, you get the following exception
at the slave JBossAS instance:
12:00:16,662 WARN
[org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager]
Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException:
WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 -
from now the replication works fine. But IMHO this is not desired behaviour, the second
(backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody
here who could confirm this. Please pay attention to it and comment this issue if it's
not correct.
--
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
4687
days inactive
5048
days old
13 comments
5 participants
participants (5)
-
Ales Justin (JIRA) -
Jozef Hartinger (JIRA)
-
Martin Gencur (JIRA)
-
Paul Ferraro (JIRA)
-
Stuart Douglas (JIRA)