[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1878:
--------------------------------
I know. But looking at the options available with {{setSocketOption()}}, {{IP_MULTICAST_ALL}} is *not* among them, even in JDK 8.
> Multicast discovery does not work on JDK8
> -----------------------------------------
>
> Key: JGRP-1878
> URL: https://issues.jboss.org/browse/JGRP-1878
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.12, 3.5
> Environment: OpenJDK8, OracleJDK8u40
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 3.2.14, 3.6
>
> Attachments: mcast.java
>
>
> Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8.
> Steps to reproduce with draw, switch to JDK8:
> {noformat}
> export IP_ADDR=127.0.0.1
> ./draw.sh
> export IP_ADDR=192.168.1.10
> ./draw.sh
> {noformat}
> Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug..
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on JGRP-1878 at 9/5/14 8:58 AM:
--------------------------------------------------------------
{quote}So if we had IP_MULTICAST_ALL set to 1, we'd get the old behavior ?{quote}
If I am looking at the appropriate API for this, the problem is that this API is available only since JDK7:
http://docs.oracle.com/javase/7/docs/api/java/nio/channels/NetworkChannel...
Otherwise I don't see a clean way to do this on JDK6.
was (Author: rhusar):
{quote}So if we had IP_MULTICAST_ALL set to 1, we'd get the old behavior ?{quote}
If I am looking at the appropriate API for this, the problem is that this API is available only since JDK7:
http://docs.oracle.com/javase/7/docs/api/java/nio/channels/NetworkChannel...
Otherwise there is no clean way to do this on JDK6.
> Multicast discovery does not work on JDK8
> -----------------------------------------
>
> Key: JGRP-1878
> URL: https://issues.jboss.org/browse/JGRP-1878
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.12, 3.5
> Environment: OpenJDK8, OracleJDK8u40
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 3.2.14, 3.6
>
> Attachments: mcast.java
>
>
> Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8.
> Steps to reproduce with draw, switch to JDK8:
> {noformat}
> export IP_ADDR=127.0.0.1
> ./draw.sh
> export IP_ADDR=192.168.1.10
> ./draw.sh
> {noformat}
> Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug..
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on JGRP-1878:
--------------------------------------
{quote}So if we had IP_MULTICAST_ALL set to 1, we'd get the old behavior ?{quote}
If I am looking at the appropriate API for this, the problem is that this API is available only since JDK7:
http://docs.oracle.com/javase/7/docs/api/java/nio/channels/NetworkChannel...
Otherwise there is no clean way to do this on JDK6.
> Multicast discovery does not work on JDK8
> -----------------------------------------
>
> Key: JGRP-1878
> URL: https://issues.jboss.org/browse/JGRP-1878
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.12, 3.5
> Environment: OpenJDK8, OracleJDK8u40
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 3.2.14, 3.6
>
> Attachments: mcast.java
>
>
> Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8.
> Steps to reproduce with draw, switch to JDK8:
> {noformat}
> export IP_ADDR=127.0.0.1
> ./draw.sh
> export IP_ADDR=192.168.1.10
> ./draw.sh
> {noformat}
> Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug..
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (WFLY-3819) Fix PicketLink authentication workflow in SAML2KerberosAuthenticationTestCase
by Josef Cacek (JIRA)
Josef Cacek created WFLY-3819:
---------------------------------
Summary: Fix PicketLink authentication workflow in SAML2KerberosAuthenticationTestCase
Key: WFLY-3819
URL: https://issues.jboss.org/browse/WFLY-3819
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Josef Cacek
Assignee: Josef Cacek
The {{SAML2KerberosAuthenticationTestCase}} uses wrong PicketLink authentication workflow (double-redirect to IDP). Originally it was a workaround for PL bug which is fixed now.
We should remove the workaround even if the test-case is ignored now.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on JGRP-1877:
-----------------------------------
{code}
public boolean waitFor(long timeout) {
final long timeout_ns=TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS);
lock.lock();
boolean intr = false;
try {
for(long wait_time=timeout_ns, start=System.nanoTime();
!done && wait_time > 0;
wait_time=timeout_ns - (System.nanoTime()-start)) {
try {
System.out.println("wait(" + TimeUnit.MILLISECONDS.convert(wait_time,TimeUnit.NANOSECONDS) + ")");
cond.await(wait_time,TimeUnit.NANOSECONDS);
}
catch(InterruptedException e) {
intr = true;
}
}
return done;
}
finally {
lock.unlock();
if (intr) Thread.currentThread().interrupt();
}
}
{code}
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (WFLY-835) @Resource UserTransaction error when file passivation store is selected
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-835?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated WFLY-835:
-----------------------------------------
Bugzilla Update: (was: Perform)
Bugzilla References: (was: https://bugzilla.redhat.com/show_bug.cgi?id=1138649)
> @Resource UserTransaction error when file passivation store is selected
> -----------------------------------------------------------------------
>
> Key: WFLY-835
> URL: https://issues.jboss.org/browse/WFLY-835
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: Ubuntu 11.10, Intel® Core™ i3-2120 CPU @ 3.30GHz × 4
> Reporter: Abraham Cabanillas Piera
> Assignee: David Lloyd
> Priority: Critical
> Labels: jboss
> Attachments: serializationerr_server.log
>
>
> The following exception is launched when the server tries to passivate into the file passivation storage a stateful EJB session with UserTransaction injected as a resource:
> {noformat}
> [org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-10-thread-1) JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}: java.lang.RuntimeException: JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:288) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_13]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.io.NotSerializableException: org.jboss.tm.usertx.client.ServerVMClientUserTransaction
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
> at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
> at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_13]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl.writeObject(SerializationGroupMemberImpl.java:368) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
> at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> ... 15 more
> Caused by: an exception which occurred:
> in field userTransaction
> in field instance
> in field instance
> in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl@6a4de0c9
> {noformat}
> The EJB subsystem configuration is:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:1.2">
> <session-bean>
> <stateless>
> <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
> </stateless>
> <stateful default-access-timeout="10000" cache-ref="passivating"/>
> <singleton default-access-timeout="5000"/>
> </session-bean>
> <mdb>
> <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
> <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
> </mdb>
> <pools>
> <bean-instance-pools>
> <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> </bean-instance-pools>
> </pools>
> <caches>
> <cache name="simple" aliases="NoPassivationCache"/>
> <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
> </caches>
> <passivation-stores>
> <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
> </passivation-stores>
> <async thread-pool-name="default"/>
> <timer-service thread-pool-name="default">
> <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
> </timer-service>
> <remote connector-ref="remoting-connector" thread-pool-name="default"/>
> <thread-pools>
> <thread-pool name="default">
> <max-threads count="100"/>
> <keepalive-time time="100" unit="milliseconds"/>
> </thread-pool>
> </thread-pools>
> <iiop enable-by-default="false" use-qualified-name="false"/>
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (WFLY-835) @Resource UserTransaction error when file passivation store is selected
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-835?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated WFLY-835:
-----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1138649
> @Resource UserTransaction error when file passivation store is selected
> -----------------------------------------------------------------------
>
> Key: WFLY-835
> URL: https://issues.jboss.org/browse/WFLY-835
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: Ubuntu 11.10, Intel® Core™ i3-2120 CPU @ 3.30GHz × 4
> Reporter: Abraham Cabanillas Piera
> Assignee: David Lloyd
> Priority: Critical
> Labels: jboss
> Attachments: serializationerr_server.log
>
>
> The following exception is launched when the server tries to passivate into the file passivation storage a stateful EJB session with UserTransaction injected as a resource:
> {noformat}
> [org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-10-thread-1) JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}: java.lang.RuntimeException: JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:288) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_13]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.io.NotSerializableException: org.jboss.tm.usertx.client.ServerVMClientUserTransaction
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
> at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
> at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_13]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl.writeObject(SerializationGroupMemberImpl.java:368) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
> at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> ... 15 more
> Caused by: an exception which occurred:
> in field userTransaction
> in field instance
> in field instance
> in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl@6a4de0c9
> {noformat}
> The EJB subsystem configuration is:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:1.2">
> <session-bean>
> <stateless>
> <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
> </stateless>
> <stateful default-access-timeout="10000" cache-ref="passivating"/>
> <singleton default-access-timeout="5000"/>
> </session-bean>
> <mdb>
> <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
> <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
> </mdb>
> <pools>
> <bean-instance-pools>
> <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> </bean-instance-pools>
> </pools>
> <caches>
> <cache name="simple" aliases="NoPassivationCache"/>
> <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
> </caches>
> <passivation-stores>
> <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
> </passivation-stores>
> <async thread-pool-name="default"/>
> <timer-service thread-pool-name="default">
> <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
> </timer-service>
> <remote connector-ref="remoting-connector" thread-pool-name="default"/>
> <thread-pools>
> <thread-pool name="default">
> <max-threads count="100"/>
> <keepalive-time time="100" unit="milliseconds"/>
> </thread-pool>
> </thread-pools>
> <iiop enable-by-default="false" use-qualified-name="false"/>
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months