[JBoss JIRA] (WFLY-6676) NPE on un-marshalling remote command from byte buffer, vanilla ISPN config
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6676?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-6676 at 6/16/16 5:26 PM:
---------------------------------------------------------------
Can you add steps to reproduce? Or just booting 2nd node after there are already some sessions created on the 1st?
was (Author: rhusar):
Can you add steps to reproduce?
> NPE on un-marshalling remote command from byte buffer, vanilla ISPN config
> --------------------------------------------------------------------------
>
> Key: WFLY-6676
> URL: https://issues.jboss.org/browse/WFLY-6676
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Bogdan Sikora
> Assignee: Radoslav Husar
>
> Started WildFly with default configuration to check some test
> 10.1.0.Final-SNAPSHOT
> HEAD b812136479c976fe3a25668a8159c3f950fce9d5
> Node names jboss-eap* are there just to make it more confusing it is in fact wildfly
> An apocalypse (huge amount of log text) starts when second server tries to sync with the first
> log from first
> {noformat}
> 2016-06-07 04:29:41,174 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.1.0.Final-SNAPSHOT (WildFly Core 2.2.0.CR2) started in 24129ms - Started 990 of 1289 services (536 services are lazy, passive or on-demand)
> 2016-06-07 04:29:46,164 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,jboss-eap-7.0) ISPN000094: Received new cluster view for channel server: [jboss-eap-7.0|1] (2) [jboss-eap-7.0, jboss-eap-7.0-2]
> 2016-06-07 04:29:46,218 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,jboss-eap-7.0) ISPN000094: Received new cluster view for channel web: [jboss-eap-7.0|1] (2) [jboss-eap-7.0, jboss-eap-7.0-2]
> 2016-06-07 04:29:46,270 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,jboss-eap-7.0) ISPN000094: Received new cluster view for channel ejb: [jboss-eap-7.0|1] (2) [jboss-eap-7.0, jboss-eap-7.0-2]
> 2016-06-07 04:29:46,339 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,jboss-eap-7.0) ISPN000094: Received new cluster view for channel hibernate: [jboss-eap-7.0|1] (2) [jboss-eap-7.0, jboss-eap-7.0-2]
> 2016-06-07 04:29:47,995 WARN [org.jgroups.protocols.UNICAST3] (thread-1,ee,jboss-eap-7.0) JGRP000041: jboss-eap-7.0: message jboss-eap-7.0-2::3298534883369 not found in retransmission table
> 2016-06-07 04:29:47,995 WARN [org.jgroups.protocols.UNICAST3] (thread-1,ee,jboss-eap-7.0) JGRP000041: jboss-eap-7.0: message jboss-eap-7.0-2::3298534883392 not found in retransmission table
> 2016-06-07 04:29:47,996 WARN [org.jgroups.protocols.UNICAST3] (thread-1,ee,jboss-eap-7.0) JGRP000041: jboss-eap-7.0: message jboss-eap-7.0-2::3298534883393 not found in retransmission table
> 2016-06-07 04:29:47,996 WARN [org.jgroups.protocols.UNICAST3] (thread-1,ee,jboss-eap-7.0) JGRP000041: jboss-eap-7.0: message jboss-eap-7.0-2::3298534883394 not found in retransmission table
> 2016-06-07 04:29:47,996 WARN [org.jgroups.protocols.UNICAST3] (thread-1,ee,jboss-eap-7.0) JGRP000041: jboss-eap-7.0: message jboss-eap-7.0-2::3298534883395 not found in retransmission table
> 2016-06-07 04:29:47,996 WARN [org.jgroups.protocols.UNICAST3] (thread-1,ee,jboss-eap-7.0) JGRP000041: jboss-eap-7.0: message jboss-eap-7.0-2::3298534883396 not found in retransmission table
> {noformat}
> second (joining one )
> {noformat}
> 2016-06-07 04:29:49,163 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000094: Received new cluster view for channel hibernate: [jboss-eap-7.0|1] (2) [jboss-eap-7.0, jboss-eap-7.0-2]
> 2016-06-07 04:29:49,171 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000094: Received new cluster view for channel ejb: [jboss-eap-7.0|1] (2) [jboss-eap-7.0, jboss-eap-7.0-2]
> 2016-06-07 04:29:49,172 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000079: Channel ejb local address is jboss-eap-7.0-2, physical addresses are [192.168.124.246:55301]
> 2016-06-07 04:29:49,186 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000094: Received new cluster view for channel server: [jboss-eap-7.0|1] (2) [jboss-eap-7.0, jboss-eap-7.0-2]
> 2016-06-07 04:29:49,187 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000079: Channel server local address is jboss-eap-7.0-2, physical addresses are [192.168.124.246:55301]
> 2016-06-07 04:29:49,187 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000094: Received new cluster view for channel web: [jboss-eap-7.0|1] (2) [jboss-eap-7.0, jboss-eap-7.0-2]
> 2016-06-07 04:29:49,188 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000079: Channel web local address is jboss-eap-7.0-2, physical addresses are [192.168.124.246:55301]
> 2016-06-07 04:29:49,211 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000079: Channel hibernate local address is jboss-eap-7.0-2, physical addresses are [192.168.124.246:55301]
> 2016-06-07 04:29:51,032 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (MSC service thread 1-4) ISPN000329: Unable to read rebalancing status from coordinator jboss-eap-7.0: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from jboss-eap-7.0, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:760)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$174(JGroupsTransport.java:599)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.futureDone(SingleResponseFuture.java:30)
> at org.jgroups.blocks.Request.checkCompletion(Request.java:151)
> at org.jgroups.blocks.UnicastRequest.receiveResponse(UnicastRequest.java:75)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:369)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:233)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:695)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> at org.jgroups.stack.Protocol.up(Protocol.java:379)
> at org.jgroups.protocols.FORK.up(FORK.java:114)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:392)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1043)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Got
> {noformat}
> 03:44:54,741 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (thread-5,ee,jboss-eap-7.0) ISPN000220: Problems un-marshalling remote command from byte buffer: java.io.EOFException: Read past end of file
> at org.jboss.marshalling.SimpleDataInput.eofOnRead(SimpleDataInput.java:151)
> at org.jboss.marshalling.SimpleDataInput.readBoolean(SimpleDataInput.java:220)
> at org.infinispan.commons.marshall.MarshallUtil.unmarshallString(MarshallUtil.java:250)
> at org.infinispan.topology.CacheTopologyControlCommand.readFrom(CacheTopologyControlCommand.java:319)
> at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readCommandParameters(ReplicableCommandExternalizer.java:113)
> at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readObject(ReplicableCommandExternalizer.java:89)
> at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readObject(ReplicableCommandExternalizer.java:41)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:478)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:235)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:149)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:354)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:134)
> 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.jboss.as.clustering.infinispan.ChannelTransport$1.objectFromBuffer(ChannelTransport.java:57)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:160)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:398)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:348)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:233)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:695)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> at org.jgroups.stack.Protocol.up(Protocol.java:379)
> at org.jgroups.protocols.FORK.up(FORK.java:114)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:379)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1043)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$4(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> and
> {noformat}
> ^[[0m^[[33m03:45:52,719 WARN [org.jgroups.protocols.UNICAST3] (thread-2,ee,jboss-eap-7.0) JGRP000041: jboss-eap-7.0: message jboss-eap-7.0-2::1099511723291 not found in retransmission table
> ^[[0m^[[33m03:45:52,719 WARN [org.jgroups.protocols.UNICAST3] (thread-2,ee,jboss-eap-7.0) JGRP000041: jboss-eap-7.0: message jboss-eap-7.0-2::1099511723292 not found in retransmission table
> ^[[0m^[[33m03:45:52,719 WARN [org.jgroups.protocols.UNICAST3] (thread-2,ee,jboss-eap-7.0) JGRP000041: jboss-eap-7.0: message jboss-eap-7.0-2::1099511723293 not found in retransmission table
> ^[[0m^[[33m03:45:52,719 WARN [org.jgroups.protocols.UNICAST3] (thread-2,ee,jboss-eap-7.0) JGRP000041: jboss-eap-7.0: message jboss-eap-7.0-2::1099511723294 not found in retransmission table
> ^[[0m^[[33m03:45:52,896 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$LogWrapper] (thread-16,ee,jboss-eap-7.0-2) ISPN000220: Problems un-marshalling remote command from byte buffer: java.lang.NullPointerException
> at org.infinispan.topology.CacheTopologyControlCommand.setParameters(CacheTopologyControlCommand.java:258)
> at org.infinispan.commands.RemoteCommandsFactory.fromStream(RemoteCommandsFactory.java:187)
> at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readObject(ReplicableCommandExternalizer.java:93)
> at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readObject(ReplicableCommandExternalizer.java:39)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:479)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:234)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:149)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:354)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:134)
> 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.jboss.as.clustering.infinispan.ChannelTransport$1.objectFromBuffer(ChannelTransport.java:57)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:143)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:398)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:348)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:233)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:695)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> at org.jgroups.stack.Protocol.up(Protocol.java:379)
> at org.jgroups.protocols.FORK.up(FORK.java:114)
> 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:392)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1043)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:435)
> at org.jgroups.protocols.pbcast.NAKACK2.deliver(NAKACK2.java:957)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:839)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:611)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> standalone-ha.xml
> {noformat}
> <?xml version="1.0" encoding="UTF-8"?><server xmlns="urn:jboss:domain:4.1">
> <extensions>
> <extension module="org.jboss.as.clustering.infinispan"/>
> <extension module="org.jboss.as.clustering.jgroups"/>
> <extension module="org.jboss.as.connector"/>
> <extension module="org.jboss.as.deployment-scanner"/>
> <extension module="org.jboss.as.ee"/>
> <extension module="org.jboss.as.ejb3"/>
> <extension module="org.jboss.as.jaxrs"/>
> <extension module="org.jboss.as.jdr"/>
> <extension module="org.jboss.as.jmx"/>
> <extension module="org.jboss.as.jpa"/>
> <extension module="org.jboss.as.jsf"/>
> <extension module="org.jboss.as.logging"/>
> <extension module="org.jboss.as.mail"/>
> <extension module="org.jboss.as.modcluster"/>
> <extension module="org.jboss.as.naming"/>
> <extension module="org.jboss.as.pojo"/>
> <extension module="org.jboss.as.remoting"/>
> <extension module="org.jboss.as.sar"/>
> <extension module="org.jboss.as.security"/>
> <extension module="org.jboss.as.transactions"/>
> <extension module="org.jboss.as.webservices"/>
> <extension module="org.jboss.as.weld"/>
> <extension module="org.wildfly.extension.batch.jberet"/>
> <extension module="org.wildfly.extension.bean-validation"/>
> <extension module="org.wildfly.extension.clustering.singleton"/>
> <extension module="org.wildfly.extension.io"/>
> <extension module="org.wildfly.extension.request-controller"/>
> <extension module="org.wildfly.extension.security.manager"/>
> <extension module="org.wildfly.extension.undertow"/>
> </extensions>
> <system-properties>
> <property name="jboss.mod_cluster.jvmRoute" value="jboss-eap-7.0-2"/>
> <property name="jboss.node.name" value="jboss-eap-7.0-2"/>
> </system-properties>
> <management>
> <security-realms>
> <security-realm name="ManagementRealm">
> <authentication>
> <local default-user="$local" skip-group-loading="true"/>
> <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
> </authentication>
> <authorization map-groups-to-roles="false">
> <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
> </authorization>
> </security-realm>
> <security-realm name="ApplicationRealm">
> <authentication>
> <local default-user="$local" allowed-users="*" skip-group-loading="true"/>
> <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
> </authentication>
> <authorization>
> <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
> </authorization>
> </security-realm>
> </security-realms>
> <audit-log>
> <formatters>
> <json-formatter name="json-formatter"/>
> </formatters>
> <handlers>
> <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
> </handlers>
> <logger log-boot="true" log-read-only="false" enabled="false">
> <handlers>
> <handler name="file"/>
> </handlers>
> </logger>
> </audit-log>
> <management-interfaces>
> <http-interface security-realm="ManagementRealm" http-upgrade-enabled="true">
> <socket-binding http="management-http"/>
> </http-interface>
> </management-interfaces>
> <access-control provider="simple">
> <role-mapping>
> <role name="SuperUser">
> <include>
> <user name="$local"/>
> </include>
> </role>
> </role-mapping>
> </access-control>
> </management>
> <profile>
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> <periodic-rotating-file-handler name="FILE" autoflush="true">
> <formatter>
> <named-formatter name="PATTERN"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="server.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="true"/>
> </periodic-rotating-file-handler>
> <logger category="com.arjuna">
> <level name="WARN"/>
> </logger>
> <logger category="org.jboss.as.config">
> <level name="DEBUG"/>
> </logger>
> <logger category="sun.rmi">
> <level name="WARN"/>
> </logger>
> <root-logger>
> <level name="INFO"/>
> <handlers>
> <handler name="CONSOLE"/>
> <handler name="FILE"/>
> </handlers>
> </root-logger>
> <formatter name="PATTERN">
> <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
> </formatter>
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
> </formatter>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:batch-jberet:1.0">
> <default-job-repository name="in-memory"/>
> <default-thread-pool name="batch"/>
> <job-repository name="in-memory">
> <in-memory/>
> </job-repository>
> <thread-pool name="batch">
> <max-threads count="10"/>
> <keepalive-time time="30" unit="seconds"/>
> </thread-pool>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:bean-validation:1.0"/>
> <subsystem xmlns="urn:jboss:domain:datasources:4.0">
> <datasources>
> <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
> <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
> <driver>h2</driver>
> <security>
> <user-name>sa</user-name>
> <password>sa</password>
> </security>
> </datasource>
> <drivers>
> <driver name="h2" module="com.h2database.h2">
> <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
> </driver>
> </drivers>
> </datasources>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:ee:4.0">
> <spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>
> <concurrent>
> <context-services>
> <context-service name="default" jndi-name="java:jboss/ee/concurrency/context/default" use-transaction-setup-provider="true"/>
> </context-services>
> <managed-thread-factories>
> <managed-thread-factory name="default" jndi-name="java:jboss/ee/concurrency/factory/default" context-service="default"/>
> </managed-thread-factories>
> <managed-executor-services>
> <managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/>
> </managed-executor-services>
> <managed-scheduled-executor-services>
> <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
> </managed-scheduled-executor-services>
> </concurrent>
> <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:ejb3:4.0">
> <session-bean>
> <stateless>
> <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
> </stateless>
> <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
> <singleton default-access-timeout="5000"/>
> </session-bean>
> <pools>
> <bean-instance-pools>
> <!-- Automatically configure pools. Alternatively, max-pool-size can be set to a specific value -->
> <strict-max-pool name="slsb-strict-max-pool" derive-size="from-worker-pools" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> <strict-max-pool name="mdb-strict-max-pool" derive-size="from-cpu-count" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> </bean-instance-pools>
> </pools>
> <caches>
> <cache name="simple"/>
> <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
> </caches>
> <passivation-stores>
> <passivation-store name="infinispan" cache-container="ejb" max-size="10000"/>
> </passivation-stores>
> <async thread-pool-name="default"/>
> <timer-service thread-pool-name="default" default-data-store="default-file-store">
> <data-stores>
> <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/>
> </data-stores>
> </timer-service>
> <remote connector-ref="http-remoting-connector" thread-pool-name="default"/>
> <thread-pools>
> <thread-pool name="default">
> <max-threads count="10"/>
> <keepalive-time time="100" unit="milliseconds"/>
> </thread-pool>
> </thread-pools>
> <default-security-domain value="other"/>
> <default-missing-method-permissions-deny-access value="true"/>
> <log-system-exceptions value="true"/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:io:1.1">
> <worker name="default"/>
> <buffer-pool name="default"/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
> <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
> <transport lock-timeout="60000"/>
> <replicated-cache name="default" mode="SYNC">
> <transaction mode="BATCH"/>
> </replicated-cache>
> </cache-container>
> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
> <transport lock-timeout="60000"/>
> <distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
> <locking isolation="REPEATABLE_READ"/>
> <transaction mode="BATCH"/>
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
> <transport lock-timeout="60000"/>
> <distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
> <locking isolation="REPEATABLE_READ"/>
> <transaction mode="BATCH"/>
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
> <transport lock-timeout="60000"/>
> <local-cache name="local-query">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> <invalidation-cache name="entity" mode="SYNC">
> <transaction mode="NON_XA"/>
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </invalidation-cache>
> <replicated-cache name="timestamps" mode="ASYNC"/>
> </cache-container>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:jaxrs:1.0"/>
> <subsystem xmlns="urn:jboss:domain:jca:4.0">
> <archive-validation enabled="true" fail-on-error="true" fail-on-warn="false"/>
> <bean-validation enabled="true"/>
> <default-workmanager>
> <short-running-threads>
> <core-threads count="50"/>
> <queue-length count="50"/>
> <max-threads count="50"/>
> <keepalive-time time="10" unit="seconds"/>
> </short-running-threads>
> <long-running-threads>
> <core-threads count="50"/>
> <queue-length count="50"/>
> <max-threads count="50"/>
> <keepalive-time time="10" unit="seconds"/>
> </long-running-threads>
> </default-workmanager>
> <cached-connection-manager/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:jdr:1.0"/>
> <subsystem xmlns="urn:jboss:domain:jgroups:4.0">
> <channels default="ee">
> <channel name="ee" stack="udp"/>
> </channels>
> <stacks>
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> </stack>
> </stacks>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
> <expose-resolved-model/>
> <expose-expression-model/>
> <remoting-connector/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:jpa:1.1">
> <jpa default-datasource="" default-extended-persistence-inheritance="DEEP"/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:jsf:1.0"/>
> <subsystem xmlns="urn:jboss:domain:mail:2.0">
> <mail-session name="default" jndi-name="java:jboss/mail/Default">
> <smtp-server outbound-socket-binding-ref="mail-smtp"/>
> </mail-session>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:naming:2.0">
> <remote-naming/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:pojo:1.0"/>
> <subsystem xmlns="urn:jboss:domain:remoting:3.0">
> <endpoint/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:resource-adapters:4.0"/>
> <subsystem xmlns="urn:jboss:domain:request-controller:1.0"/>
> <subsystem xmlns="urn:jboss:domain:sar:1.0"/>
> <subsystem xmlns="urn:jboss:domain:security-manager:1.0">
> <deployment-permissions>
> <maximum-set>
> <permission class="java.security.AllPermission"/>
> </maximum-set>
> </deployment-permissions>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> <security-domain name="other" cache-type="default">
> <authentication>
> <login-module code="Remoting" flag="optional">
> <module-option name="password-stacking" value="useFirstPass"/>
> </login-module>
> <login-module code="RealmDirect" flag="required">
> <module-option name="password-stacking" value="useFirstPass"/>
> </login-module>
> </authentication>
> </security-domain>
> <security-domain name="jboss-web-policy" cache-type="default">
> <authorization>
> <policy-module code="Delegating" flag="required"/>
> </authorization>
> </security-domain>
> <security-domain name="jboss-ejb-policy" cache-type="default">
> <authorization>
> <policy-module code="Delegating" flag="required"/>
> </authorization>
> </security-domain>
> <security-domain name="jaspitest" cache-type="default">
> <authentication-jaspi>
> <login-module-stack name="dummy">
> <login-module code="Dummy" flag="optional"/>
> </login-module-stack>
> <auth-module code="Dummy"/>
> </authentication-jaspi>
> </security-domain>
> </security-domains>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:singleton:1.0">
> <singleton-policies default="default">
> <singleton-policy name="default" cache-container="server">
> <simple-election-policy/>
> </singleton-policy>
> </singleton-policies>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:transactions:3.0">
> <core-environment>
> <process-id>
> <uuid/>
> </process-id>
> </core-environment>
> <recovery-environment socket-binding="txn-recovery-environment" status-socket-binding="txn-status-manager"/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:undertow:3.1">
> <buffer-cache name="default"/>
> <server name="default-server">
> <ajp-listener name="ajp" socket-binding="ajp"/>
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> <servlet-container name="default">
> <jsp-config/>
> <websockets/>
> </servlet-container>
> <handlers>
> <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
> </handlers>
> <filters>
> <response-header name="server-header" header-name="Server" header-value="JBoss-EAP/7"/>
> <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
> </filters>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:webservices:2.0">
> <wsdl-host>${jboss.bind.address:127.0.0.1}</wsdl-host>
> <endpoint-config name="Standard-Endpoint-Config"/>
> <endpoint-config name="Recording-Endpoint-Config">
> <pre-handler-chain name="recording-handlers" protocol-bindings="##SOAP11_HTTP ##SOAP11_HTTP_MTOM ##SOAP12_HTTP ##SOAP12_HTTP_MTOM">
> <handler name="RecordingHandler" class="org.jboss.ws.common.invocation.RecordingServerHandler"/>
> </pre-handler-chain>
> </endpoint-config>
> <client-config name="Standard-Client-Config"/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:weld:3.0"/>
> </profile>
> <interfaces>
> <interface name="management">
> <inet-address value="192.168.124.246"/>
> </interface>
> <interface name="public">
> <inet-address value="192.168.124.246"/>
> </interface>
> <interface name="private">
> <inet-address value="192.168.124.246"/>
> </interface>
> </interfaces>
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:101}">
> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> <socket-binding name="https" port="${jboss.https.port:8443}"/>
> <socket-binding name="jgroups-mping" interface="private" port="0" multicast-address="230.0.0.4" multicast-port="45700"/>
> <socket-binding name="jgroups-tcp" interface="private" port="7600"/>
> <socket-binding name="jgroups-tcp-fd" interface="private" port="57600"/>
> <socket-binding name="jgroups-udp" interface="private" port="55200" multicast-address="230.0.0.4" multicast-port="45688"/>
> <socket-binding name="jgroups-udp-fd" interface="private" port="54200"/>
> <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/>
> <socket-binding name="txn-recovery-environment" port="4712"/>
> <socket-binding name="txn-status-manager" port="4713"/>
> <outbound-socket-binding name="mail-smtp">
> <remote-destination host="localhost" port="25"/>
> </outbound-socket-binding>
> </socket-binding-group>
> </server>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGMGR-139) Add maxBackupIndex to periodic-rotating-file-handlers
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-139?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-139:
--------------------------------------
The trick is given the file name {{server.log.20161606}} how do you get {{20161606}} back into a date format? It's possible you could assume the current {{suffix}} would be the date format, but now there's potential to miss purging files. For example say you get 5 days of log files and shutdown the server every Friday and restart it Monday. If you just take {{current_date - 5 days}} then you'd always miss purging Monday and Tuesdays log files.
What I meant more by OS tools was using a cron job to delete files older than x days. For example
{code}
find ${JBOSS_HOME}/standalone/log -name "server.log.*" -mtime +5 | xargs -I {} rm "{}"
{code}
Given the configuration that should only rotate when the file reaches 1GB in size and keep 1 back up. So you should only ever have {{server.log}} and {{server.log.1}}. If it's got a date pattern suffix then something else is rotating the file.
> Add maxBackupIndex to periodic-rotating-file-handlers
> -----------------------------------------------------
>
> Key: LOGMGR-139
> URL: https://issues.jboss.org/browse/LOGMGR-139
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Reporter: Rémy Garrigue
> Priority: Minor
>
> That's all in the title.
> We would like to have a daily log, keeping 15 days of log. Actually there's no way to do that except maybe custom handler which we can't get to work. That'ld be far easier if there was the same maxBackupIndex option as in size rotating handler.
> Regards,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGMGR-139) Add maxBackupIndex to periodic-rotating-file-handlers
by Rémy Garrigue (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-139?page=com.atlassian.jira.plugin... ]
Rémy Garrigue commented on LOGMGR-139:
--------------------------------------
Sorry for the lack of accuracy : I'm working on Wildfly, from v7 onward.
I don't see the difficulty about the rotating & removing. Linux's logrotated is doing that fine : take files matching name+date format, order them by time, remove index > maxBackupIndex. Truth is I dunno what logrotate would do if I drop a file with a name matching the pattern, but I guess that would be my bad.
I tried OS tool, namely logrotate. Problem is, Wildfly keeps its file descriptor open, hence keep writing on renamed log. For example if server.log got renamed server.log.20161606 and a new server.log is created by logrotated, new log still go in server.log.20161606. The best I could think about is adding a postrotate bloc which will call jboss-cli to change-file unto server.log. That works.
For the custom handler, I tried something like this (not at work atm, can't c/c the one I tried). It simply didn't worked, after 2 days I ended up with 3 log files (current, day+1 day+2) when my max backup is 1
{code:java}
<size-rotating-file-handler name="FILE">
<formatter>
<pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
</formatter>
<file relative-to="jboss.server.log.dir" path="server.log"/>
<rotate-size value="1000000000"/>
<max-backup-index value="1"/>
<append value="true"/>
</size-rotating-file-handler>
{code}
> Add maxBackupIndex to periodic-rotating-file-handlers
> -----------------------------------------------------
>
> Key: LOGMGR-139
> URL: https://issues.jboss.org/browse/LOGMGR-139
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Reporter: Rémy Garrigue
> Priority: Minor
>
> That's all in the title.
> We would like to have a daily log, keeping 15 days of log. Actually there's no way to do that except maybe custom handler which we can't get to work. That'ld be far easier if there was the same maxBackupIndex option as in size rotating handler.
> Regards,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5537) Singleton EJBs with multiple views does not honor Lock semantics
by Yeray Santana Borges (JIRA)
[ https://issues.jboss.org/browse/WFLY-5537?page=com.atlassian.jira.plugin.... ]
Yeray Santana Borges commented on WFLY-5537:
--------------------------------------------
I have been working in this issue, I haven't finished yet because before create a PR, I would like to get some feedback from someone with more knowledge in this module.
Following the description from [~nmoelholm] and based on my tests and code checks, the problem is that there is that ContainerManagedConcurrencyInterceptor only knows about the mapping methods of a single view.
Mapping methods are stored in viewMethodToComponentMethodMap variable in ContainerManagedConcurrencyInterceptor:51.
Since the interceptor has just one map, if the method invoked belongs to a view different than the one which has initialized the viewMethodToComponentMethodMap for the current ContainerManagedConcurrencyInterceptor intance, then the server gets the wrong type in SingletonComponent:159, because the method name used is not mapped in the viewMethodToComponentMethodMap.
So, it seems it is needed an access to all existing viewMethodToComponentMethodMap created for each view in ContainerManagedConcurrencyInterceptor.
How?, I have used the own SingletonComponent to store them as proposal, but it looks a little hack from my point of view.
With that fix, ContainerManagedConcurrencyInterceptor is able always to found any method mapping and the problem for the wrong Lock is resolved.
SingletonComponent instance is created once all views has been already initialized, each view with its own copy of viewMethodToComponentMethodMap.
My question is, does it seem to be quite hacking to use the SingletonComponent for that purposed? If this approach is incorrect, any suggestions?
The changes are not finished yet, if the proposal is correct, then the instance variable viewMethodToComponentMethodMap is not longer needed in the interceptor because using the SingletonComponent, the interceptor can access to the viewMethodToComponentMethodMap of each view and then avoid the locking problem.
Changes are available in this topic branch: https://github.com/yersan/wildfly/tree/bugs/WFLY-5537
> Singleton EJBs with multiple views does not honor Lock semantics
> ----------------------------------------------------------------
>
> Key: WFLY-5537
> URL: https://issues.jboss.org/browse/WFLY-5537
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.CR2
> Environment: 10.0.0.CR2
> Reporter: Nicky Mølholm
> Labels: ejb, interceptor, singleton
>
> Upon method invocations to Singleton EJBs with multiple views... the *ContainerManagedConcurrencyInterceptor* randomly selects a wrong Lock (READ / WRITE).
> Here is an example:
> {code:java}
> @Singleton
> @Lock(LockType.READ)
> @Local({ GreeterSayMyName.class, GreeterSayHello.class })
> public class GreeterBean implements GreeterSayMyName, GreeterSayHello {
> @EJB
> GreeterSayMyName myself;
> @Override
> public String sayHello() {
> return "hello from " + myself.sayMyName();
> }
> @Override
> public String sayMyName() {
> return "The Greeter";
> }
> }
> public interface GreeterSayHello {
>
> String sayHello();
>
> }
> public interface GreeterSayMyName {
> String sayMyName();
> }
> {code}
> Sometimes (randomly) invoking the 'sayHello' method on this example EJB causes lock upgrade exceptions. They look like this:
> {noformat}
> 13:14:10,436 ERROR [f2PtkwmdRgaoHCdnZ7Vurg] [anonymous] [org.jboss.as.ejb3.invocation] (default task-5 f2PtkwmdRgaoHCdnZ7Vurg) WFLYEJB0034: EJB Invocation failed on component GreeterBean for method public abstract java.lang.String hello.world.GreeterSayHello.sayHello(): javax.ejb.IllegalLoopbackException: WFLYEJB0238: EJB 3.1 PFD2 4.8.5.1.1 upgrading from read to write lock is not allowed
> at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.checkLoopback(EJBReadWriteLock.java:232)
> at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.access$300(EJBReadWriteLock.java:40)
> {noformat}
> This happens completely randomly.
> The problem is that the interceptor only knows about one of the views' methods. At deployment time the ViewService will start the views concurrently - and the interceptorfactory only adds an interceptor instance to the interceptor context if one does not already exist.
> When the exception does NOT occur -then there is still a problem (although not visible from the code): A WRITE lock is selected - even though , given the above code, it should never ever be possible. So in fact - the issue , in that case, does not cause an exception because .... it already has the WRITE lock.
> ( When the exception occurs ...then it is because the sayHello() invocation resulted in a READ lock ... and the reentrant invocation caused a WRITE lock to be selected by the interceptor ... but as this is not allowed, it results in a horrible exception )
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6732) IllegalStateException in ApplicationSecurityDomainService#initialSecurityHandler when loginConfig is null
by Farah Juma (JIRA)
Farah Juma created WFLY-6732:
--------------------------------
Summary: IllegalStateException in ApplicationSecurityDomainService#initialSecurityHandler when loginConfig is null
Key: WFLY-6732
URL: https://issues.jboss.org/browse/WFLY-6732
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Farah Juma
Assignee: Farah Juma
Fix For: 11.0.0.Alpha1
The following IllegalStateException occurs when attempting to deploy an application that doesn't specify the {{login-config}}:
{code}
java.lang.IllegalStateException: WFLYUT0084: No authentication mechanisms have been selected.
at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:345)
at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:295)
at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:400)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:204)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6732) IllegalStateException in ApplicationSecurityDomainService#initialSecurityHandler when loginConfig is null
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-6732?page=com.atlassian.jira.plugin.... ]
Farah Juma updated WFLY-6732:
-----------------------------
Labels: affects_elytron (was: )
> IllegalStateException in ApplicationSecurityDomainService#initialSecurityHandler when loginConfig is null
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6732
> URL: https://issues.jboss.org/browse/WFLY-6732
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Farah Juma
> Labels: affects_elytron
> Fix For: 11.0.0.Alpha1
>
>
> The following IllegalStateException occurs when attempting to deploy an application that doesn't specify the {{login-config}}:
> {code}
> java.lang.IllegalStateException: WFLYUT0084: No authentication mechanisms have been selected.
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:345)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:295)
> at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:400)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:204)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ELY-575) NPE in AbstractMechanismAuthenticationFactory
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-575?page=com.atlassian.jira.plugin.sy... ]
David Lloyd resolved ELY-575.
-----------------------------
Resolution: Done
> NPE in AbstractMechanismAuthenticationFactory
> ---------------------------------------------
>
> Key: ELY-575
> URL: https://issues.jboss.org/browse/ELY-575
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms, SASL
> Reporter: David Lloyd
> Assignee: David Lloyd
>
> The SaslAuthenticationFactory sublcass of AbstractMechanismAuthenticationFactory is using org.wildfly.security.sasl.util.SaslMechanismInformation#getSupportedServerCredentialTypes() to determine what credentials are available. But, that method returns null if nothing is known about that mechanism name. AbstractMechanismAuthenticationFactory doesn't check for null in the returned collection, and so NPE results which is uncaught and can cause hangs and other problems.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years