[JBoss JIRA] (WFLY-3384) Problem with ServiceBasedNamingStore and JNDIView.
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3384?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-3384:
---------------------------------------
Hiding the exception is not a solution, the real issue here is the incorrect setup of jndi names, where entries that are not a context, e.g. java:jboss/clustering/group/ejb, have children. Without the exception that would never get caught.
> Problem with ServiceBasedNamingStore and JNDIView.
> --------------------------------------------------
>
> Key: WFLY-3384
> URL: https://issues.jboss.org/browse/WFLY-3384
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Environment: WildFly8.0.0, JDK8
> Reporter: Sławomir Wojtasiak
> Assignee: Eduardo Martins
>
> Some of the registered services are bound to the JNDI using the BinderService and the dependency mechanism to run the binder as soon as the main service runs. At this point everything works like a harm; services are registered and started successfully. But there is a little inconsistency, at least from the JNDI point of view which leads to a specific problem.
> Let's take a look at the following services:
> {quote}
> jboss.clustering.group.ejb.dist@a59ab61 State: UP (Uses: BinderService => JNDI: jboss.naming.context.java.jboss.clustering.group.ejb.dist)
> jboss.clustering.group.ejb@60e172ee State: DOWN (Uses: BinderService => JNDI: jboss.naming.context.java.jboss.clustering.group.ejb)
> {quote}
> As you can see they share the same path in the naming context (*jboss.naming.context.java.jboss.clustering.group.ejb*.dist). The second service _jboss.naming.context.java.jboss.clustering.group.ejb_ is a parent naming context to the first one: _jboss.naming.context.java.jboss.clustering.group.ejb.dist_. To make matters worse they do not depend on themselves, so when _jboss.clustering.group.ejb.dist_ is requested to be started (for instance by _jboss.clustering.providers.ejb.dist_ service) it starts immediately but _jboss.clustering.group.ejb_ is left in the WAITING state (It's ON_DEMAND service.). It leads to a situation where only the _jboss.clustering.group.ejb.dist_ service is registered in the naming context, but both services exist in the service registry.
> Such naming conflict can be a problem when for example we have to traverse through the naming context using ServiceBasedNamingStore as a naming provider. (JNDIView is a good example here, but I also managed to reproduce the problem when I messed up something with the remoting configuration. I don't remember details now.)
> JNDIView uses Context.list("") method in order to get the first level from the naming context. So in case of the _jboss.clustering.group.ejb.dist_ service the traverse path would be as follows:
> context.list("") -> returns "clustering"
> context.lookup( "clustering" ) returns NamingContext("clustering") because there is no service "jboss.clustering".
> NamingContext("clustering").list("") -> returns "group"
> NamingContext("clustering").lookup( "group" ) returns NamingContext("clustering/group") because there is no service "jboss.clustering.group".
> NamingContext("clustering/group").list("") -> returns "ejb"
> NamingContext("clustering/group").lookup("ejb") -> Fails!
> It fails with an _NameNotFoundException_ simply because the first thing the ServiceBasedNamingStore component does is to check if there is the _jboss.naming.context.java.jboss.clustering.group.ejb_ service in the service registry. It is available in the registry so ServiceBasedNamingStore decides to get the destination service instance the BinderService (_jboss.naming.context.java.jboss.clustering.group.ejb_) should point to. Service _jboss.clustering.group.ejb_ hasn't been started yet so its dependant the BinderService (_jboss.naming.context.java.jboss.clustering.group.ejb.dist_) couldn't resolve the injections and as so the BinderService does not point to the destination _jboss.clustering.group.ejb_ service instance. In the result, it ends with the exception because ServiceBasedNamingStore is not able to return the reference to the service the JNDI name _jboss.naming.context.java.jboss.clustering.group.ejb_ should point to. Notice that everything would be OK if there weren't running _jboss.naming.context.java.jboss.clustering.group.ejb.dist_ service, because Context.list("") ignores the _jboss.naming.context.java.jboss.clustering.group.ejb_ service as an unbound one.
> Anyway even if the service _jboss.naming.context.java.jboss.clustering.group.ejb_ was started properly and the naming context pointed to the _jboss.clustering.group.ejb_ service, it would lead to a different problem. The name _jboss.naming.context.java.jboss.clustering.group.ejb.dist_ wouldn't be found at all, because the _jboss.naming.context.java.jboss.clustering.group.ejb_ name would be treated as the end of the path while traversing using the Context.list("") method.
> It's probably a problem with the service naming convention, but anyway it is not an isolated case. There are a lot of services that follow the same naming rules but fortunately they are not registered in the naming context (yet?). For instance:
> {quote}
> jboss.clustering.group.hibernate.entity
> jboss.clustering.group.hibernate.timestamps
> jboss.clustering.group.hibernate
> {quote}
> Introducing something like a value aware NamingContext would also do the trick, but it's not natural for the JNDI.
> Anyway, it can be fixed in many ways, so for now I decided just to ignore such problematic services in the JNDIViewOperation just to avoid the exception.
> If anyone needs a workaround:
> Class: org.jboss.as.naming.management.JndiViewOperation
> jar: wildflay-naming-8.0.0.Final.jar
> Before (Line: 134):
> {code:title=org.jboss.as.naming.management.JndiViewOperation.java|borderStyle=solid}
> final Object value;
> if(context instanceof NamingContext) {
> value = ((NamingContext)context).lookup(pair.getName(), false);
> } else {
> value = context.lookup(pair.getName());
> }
> {code}
> After:
> {code:title=org.jboss.as.naming.management.JndiViewOperation.java|borderStyle=solid}
> Object value;
> try {
> if(context instanceof NamingContext) {
> value = ((NamingContext)context).lookup(pair.getName(), false);
> } else {
> value = context.lookup(pair.getName());
> }
> } catch( NameNotFoundException exc ) {
> value = null;
> }
> {code}
> It is the original exception:
> {noformat}
> 23:44:29,133 ERROR [stderr] (XNIO-1 task-8) javax.naming.NameNotFoundException: Error looking up clustering/group/ejb, service service jboss.naming.context.java.jboss.clustering.group.ejb is not started
> 23:44:29,133 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:133)
> 23:44:29,133 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> 23:44:29,134 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> 23:44:29,134 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> 23:44:29,134 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:136)
> 23:44:29,134 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:144)
> 23:44:29,135 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:144)
> 23:44:29,135 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation.access$0(JndiViewOperation.java:125)
> 23:44:29,135 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:75)
> 23:44:29,135 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591)
> 23:44:29,136 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469)
> 23:44:29,136 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273)
> 23:44:29,142 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268)
> 23:44:29,142 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272)
> 23:44:29,143 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146)
> 23:44:29,145 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:169)
> 23:44:29,147 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> 23:44:29,150 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> 23:44:29,151 ERROR [stderr] (XNIO-1 task-8) at java.security.AccessController.doPrivileged(Native Method)
> 23:44:29,151 ERROR [stderr] (XNIO-1 task-8) at javax.security.auth.Subject.doAs(Subject.java:422)
> 23:44:29,151 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94)
> 23:44:29,152 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> 23:44:29,152 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> 23:44:29,153 ERROR [stderr] (XNIO-1 task-8) at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:50)
> 23:44:29,153 ERROR [stderr] (XNIO-1 task-8) at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:77)
> 23:44:29,154 ERROR [stderr] (XNIO-1 task-8) at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> 23:44:29,154 ERROR [stderr] (XNIO-1 task-8) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
> 23:44:29,156 ERROR [stderr] (XNIO-1 task-8) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> 23:44:29,157 ERROR [stderr] (XNIO-1 task-8) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBLOGGING-112) JBoss Logging doesn't recognize log4j implementation
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created JBLOGGING-112:
---------------------------------------------
Summary: JBoss Logging doesn't recognize log4j implementation
Key: JBLOGGING-112
URL: https://issues.jboss.org/browse/JBLOGGING-112
Project: JBoss Logging
Issue Type: Bug
Affects Versions: 3.3.0.Alpha1
Reporter: Richard Achmatowicz
Assignee: James Perkins
There seems to be a typo in org.jboss.logging.LoggingProviders in the method tryLog4j(): the logging provider implementation used is Log4j2LoggerProvider, whereas it should be Log4jLoggerProvider.
The net effect is that if I have log4j jars on the classpath and include a log4j configuration, the configuration gets parsed but log4j is not used as the logging provider; instead, JDK logging provider is used.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly
by Rafael Benevides (JIRA)
[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ]
Rafael Benevides edited comment on WFLY-4171 at 1/19/15 6:33 PM:
-----------------------------------------------------------------
Add IT about minify profile to HTML5 Archetype: WFLY-4267
was (Author: rafabene):
Add IT about minify profile to HTML5 Archetype
> Provide an html5 archetype for wildfly
> --------------------------------------
>
> Key: WFLY-4171
> URL: https://issues.jboss.org/browse/WFLY-4171
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Fred Bricon
> Assignee: Rafael Benevides
>
> We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are :
> * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final
> * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4249) When a node left and rejoined the cluster, the authentication failed to sync.
by Jixing Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-4249?page=com.atlassian.jira.plugin.... ]
Jixing Wang commented on WFLY-4249:
-----------------------------------
NyxPrincipal is part of the deployment and the deployment has not completed at the time infinispan attempts to deserialise the class. I think somehow infinispan has to wait for the deployment to start up, or perform the deserialization in a lazy manner.
> When a node left and rejoined the cluster, the authentication failed to sync.
> -----------------------------------------------------------------------------
>
> Key: WFLY-4249
> URL: https://issues.jboss.org/browse/WFLY-4249
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.Alpha1
> Environment: Fedora 18, Java 1.7.0_45-b18 64Bit
> Reporter: Jixing Wang
> Assignee: Paul Ferraro
> Priority: Critical
>
> Hi there,
> When I try to use cluster features, I got an issue.
> With SSO enabled, when a node left and rejoined the cluster, the authentication failed to sync.
> I enabled SSO in standalone-ha.xml
> <single-sign-on/>
> Node 3:
> $JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -b=10.0.0.120 -u 230.0.0.4 -Djboss.node.name=node3 -Djboss.socket.binding.port-offset=100
> Node 4:
> $JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -b=10.0.0.120 -u 230.0.0.4 -Djboss.node.name=node4 -Djboss.socket.binding.port-offset=200
> I first started both nodes and logged in. Then I shut down node 3, and refresh the page. Everything worked fine until now. After this, I started node 3 again but I found I was logged out. When I shut down the node3, it worked again.
> I also tried different versions of WildFly, 8.1, 8.2 and 9.0 and it failed in all versions.
> The log from node 4 below happens sometimes but NOT always.
> 14:56:44,874 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-18,shared=udp) ISPN000094: Received new cluster view: [node4/web|3] (2) [node4/web, node3/web]
> 14:56:45,117 ERROR [org.infinispan.statetransfer.OutboundTransferTask] (transport-thread-12) Failed to send entries to node node3/web : ISPN000217: Received exception from node3/web, see cause for remote stack trace: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node3/web, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:362)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281)
> at org.infinispan.statetransfer.OutboundTransferTask.sendEntries(OutboundTransferTask.java:233)
> at org.infinispan.statetransfer.OutboundTransferTask.run(OutboundTransferTask.java:174)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_45]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_45]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_45]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: org.infinispan.commons.CacheException: Problems invoking command.
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:221)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:460)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:377)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:667)
> at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
> at org.jgroups.JChannel.up(JChannel.java:708)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1015)
> at org.jgroups.protocols.RSVP.up(RSVP.java:171)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:370)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1010)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:695)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:382)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:185)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:303)
> at org.jgroups.protocols.Discovery.up(Discovery.java:379)
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2622)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1412)
> at org.jgroups.protocols.TP$MyHandler.run(TP.java:1598)
> ... 3 more
> Caused by: java.io.InvalidClassException: com.britensw.nyx.core.security.NyxPrincipal; Module load failed
> at org.jboss.marshalling.ModularClassResolver.resolveClass(ModularClassResolver.java:104) [jboss-marshalling-1.4.8.Final.jar:1.4.8.Final]
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:949)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1256)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1746)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1659)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1286)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1746)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1659)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1286)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) [jboss-marshalling-1.4.8.Final.jar:1.4.8.Final]
> at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseAuthenticationEntryExternalizer.readObject(CoarseAuthenticationEntryExternalizer.java:57)
> at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseAuthenticationEntryExternalizer.readObject(CoarseAuthenticationEntryExternalizer.java:36)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:389)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:205)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:152)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:355)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) [jboss-marshalling-1.4.8.Final.jar:1.4.8.Final]
> at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.readObject(ImmortalCacheEntry.java:152)
> at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.readObject(ImmortalCacheEntry.java:142)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:389)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:205)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:152)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:355)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) [jboss-marshalling-1.4.8.Final.jar:1.4.8.Final]
> at org.infinispan.marshall.exts.ListExternalizer.readObject(ListExternalizer.java:62)
> at org.infinispan.marshall.exts.ListExternalizer.readObject(ListExternalizer.java:26)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:389)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:205)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:152)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:355)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) [jboss-marshalling-1.4.8.Final.jar:1.4.8.Final]
> at org.infinispan.statetransfer.StateChunk$Externalizer.readObject(StateChunk.java:88)
> at org.infinispan.statetransfer.StateChunk$Externalizer.readObject(StateChunk.java:65)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:389)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:205)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:152)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:355)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) [jboss-marshalling-1.4.8.Final.jar:1.4.8.Final]
> at org.infinispan.marshall.exts.ListExternalizer.readObject(ListExternalizer.java:62)
> at org.infinispan.marshall.exts.ListExternalizer.readObject(ListExternalizer.java:26)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:389)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:205)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:152)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:355)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) [jboss-marshalling-1.4.8.Final.jar:1.4.8.Final]
> at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readParameters(ReplicableCommandExternalizer.java:100)
> at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:146)
> at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:59)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:389)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:205)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:152)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:355)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) [jboss-marshalling-1.4.8.Final.jar:1.4.8.Final]
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:136)
> at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:101)
> at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80)
> at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:28)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:206)
> ... 27 more
> Caused by: org.jboss.modules.ModuleNotFoundException: deployment.nyx.war:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240) [jboss-modules.jar:1.3.4.Final]
> at org.jboss.marshalling.ModularClassResolver.resolveClass(ModularClassResolver.java:102) [jboss-marshalling-1.4.8.Final.jar:1.4.8.Final]
> ... 96 more
> Caused by: an exception which occurred:
> in field principal
> in object of type org.wildfly.extension.undertow.security.AccountImpl
> in field account
> in object of type io.undertow.security.api.AuthenticatedSessionManager$AuthenticatedSession
> 14:56:49,679 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,shared=udp) ISPN000094: Received new cluster view: [node4/ejb|3] (2) [node4/ejb, node3/ejb]
> 14:56:51,515 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-15,shared=udp) ISPN000094: Received new cluster view: [node4/hibernate|3] (2) [node4/hibernate, node3/hibernate]
> Apache configuration:
> <<mod_cluster.conf>>
> LoadModule proxy_module modules/mod_proxy.so
> LoadModule proxy_http_module modules/mod_proxy_http.so
> LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
> LoadModule slotmem_module modules/mod_slotmem.so
> LoadModule manager_module modules/mod_manager.so
> LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
> LoadModule advertise_module modules/mod_advertise.so
> MemManagerFile /var/cache/httpd
> <<cluster.conf>>
> Listen 10001
> <VirtualHost *:10001>
> ServerAdmin root(a)example.com
> ServerName localhost
> <Directory />
> Require all granted
> </Directory>
> <Location /mod_cluster_manager>
> SetHandler mod_cluster-manager
> Require all granted
> </Location>
> AdvertiseFrequency 5
> KeepAliveTimeout 60
> MaxKeepAliveRequests 0
> AllowDisplay On
> ManagerBalancerName mycluster
> ServerAdvertise On
> EnableMCPMReceive
> ErrorLog /var/log/httpd/error_log
> TransferLog /var/log/httpd/access_log
> </VirtualHost>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4265) Add support for caching handler
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4265?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4265:
--------------------------------------
There already is proper cache configuration in the undertow subsystem, as caching is used by the caching resource manager.
> Add support for caching handler
> -------------------------------
>
> Key: WFLY-4265
> URL: https://issues.jboss.org/browse/WFLY-4265
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 9.0.0.CR1
>
>
> Currently we cannot configure CacheHandler as it requires DirectCache as parameter in constructor.
> One option to fix this is to have few cache handler impls that would only have primitive parameters in constructor or getters / setters that would configure direct cache.
> Or add proper type cache configuration to undertow subsystem.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months