[JBoss JIRA] (WFLY-2845) On WildFly clean shutdown: failed marshalling rsp (UnsuccessfulResponse)
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2845?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2845:
-------------------------------
Fix Version/s: 9.0.0.CR1
(was: 9.0.0.Beta1)
> On WildFly clean shutdown: failed marshalling rsp (UnsuccessfulResponse)
> ------------------------------------------------------------------------
>
> Key: WFLY-2845
> URL: https://issues.jboss.org/browse/WFLY-2845
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.CR1
> Environment: RHEL6 x86_64; Oracle JDK 7
> Reporter: Michal Babacek
> Assignee: Paul Ferraro
> Labels: clustering
> Fix For: 9.0.0.CR1
>
>
> I've got two standalone-ha instances running on a one box. Each of these instances has {{<distributable/>}} [clusterbench|https://github.com/Karm/clusterbench/tree/simplified-and-pure] app deployed. When I start to shut the instances down via CLI command, one of them throws:
> {noformat}
> 08:59:33,341 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,shared=udp) ISPN000094: Received new cluster view: [jboss-eap-8.0/web|4] (1) [jboss-eap-8.0/web]
> 08:59:33,368 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher
> 08:59:33,379 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-0) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
> 08:59:33,380 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-1) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
> 08:59:33,392 INFO [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 558ms
> {noformat}
> In the log. It's a non-deterministic problem and it does not emerge always.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-2952) Add support to define security provider with a reference to a config file location
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2952?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2952:
-------------------------------
Fix Version/s: 9.0.0.CR1
(was: 9.0.0.Beta1)
> Add support to define security provider with a reference to a config file location
> ----------------------------------------------------------------------------------
>
> Key: WFLY-2952
> URL: https://issues.jboss.org/browse/WFLY-2952
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.CR1
>
>
> The big advantage of this is that the configuration file can be added to the app server installation, the configuration can then reference it relative to a known location within the app server installation.
> This will be the first step to move on from requiring the configuration to be global at the JVM level.
> Note: Dependencies may be an issue unless we can work out a way for services that depend on a specific provider to set the dependency.
> In addition to being able to specify the class name of the provider we will also need to be able to specify a module.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-2990) Forward port EAP 6.2/6.3 xml schemas
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2990?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2990:
-------------------------------
Fix Version/s: 9.0.0.CR1
(was: 9.0.0.Beta1)
> Forward port EAP 6.2/6.3 xml schemas
> ------------------------------------
>
> Key: WFLY-2990
> URL: https://issues.jboss.org/browse/WFLY-2990
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Blocker
> Fix For: 9.0.0.CR1
>
>
> EAP 6.3 will be introducing new versions of domain configuration xml schemas. These will basically be schemas containing some subset of the diff between the AS 7.2 schemas and the WF 9 schemas.
> These schemas and parsing thereof need to be forward ported into WF.
> Hopefully the schemas used for EAP 6.2 are already forward ported and this is mostly about 6.3.
> This is a parent task to capture the overall requirement and the task of analyzing what areas need the forward port. Subtasks or linked issues should be used for the specific porting tasks (e.g. one per subsystem)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-3044) Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-3044?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-3044:
-------------------------------
Fix Version/s: 9.0.0.CR1
(was: 9.0.0.Beta1)
> Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-3044
> URL: https://issues.jboss.org/browse/WFLY-3044
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 9.0.0.CR1
>
>
> The problem is in ViewScopeContextManager, namely
> {code}
> getContextMap(facesContext).put(contextual, new ViewScopeContextObject(contextual, creational, name));
> {code}
> probably it needs an artificial ID generated to serve as a key.
> Also the ViewScopeContextObject needs to be serializable as well among other things
> {code}
> class ViewScopeContextObject {
> {code}
> Issue manifests as
> {noformat}[Server:server-one] 19:22:41,564 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-15) ISPN000136: Execution error: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)
> [Server:server-one] at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:581)
> ...
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263)
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312)
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69)
> [Server:server-one] at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80)
> [Server:server-one] at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101)
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83)
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64)
> [Server:server-one] at org.infinispan.CacheImpl.endBatch(CacheImpl.java:777)
> [Server:server-one] at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53)
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.end(InfinispanBatcher.java:56)
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.close(InfinispanBatcher.java:46)
> [Server:server-one] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:72)
> [Server:server-one] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:704) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> [Server:server-one] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> [Server:server-one] Caused by: java.lang.RuntimeException: Failure to marshal argument(s)
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333)
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> [Server:server-one] ... 76 more
> [Server:server-one] Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.weld.bean.ManagedBean
> [Server:server-one] Caused by: an exception which occurred:
> [Server:server-one] in object java.util.HashMap@b37422bb
> [Server:server-one] in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue@b37422bb
> [Server:server-one] in object org.infinispan.commands.write.PutKeyValueCommand@db517a36
> [Server:server-one] in object org.infinispan.commands.tx.PrepareCommand@6fa34718
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month