September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2080 at 9/1/16 5:48 AM: -------------------------------------------------------- Hmm... we could also start from the other end and add 'randomness' to an {{IpAddress}}; rather than encoding the IP address and port in the UUID, we could add a 16 byte (or smaller) UUID to {{IpAddress}}. The reason we abandoned IpAddress a long time ago is that - if the port was fixed - we could run into _reincarnation issues_: a member with address {{192.168.1.3:5000}} crashing and immediately restarting would have the same address {{192.168.1.3:5000}} but still have state from old members (e.g. in {{NAKACK2}}). Since the combination of IP address and port is pretty unique, we'd only have to add a small amount of randomness (perhaps even configurable) to an {{IpAddress}}. Currently, {{IpAddress}} uses 20 bytes in memory (JOL) and loses 4 due to mapping, so we could use 12 bytes for randomness. The advantages of this over encoding the IP address in a UUID are: * To extract an {{IpAddress}} from a UUID when sending a message, we'd need to create a new {{IpAddress}} instance for every message (high allocation rate). When adding some randomness to {{IpAddress}}, we can directly use those * Encoding an IPv4 address in a UUID takes 6 bytes (4 for the address and 2 for the port), so we have 10 bytes left for randomness in the UUID. For IPv6, the required size is 18 bytes, so we'd need to make the UUID larger to have enough randomness. With the extension scheme, {{IpAddress}} would always contain the same amount of randomness. * No hashmap lookup from address to physical address would have to be done Disadvantages: * Addresses get bigger, both on the wire and in memory was (Author: belaban): Hmm... we could also start from the other end and add 'randomness' to an {{IpAddress}}; rather than encoding the IP address and port in the UUID, we could add a 16 byte (or smaller) UUID to {{IpAddress}}. The reason we abandoned IpAddress a long time ago is that - if the port was fixed - we could run into _reincarnation issues_: a member with address {{192.168.1.3:5000}} crashing and immediately restarting would have the same address {{192.168.1.3:5000}} but still have state from old members (e.g. in {{NAKACK2}}). Since the combination of IP address and port is pretty unique, we'd only have to add a small amount of randomness (perhaps even configurable) to an {{IpAddress}}. Currently, {{IpAddress}} uses 20 bytes in memory (JOL) and loses 4 due to mapping, so we could use 12 bytes for randomness. The advantages of this over encoding the IP address in a UUID are: * To extract an {{IpAddress}} from a UUID when sending a message, we'd need to create a new {{IpAddress}} instance for every message (high allocation rate). When adding some randomness to {{IpAddress}}, we can directly use those * Encoding an IPv4 address in a UUID takes 6 bytes (4 for the address and 2 for the port), so we have 10 bytes left for randomness in the UUID. For IPv6, the required size is 18 bytes, so we'd need to make the UUID larger to have enough randomness. With the extension scheme, {{IpAddress}} would always contain the same amount of randomness. > New Address which contains IP address and port > ---------------------------------------------- > > Key: JGRP-2080 > URL: https://issues.jboss.org/browse/JGRP-2080 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol. > If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings. > An {{IPv4UUID}} (credits to Neal Dillman) would look like this: > * 4 bytes: IPv4 address > * 2 bytes: port > * 12 bytes: random data (rest of the UUID) > When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too. > When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately. > An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

by Bela Ban (JIRA)

Bela Ban created JGRP-2098: ------------------------------ Summary: Discovery: reduce messages when IpAddressUUID is used Key: JGRP-2098 URL: https://issues.jboss.org/browse/JGRP-2098 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0 Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase. Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID. Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7029) RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7029?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-7029: -------------------------------------- Possible cause https://github.com/infinispan/infinispan/pull/3805/commits/f8039053d6d76e... > RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations." > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7029 > URL: https://issues.jboss.org/browse/WFLY-7029 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > > https://ci.wildfly.org/viewLog.html?buildId=24851&tab=buildResultsDiv&bui... > {noformat} > 04:31:43,323 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0, timeout=15 > 04:31:43,324 INFO [org.jboss.as.arquillian.container.controller.ClientWildFlyContainerController] (main) Manual stopping of a server instance with timeout=15 > &amp#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout. > &amp#27;[0m04:31:43,343 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-10) Retrying invocation which failed on node node-0 with exception:: javax.ejb.NoSuchEJBException: No such EJB[appname=,modulename=remote-failover-test,distinctname=,beanname=SlowToDestroyStatefulIncrementorBean,viewclassname=org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor] > at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64) > at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:386) > at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:498) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &amp#27;[0m&amp#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &amp#27;[0m&amp#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown > &amp#27;[0m&amp#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server > &amp#27;[0m&amp#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server > &amp#27;[0m&amp#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk > &amp#27;[0m&amp#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web > &amp#27;[0m&amp#27;[0m04:31:43,502 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence > &amp#27;[0m&amp#27;[33m04:31:43,502 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (thread-11,ee,node-0) ISPN000071: Caught exception when handling command LockControlCommand{cache=remote-failover-test.jar, keys=[UnknownSessionID [6951504948515351686656515249505365655750686851525048706670486766]], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTransaction:<node-1>:48:remote}: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > 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:380) > 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.pbcast.GMS.up(GMS.java:1040) > 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.up(FD.java:260) > 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.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > 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) > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &amp#27;[0m&amp#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > &amp#27;[0m&amp#27;[0m04:31:43,535 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &amp#27;[0m&amp#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container > &amp#27;[0m04:31:43,565 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-14) EJBCLIENT000016: Channel Channel ID b007a55b (outbound) of Remoting connection 017c35ab to /0:0:0:0:0:0:0:1:8080 of endpoint "config-based-ejb-client-endpoint" <1c33eee> can no longer process messages > &amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [::1]:8009 > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [::1]:8443 > &amp#27;[0m&amp#27;[31m04:31:43,585 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-11) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-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:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > 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.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > 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:380) > 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.pbcast.GMS.up(GMS.java:1040) > 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.up(FD.java:260) > 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.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > 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) > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > &amp#27;[0m&amp#27;[31m04:31:43,588 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component SlowToDestroyStatefulIncrementorBean for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-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:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > 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.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > 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:380) > 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.pbcast.GMS.up(GMS.java:1040) > 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.up(FD.java:260) > 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.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > 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) > ... 1 more > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2080 at 9/1/16 5:12 AM: -------------------------------------------------------- We also need to look at whether local_addr is set correctly in ForkChannels. UPDATE: yes, this is correct: local_addr is set on ForkChannel.connect() was (Author: belaban): We also need to look at whether local_addr is set correctly in ForkChannels > New Address which contains IP address and port > ---------------------------------------------- > > Key: JGRP-2080 > URL: https://issues.jboss.org/browse/JGRP-2080 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol. > If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings. > An {{IPv4UUID}} (credits to Neal Dillman) would look like this: > * 4 bytes: IPv4 address > * 2 bytes: port > * 12 bytes: random data (rest of the UUID) > When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too. > When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately. > An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1682: ---------------------------------------------- Yes, this problem has been fixed. > Missleading tab completion for edit-batch-line command > ------------------------------------------------------ > > Key: WFCORE-1682 > URL: https://issues.jboss.org/browse/WFCORE-1682 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Petr Kremensky > Assignee: Jean-Francois Denise > > Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works. > *command usage* > {noformat} > [standalone@localhost:9990 /] batch > [standalone@localhost:9990 / #] :read-resource > [standalone@localhost:9990 / #] list-batch > #1 /:read-resource > [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type) > #1 :read-attribute(name=launch-type) > [standalone@localhost:9990 / #] list-batch > #1 :read-attribute(name=launch-type) > {noformat} > *actual* > {noformat} > [standalone@localhost:9990 / #] edit-batch-line <TAB> > [standalone@localhost:9990 / #] edit-batch-line --<TAB> > --help --line-number > [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type) > Failed to parse line number '--line-number=1': For input string: "--line-number=1" > {noformat} > {{--line-number}} shouldn't be offered by tab completion for the command. > Misleading tab completion ends up with syntax error. > *expected* > {noformat} > [standalone@localhost:9990 / #] edit-batch-line <TAB> > --help > {noformat} > The issue is a regression against EAP 7.0.0 release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3915) Dynamic configuration of outbound SSL connections

by Mayurapriyan Sivaraman (JIRA)

[ https://issues.jboss.org/browse/WFLY-3915?page=com.atlassian.jira.plugin.... ] Mayurapriyan Sivaraman commented on WFLY-3915: ---------------------------------------------- I was exactly looking for this feature. Do anyone know of alternative configuration for this feature in jboss EAP ? > Dynamic configuration of outbound SSL connections > ------------------------------------------------- > > Key: WFLY-3915 > URL: https://issues.jboss.org/browse/WFLY-3915 > Project: WildFly > Issue Type: Feature Request > Reporter: James Livingston > Assignee: Jason Greene > > WebSphere has a feature called "Dynamic outbound SSL configuration" (http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websph...), which allows the configuration of SSL parameters for connections which are not opened directly by the container. > That can be useful for configuring the SSL usage of components such as resource adapters, JDBC drivers, and application-packaged web service libraries. For example the truststore/keystore could be configured different for all requests to the database host, so that the global javax.net.ssl settings to not need to be modified if the driver does not itself provide a way to configure it. > I believe that it is implemented by using javax.net.ssl.SSLContext.setDefault() to replace the standard socket factory. The socket factory could then look at the passed hostname/port, and potentially the calling application to configure the SSL socket appropriately before returning it to the caller. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1708) ReconnectSyslogServerTestCase from wf-core fails intermittently

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1708?page=com.atlassian.jira.plugi... ] Ondrej Lukas reopened WFCORE-1708: ---------------------------------- Still fails on Solaris. See JBEAP-5564 for details. > ReconnectSyslogServerTestCase from wf-core fails intermittently > --------------------------------------------------------------- > > Key: WFCORE-1708 > URL: https://issues.jboss.org/browse/WFCORE-1708 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 3.0.0.Alpha4 > Reporter: Ondrej Lukas > Assignee: Ondrej Lukas > Fix For: 3.0.0.Alpha5 > > > *Description of problem:* > ReconnectSyslogServerTestCase from wf-core fails intermittently. > *How reproducible:* > 2% > *Actual results:* > Stacktrace: > {noformat} > java.lang.AssertionError: No message was logged into the TCP syslog after second syslog server restart > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertNotNull(Assert.java:712) > at org.jboss.as.test.manualmode.logging.ReconnectSyslogServerTestCase.testReconnectSyslogServer(ReconnectSyslogServerTestCase.java:118) > {noformat} > Standard Output: > {noformat} > 10:59:13,639 INFO [org.wildfly.core.testrunner.Server] (main) Starting container with: /qa/tools/opt/x86_64/jdk1.8.0_91/jre/bin/java -D[Standalone] -javaagent:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/eap-local-maven-repository/org/jboss/byteman/byteman/3.0.3/byteman-3.0.3.jar=port:9091,boot:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/eap-local-maven-repository/org/jboss/byteman/byteman/3.0.3/byteman-3.0.3.jar,sys:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/shared/target/wildfly-core-testsuite-shared-3.0.0.Alpha4-redhat-1.jar -Dorg.jboss.byteman.transform.all -Dorg.jboss.byteman.verbose=true -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/eap-local-maven-repository -Xmx512m -XX:MaxMetaspaceSize=256m -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv6Addresses=false -server -Dts.timeout.factor=100 -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode -ea -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/log/server.log -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/configuration/logging.properties -jar /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/jboss-modules.jar -mp /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/modules org.jboss.as.standalone -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/log -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/configuration -c=standalone.xml -bmanagement=10.16.180.146 -Djboss.http.port=8080 -Djboss.bind.address=10.16.180.146 > 10:59:13,849 INFO [org.xnio] (main) XNIO version 3.4.0.Beta2 > 10:59:13,950 INFO [org.xnio.nio] (main) XNIO NIO Implementation Version 3.4.0.Beta2 > TransformListener() : accepting requests on localhost:9091 > 10:59:14,238 INFO [org.jboss.remoting] (main) JBoss Remoting version 4.0.21.Final-redhat-1 > &amp#27;[0m10:59:15,448 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final-redhat-1 > &amp#27;[0m&amp#27;[0m10:59:16,071 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final-redhat-1 > &amp#27;[0m&amp#27;[0m10:59:16,385 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 3.0.0.Alpha4-redhat-1 "Kenny" starting > &amp#27;[0m&amp#27;[0m10:59:17,878 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &amp#27;[0m&amp#27;[0m10:59:17,983 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.0.Beta2 > &amp#27;[0m&amp#27;[0m10:59:18,004 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.0.Beta2 > &amp#27;[0m&amp#27;[0m10:59:18,144 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none > &amp#27;[0m&amp#27;[0m10:59:18,180 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 4.0.21.Final-redhat-1 > &amp#27;[0m&amp#27;[33m10:59:18,208 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &amp#27;[0m&amp#27;[33m10:59:18,352 WARN [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-1) WFLYDMHTTP0003: Unable to load console module for slot main, disabling console > &amp#27;[0m&amp#27;[0m10:59:18,924 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://10.16.180.146:9990/management > &amp#27;[0m&amp#27;[0m10:59:18,925 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://10.16.180.146:9990 > &amp#27;[0m&amp#27;[0m10:59:18,925 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha4-redhat-1 "Kenny" started in 4551ms - Started 59 of 62 services (20 services are lazy, passive or on-demand) > &amp#27;[0m&amp#27;[0m10:59:19,841 INFO [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/data/content/b6/795345f1851ba393f4f56dcd0e08328efcc090/content > &amp#27;[0m&amp#27;[0m10:59:19,880 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "logging-test.jar" (runtime-name: "logging-test.jar") > &amp#27;[0m&amp#27;[0m10:59:20,076 INFO [org.wildfly.test.undertow.UndertowService] (MSC service thread 1-2) Started Undertow on 10.16.180.146:8080 > &amp#27;[0m&amp#27;[0m10:59:20,131 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "logging-test.jar" (runtime-name : "logging-test.jar") > &amp#27;[0m&amp#27;[0m10:59:27,185 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-1) someLogMessage > &amp#27;[0m10:59:27,739 WARN [org.jboss.as.test.syslogserver.UDPSyslogServer] (SyslogServer: udp) SocketException occurred: java.net.SocketException: Socket closed > at java.net.PlainDatagramSocketImpl.receive0(Native Method) > at java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143) > at java.net.DatagramSocket.receive(DatagramSocket.java:812) > at org.jboss.as.test.syslogserver.UDPSyslogServer.run(UDPSyslogServer.java:62) > at java.lang.Thread.run(Thread.java:745) > 10:59:28,239 ERROR [org.jboss.as.test.syslogserver.TCPSyslogServer] (SyslogServer: tcp) IOException occurred.: java.net.SocketException: Socket closed > at java.net.PlainSocketImpl.socketAccept(Native Method) > at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409) > at java.net.ServerSocket.implAccept(ServerSocket.java:545) > at java.net.ServerSocket.accept(ServerSocket.java:513) > at org.jboss.as.test.syslogserver.TCPSyslogServer.run(TCPSyslogServer.java:55) > at java.lang.Thread.run(Thread.java:745) > 10:59:28,241 WARN [org.jboss.as.test.syslogserver.TCPSyslogSocketHandler] (Thread-6) IOException occurred: java.net.SocketException: Socket closed > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) > at java.net.SocketInputStream.read(SocketInputStream.java:170) > at java.net.SocketInputStream.read(SocketInputStream.java:141) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > at java.io.BufferedInputStream.read(BufferedInputStream.java:265) > at org.jboss.as.test.syslogserver.TCPSyslogSocketHandler.run(TCPSyslogSocketHandler.java:73) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m10:59:28,255 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-1) someLogMessage > &amp#27;[0mLogManager error of type WRITE_FAILURE: Error writing to TCP stream > java.net.SocketException: Broken pipe > at java.net.SocketOutputStream.socketWrite0(Native Method) > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) > at java.net.SocketOutputStream.write(SocketOutputStream.java:153) > at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182) > at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:173) > at org.jboss.logmanager.handlers.SyslogHandler.sendMessage(SyslogHandler.java:579) > at org.jboss.logmanager.handlers.SyslogHandler.doPublish(SyslogHandler.java:540) > at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322) > at org.jboss.logmanager.Logger.logRaw(Logger.java:850) > at org.jboss.logmanager.Logger.log(Logger.java:802) > at org.jboss.logmanager.Logger.log(Logger.java:814) > at org.jboss.logging.JBossLogManagerLogger.doLog(JBossLogManagerLogger.java:42) > at org.jboss.logging.Logger.info(Logger.java:955) > at org.jboss.as.test.manualmode.logging.LoggingServiceActivator$1.handleRequest(LoggingServiceActivator.java:50) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:233) > at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:131) > at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:57) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:565) > &amp#27;[0m10:59:28,263 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-2) someLogMessage > &amp#27;[0m&amp#27;[0m10:59:36,291 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-1) someLogMessage > &amp#27;[0m10:59:36,794 WARN [org.jboss.as.test.syslogserver.UDPSyslogServer] (SyslogServer: udp) SocketException occurred: java.net.SocketException: Socket closed > at java.net.PlainDatagramSocketImpl.receive0(Native Method) > at java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143) > at java.net.DatagramSocket.receive(DatagramSocket.java:812) > at org.jboss.as.test.syslogserver.UDPSyslogServer.run(UDPSyslogServer.java:62) > at java.lang.Thread.run(Thread.java:745) > 10:59:37,295 ERROR [org.jboss.as.test.syslogserver.TCPSyslogServer] (SyslogServer: tcp) IOException occurred.: java.net.SocketException: Socket closed > at java.net.PlainSocketImpl.socketAccept(Native Method) > at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409) > at java.net.ServerSocket.implAccept(ServerSocket.java:545) > at java.net.ServerSocket.accept(ServerSocket.java:513) > at org.jboss.as.test.syslogserver.TCPSyslogServer.run(TCPSyslogServer.java:55) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m10:59:37,298 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-2) someLogMessage > &amp#27;[0m&amp#27;[0m10:59:37,310 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-1) someLogMessage > &amp#27;[0m10:59:37,313 ERROR [org.jboss.as.test.syslogserver.Rfc5424SyslogEvent] (Thread-9) Can't parse priority > 10:59:37,313 WARN [org.jboss.as.test.syslogserver.TCPSyslogSocketHandler] (Thread-9) IOException occurred: java.net.SocketException: Socket closed > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) > at java.net.SocketInputStream.read(SocketInputStream.java:170) > at java.net.SocketInputStream.read(SocketInputStream.java:141) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > at java.io.BufferedInputStream.read(BufferedInputStream.java:265) > at org.jboss.as.test.syslogserver.TCPSyslogSocketHandler.run(TCPSyslogSocketHandler.java:73) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m10:59:45,316 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-2) someLogMessage > &amp#27;[0m10:59:50,955 WARN [org.jboss.as.test.syslogserver.UDPSyslogServer] (SyslogServer: udp) SocketException occurred: java.net.SocketException: Socket closed > at java.net.PlainDatagramSocketImpl.receive0(Native Method) > at java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143) > at java.net.DatagramSocket.receive(DatagramSocket.java:812) > at org.jboss.as.test.syslogserver.UDPSyslogServer.run(UDPSyslogServer.java:62) > at java.lang.Thread.run(Thread.java:745) > 10:59:51,456 ERROR [org.jboss.as.test.syslogserver.TCPSyslogServer] (SyslogServer: tcp) IOException occurred.: java.net.SocketException: Socket closed > at java.net.PlainSocketImpl.socketAccept(Native Method) > at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409) > at java.net.ServerSocket.implAccept(ServerSocket.java:545) > at java.net.ServerSocket.accept(ServerSocket.java:513) > at org.jboss.as.test.syslogserver.TCPSyslogServer.run(TCPSyslogServer.java:55) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m10:59:51,517 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment logging-test.jar (runtime-name: logging-test.jar) in 17ms > &amp#27;[0m&amp#27;[33m10:59:51,525 WARN [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type deployment-undeployed is not described for the resource at the address [] > &amp#27;[0m&amp#27;[0m10:59:51,527 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/data/content/b6/795345f1851ba393f4f56dcd0e08328efcc090/content > &amp#27;[0m&amp#27;[0m10:59:51,528 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "logging-test.jar" (runtime-name: "logging-test.jar") > &amp#27;[0m&amp#27;[0m10:59:51,549 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0236: Suspending server with no timeout. > &amp#27;[0m&amp#27;[0m10:59:51,552 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &amp#27;[0m&amp#27;[0m10:59:51,704 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Core 3.0.0.Alpha4-redhat-1 "Kenny" stopped in 97ms > &amp#27;[0m > {noformat} > Standard Error Output: > {noformat} > Exception in thread "Thread-13" java.lang.NullPointerException > at org.wildfly.core.testrunner.Server.lambda$stop$0(Server.java:184) > at java.lang.Thread.run(Thread.java:745) > {noformat} > *Expected results:* > No errors > *Additional info:* > Links to jenkins reports: > * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T... > * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-91) Review use of Locale in toLowerCase() calls

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-91?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFCORE-91: ----------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Review use of Locale in toLowerCase() calls > ------------------------------------------- > > Key: WFCORE-91 > URL: https://issues.jboss.org/browse/WFCORE-91 > Project: WildFly Core > Issue Type: Task > Components: CLI, Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha7 > > > There are places where we are converting strings to lower case without specifying Locale.ENGLISH. Some of these may be fine, but some are not and they should all be reviewed: > {code} > $ git grep "toLowerCase()" > cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase()); > cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase()); > controller/src/main/java/org/jboss/as/controller/operations/global/ReadResourceDescriptionHandler.java: final AccessControl value = localName != null ? MAP.get(local > core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase(); > core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase(); > core-model-test/tests/src/test/java/org/jboss/as/core/model/test/standalone/root/StandaloneRootResourceTestCase.java: String hostName = NetworkUtils.canonize(InetAddress > domain-management/src/main/java/org/jboss/as/domain/management/security/adduser/ConfirmationChoice.java: String temp = response.toLowerCase(); // We now need to matc > domain-management/src/test/java/org/jboss/as/domain/management/security/auditlog/AbstractAuditLogHandlerTestCase.java: PathElement.pathElement(PROTOCOL, transpor > host-controller/src/main/java/org/jboss/as/host/controller/DirectoryGrouping.java: final DirectoryGrouping directoryGrouping = localName != null ? MAP.get(localName.toLo > host-controller/src/main/java/org/jboss/as/host/controller/HostControllerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase(); > host-controller/src/main/java/org/jboss/as/host/controller/discovery/S3Util.java: String lk=hashKey.toLowerCase(); > server/src/main/java/org/jboss/as/server/ServerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase(); > testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: super("TestClient-" + id + " (" + type.toString().toLowerCase() + " > testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: this.description = "TestClient-" + id + " (" + type.toString().toLow > testsuite-core/shared/src/main/java/org/jboss/as/test/integration/management/interfaces/JmxInterfaceStringUtils.java: return string.replaceAll(regex, replacement).toLowe > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFCORE-13: ----------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Labels: EAP > Fix For: 3.0.0.Alpha7 > > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-363: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > ManagementResourceRegistration.getOverrideModel never returns null > ------------------------------------------------------------------ > > Key: WFCORE-363 > URL: https://issues.jboss.org/browse/WFCORE-363 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha7 > > > ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct. > The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should. > This bug is the cause of the initial failure of my WFLY-2880 fix. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-311) Better error message if authentication is required to connect to the master but no realm is associated on the slave

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-311?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-311: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Better error message if authentication is required to connect to the master but no realm is associated on the slave > ------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-311 > URL: https://issues.jboss.org/browse/WFCORE-311 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Environment: RH EL 6.3 - JBoss EAP 6.2 > Reporter: Riccardo Benvenuti > Assignee: Brian Stansberry > Priority: Minor > Fix For: 3.0.0.Alpha7 > > > In JBoss 6.2 domain environment if in the host.xml file on the slave is missing the realm in the domain-controller tag as reported below > <domain-controller> > <remote host="10.123.137.200" port="9999"/> > </domain-controller> > we get the following error: > JBoss Bootstrap Environment > JBOSS_HOME: /opt/jboss7/jboss-eap-6.2 > JAVA: /usr/java/jdk1.7.0_51/bin/java > JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true > ========================================================================= > 16:45:58,529 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2 > 16:45:58,746 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller' > [Host Controller] 16:45:59,735 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2 > [Host Controller] 16:45:59,913 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1 > [Host Controller] 16:46:00,023 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) starting > [Host Controller] 16:46:00,991 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.7.GA-redhat-1 > [Host Controller] 16:46:01,010 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.7.GA-redhat-1 > [Host Controller] 16:46:01,033 INFO [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (management) port (9990) securePort (-1) > [Host Controller] 16:46:01,045 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.18.GA-redhat-1 > [Host Controller] 16:46:01,173 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 10.123.137.201:9999 > [Host Controller] 16:46:01,857 ERROR [org.jboss.remoting.remote.connection] (Remoting "testjb7s1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > [Host Controller] 16:46:01,869 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure. > [Host Controller] 16:46:01,891 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report > [Host Controller] JBAS014775: New missing/unsatisfied dependencies: > [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (missing) dependents: [service jboss.server.controller.management.security_realm.ApplicationRealm] > [Host Controller] > [Host Controller] 16:46:01,897 INFO [org.jboss.as.controller] (MSC service thread 1-1) JBAS014774: Service status report > [Host Controller] JBAS014775: New missing/unsatisfied dependencies: > [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (missing) dependents: [service jboss.remoting.authentication_provider.management] > [Host Controller] > [Host Controller] 16:46:01,922 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report > [Host Controller] JBAS014776: Newly corrected services: > [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (no longer required) > [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (no longer required) > [Host Controller] > [Host Controller] 16:46:01,927 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) stopped in 28ms > 16:46:02,245 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99 > 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012016: Shutting down process controller > 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012015: All processes finished; exiting > Adding the realm everything works correctly > <domain-controller> > <remote host="10.123.137.200" port="9999" security-realm="ManagementRealm"/> > </domain-controller> > Maybe a warning message could be useful to find the problem. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-301) Configuration of individual contexts for http management interface.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-301?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-301: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Configuration of individual contexts for http management interface. > ------------------------------------------------------------------- > > Key: WFCORE-301 > URL: https://issues.jboss.org/browse/WFCORE-301 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Alpha7 > > > At the moment all management requests are handled over the '/management' context, we also have a '/console' context to serve up the files for the admin console. > The '/management' context is secured using standard HTTP mechanisms, this decision was taken so that clients could be written in different languages and all they would need to know is how to use standard authentication mechanisms. Due to problems where web browsers could run malicious scripts cross origin resource sharing is completely disabled for this context. > We need to start to open up the handling of cross origin requests for a couple of reasons: - > - Enabling Keycloak SSO support. > - Alternative console distribution options > The '/management' context is going to be retained as-is for legacy clients, possibly even switched off by default. > A new context can then be added using non-browser based authentication, this could be SSO Keycloak or could be a form of Digest authentication where the response is handled by the console and not the web browser - either way as the browser is bypassed it is no longer at risk of sending malicious cross origin requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-273: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFCORE-273 > URL: https://issues.jboss.org/browse/WFCORE-273 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Ken Wills > Fix For: 3.0.0.Alpha7 > > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-234) Inconsistent synchronization in ConfigurationFile

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-234?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-234: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Inconsistent synchronization in ConfigurationFile > ------------------------------------------------- > > Key: WFCORE-234 > URL: https://issues.jboss.org/browse/WFCORE-234 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha7 > > > ConfigurationFile synchronizes on itself in some places and not in others. This may cause problems, particularly with the history dir. > The one that comes to mind is successfulBoot is synchronized, but all the methods called by ConfigurationFilePersistenceResource are not. The latter is called with the controller lock held, but the former is not. So there's a possibility of two threads interacting with the files concurrently if an operation executes immediately after boot. > The deployment scanner schedules such an op, so it's possible. Currently the schedule is for 200 ms after deployment-scanner add runs during boot. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-296) Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-296?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-296: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https:// > --------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-296 > URL: https://issues.jboss.org/browse/WFCORE-296 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI, Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > > From [~dmlloyd] > {quote} > When we have multi-layer protocol going on, the URI scheme we should use > is like this: > outer+middle+inner:// > {quote} > Switch URI schemes from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https:// > The existing schemes will be needed for backwards compatibility but somehow deprecated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-610) Integrate Elytron for management security.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-610?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-610: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Integrate Elytron for management security. > ------------------------------------------ > > Key: WFCORE-610 > URL: https://issues.jboss.org/browse/WFCORE-610 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > > This is a top level container task for the integration of Elytron for domain management security. > Do note however that the purpose of Elytron is a single unified security solution across the whole of the application server so many tasks here will be groundwork for the remainder of the integration. > At the moment the Elytron subsystem is being developed outside of wildfly-core, this will need to change in the future due to dependency issues (i.e. to write a subsystem you need to depend on core and core will need to include the subsystem (I think.)). However this will make it easier for now to ensure that the subsystem is 100% with no WildFly code accessing the subsystem - and also verify that we can create a distribtion with out the subsystem and still have a functional server. > Overall if someone came up with an alternative subsystem that provided the same capabilities it should be possible to drop it in. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-406) Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true"

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-406?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-406: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true" > ---------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-406 > URL: https://issues.jboss.org/browse/WFCORE-406 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Environment: FreeBSD, OpenJDK 1.6 > Reporter: Brian Stansberry > Priority: Minor > Fix For: 3.0.0.Alpha7 > > > Some platform mbean getters are documented to throw a UOE on some VMs. The read-resource handler will catch the UOE and leave the attribute undefined, but the description says it's not nillable. > Specifically, PlatformMBeanDescriptions.getThreadingResource()'s THREAD_CPU_TIME_ENABLED attribute, although there may well be others. > This leads to this unit test failure on jvms where the UOE is thrown: > failure message="thread-cpu-time-enabled is undefined" > type="junit.framework.AssertionFailedError">junit.fra mework.AssertionFailedError: thread-cpu-time-enabled is undefined > at junit.framework.Assert.fail(Assert.java:50) > at junit.framework.Assert.assertTrue(Assert.java:20) > at > org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.validateResource(PlatformMBeanResourceUn > itTestCase.java:595) > at org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.basicResourceTest(PlatformMBeanResourceUnitTestCase.java:563) > at > org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.testThreadingMXBean(PlatformMBeanResourceUnitTestCase.java:340) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-710) Make ServerOperationResolver handle deployment-overlays similarly to deployments

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-710?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-710: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Make ServerOperationResolver handle deployment-overlays similarly to deployments > -------------------------------------------------------------------------------- > > Key: WFCORE-710 > URL: https://issues.jboss.org/browse/WFCORE-710 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.Alpha2 > Reporter: Kabir Khan > Fix For: 3.0.0.Alpha7 > > > Currently in domain mode a > {code} > /deployment-overlay=xxx:add(...) > {code} > results in a deployment overlay on ALL servers. > However for deployments > {code} > /deployment=xxx:add(...) > {code} > does not get pushed to the servers. This happens when it is associated with a server group: > {code} > /server-group=zzz/deployment=xxx:add(...) > {code} > Similarly > {code} > /deployment-overlay=xxx:add(...) > {code} > should not get pushed to the servers, until we have a > {code} > /server-group=zzz/deployment=yyy:add(...) > {code} > which picks out the servers we want to have the overlay -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-673) Elytron Integration with Core

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-673?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-673: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Elytron Integration with Core > ----------------------------- > > Key: WFCORE-673 > URL: https://issues.jboss.org/browse/WFCORE-673 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha7 > > > This is the top level tracking task for Elytron integration within core. The tasks for the changes actually being made will either be linked or added as sub-tasks. > In addition to this general issues that affect the Elytron integration are being labelled with 'affects_elytron' and can be queried using the following query: - > https://issues.jboss.org/issues/?filter=12323574 > The label is a general catch-all for issues that are of interest to us but are not automatically blockers for our progress. > The general criteria for the resolution of this issue will be: - > - Inclusion of the Elytron Subsystem in core > - All network entry points in core to be securable using Elytron > - All SSL artefacts to be obtainable from Elytron. > Note: The legacy modes will become better defined as we progress but whilst it must be possible to use Elytron it's use may still be optional to a certain degree. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1006) Upgrade to PicketBox 5

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1006?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1006: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Upgrade to PicketBox 5 > ---------------------- > > Key: WFCORE-1006 > URL: https://issues.jboss.org/browse/WFCORE-1006 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Stefan Guilhen > Fix For: 3.0.0.Alpha7 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-887: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > "Deprecate" using an expression in model refs to interfaces > ----------------------------------------------------------- > > Key: WFCORE-887 > URL: https://issues.jboss.org/browse/WFCORE-887 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha7 > > > SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions. > Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1. > There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support. > We should look for other cases like this too, although those changes should be separate JIRAs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-952) Use WildFly Common for null param checks

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-952?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-952: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Use WildFly Common for null param checks > ---------------------------------------- > > Key: WFCORE-952 > URL: https://issues.jboss.org/browse/WFCORE-952 > Project: WildFly Core > Issue Type: Task > Reporter: David Lloyd > Priority: Minor > Fix For: 3.0.0.Alpha7 > > > For each module, do the following: > * Locate any/all null param check methods in the log msg > * Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed > * Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-909) Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-909?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-909: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-909 > URL: https://issues.jboss.org/browse/WFCORE-909 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Priority: Minor > Fix For: 3.0.0.Alpha7 > > > The OperationContext current will not throw error during boot of an --admin-only process if required capabilities cannot all be resolved, instead simply logging an ERROR. This is to allow the process to boot and give the user an opportunity to fix the problem. > Test suites often run admin-only processes though to test management of the model without needing to be concerned about runtime services. For these tests, failing on boot if required capabilities are not present may be desired. In particular, it's desirable for WF full's ParseAndMarshalModelsTestCase. So this task is to use a "jboss.unsupported.validate.boot.capabilities" system property to turn on capability resolution enforcement. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-811) Add module for org.wildfly.security.elytron-web:undertow-server

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-811?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-811: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Add module for org.wildfly.security.elytron-web:undertow-server > --------------------------------------------------------------- > > Key: WFCORE-811 > URL: https://issues.jboss.org/browse/WFCORE-811 > Project: WildFly Core > Issue Type: Sub-task > Components: Modules > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > > This is the module that provides the integration between Elytron and Undertow without each needing to be aware of the other. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-782) Upgrade to Elytron 1.1.0.Alpha1

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-782?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-782: ------------------------------------ Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Upgrade to Elytron 1.1.0.Alpha1 > ------------------------------- > > Key: WFCORE-782 > URL: https://issues.jboss.org/browse/WFCORE-782 > Project: WildFly Core > Issue Type: Sub-task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > > This will also require the SSL Explorer copyright notice including within the WildFly distribution. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1145: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Review of HostController / Application Server Remoting connections > ------------------------------------------------------------------ > > Key: WFCORE-1145 > URL: https://issues.jboss.org/browse/WFCORE-1145 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Alpha7 > > > Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access. > The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1128) Improve the subsystem test schema test coverage

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1128?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1128: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Improve the subsystem test schema test coverage > ----------------------------------------------- > > Key: WFCORE-1128 > URL: https://issues.jboss.org/browse/WFCORE-1128 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.1.Final > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha7 > > > Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths(). > Rather than making it explicit to turn on, it should be explicit to turn off. > Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1059) RestartParentResourceAdd/RemoveHandler should handle capability registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1059: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > RestartParentResourceAdd/RemoveHandler should handle capability registration > ---------------------------------------------------------------------------- > > Key: WFCORE-1059 > URL: https://issues.jboss.org/browse/WFCORE-1059 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha7 > > > RestartParentResourceAddHandler and RestartParentResourceRemoveHandler do not extend the respective AbstractAddStepHandler and AbstractRemoveStepHandler base classes, and thus does not handle capability [un]registration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1054) Better subsystem test coverage

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1054?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1054: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Better subsystem test coverage > ------------------------------ > > Key: WFCORE-1054 > URL: https://issues.jboss.org/browse/WFCORE-1054 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha7 > > > The subsystem and core-model tests should be expanded to test FULL models. In many(?) cases these tests do not use a full xml. We should generate a full xml file for testing, possibly by using the schema. Or by inspecting the resource registrations a bit similar to the ExpressionSupportTestCase. > We might need something to deal with the case where e.g. a parent expects only one of two children to be set (i.e. there is a choice) and not both. In those cases it would be good to be able to test all possible permutations. This testing should be at least the parsing and marshalling of the main model. It is uncertain whether it will be possible to do do transformers, although perhaps we could do something like the DomainAdjusters from the mixed domain tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1053) Model compatibility tests

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1053?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1053: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Model compatibility tests > ------------------------- > > Key: WFCORE-1053 > URL: https://issues.jboss.org/browse/WFCORE-1053 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha7 > > > Once the infrastructure is in place, we will need to test all subsystems here and in WildFly. > The basic idea is some variety of CompareModelVersionsUtil and compare the current resource registrations against a stored snapshot of the resource registrations -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1157) Managmement and JMX notifications when ControlledProcessState changes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1157?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1157: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Managmement and JMX notifications when ControlledProcessState changes > --------------------------------------------------------------------- > > Key: WFCORE-1157 > URL: https://issues.jboss.org/browse/WFCORE-1157 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, JMX > Reporter: Brian Stansberry > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha7 > > > When Jeff Mesnil added the core management notification stuff an obvious thing to do was to emit notifications around ControlledProcessState changes. But I forgot. :( So lets do it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1154) Deprecate permgen attributes in host and server config level jvm settings

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1154?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1154: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Deprecate permgen attributes in host and server config level jvm settings > ------------------------------------------------------------------------- > > Key: WFCORE-1154 > URL: https://issues.jboss.org/browse/WFCORE-1154 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha7 > > > The permgen size attributes no longer do anything in a core 2.0 or later server, as we require JDK 8 and our code ignores these if JDK 8 or later is running. So we should deprecate the config elements and log a message if they are used, and add deprecation text in the xsd. > I considered only deprecating these attributes if they appear in the host=* tree, and not doing the ones for domain-wide resources, since those could be used for legacy slaves running JDK < 8. But I think the distinction isn't worth the effort. First, these things are deprecated in all cases in the sense that they may go away in some future release. And second, all that happens is an INFO message is logged, and the chances that message may help some JDK 8 user offsets the chance that a JDK < 8 user would be annoyed by some spurious INFO logging. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1282: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string > --------------------------------------------------------------------------------------- > > Key: WFCORE-1282 > URL: https://issues.jboss.org/browse/WFCORE-1282 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 1.0.2.Final > Environment: Oracle Java > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Alpha7 > > Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log > > > User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. > Setting as critical as these cipher suites, are considered for strong and widely used in my opinion. > In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all. > Note, that analogous configuration in EAP6 works fine. > Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). > Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1220) Try closing the channel if java.lang.Error prevents sending error responses to the client

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1220?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1220: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Try closing the channel if java.lang.Error prevents sending error responses to the client > ----------------------------------------------------------------------------------------- > > Key: WFCORE-1220 > URL: https://issues.jboss.org/browse/WFCORE-1220 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 3.0.0.Alpha7 > > > Beyond the basic work on WFCORE-1134, look into further reaction when Errors occur and the server or HC cannot even send an error response to the caller. If we get to this point, the task has already failed to handle a problem and now we can't notify the remote side either. Most likely this is an OOME situation, although any Error here means a major issue. > Options: > 1) Try and close the channel to disconnect this process from the remote end so it doesn't disrupt the remote end. If this is an intra-HC or HC-server connection a successful close will remove this process from normal domain control. If this is a server the HC still has some control over the server via the ProcessController, e.g. to handle a 'kill' or 'destroy' management op. If this is a slave HC, the slave is disconnected from the domain. Either a server or a slave HC may try to reconnect, although it's likely better if that fails and the user just restarts the process. > If the remote side is an end user client (e.g. CLI) then a successful close will be noticed by the client. The user can reconnect or take action to terminate this process. > 2) Commit suicide via SystemExiter.exit. But I'm not certain complete termination of the process is how we want to deal with problems with management requests. Probably some sort of configurable policy would be better. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1167) Upgrade jboss-invocation to include the new blockingCaller flag in InterceptorContext

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1167?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1167: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Upgrade jboss-invocation to include the new blockingCaller flag in InterceptorContext > ------------------------------------------------------------------------------------- > > Key: WFCORE-1167 > URL: https://issues.jboss.org/browse/WFCORE-1167 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Reporter: Farah Juma > Assignee: Farah Juma > Labels: affects_elytron > Fix For: 3.0.0.Alpha7 > > > Upgrade jboss-invocation to a version that includes: > https://github.com/jbossas/jboss-invocation/commit/bae968117dffa6d179ca77... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1351: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Critical > Fix For: 3.0.0.Alpha7 > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1515) Improve PersistentResourceDefinition to make it easier to register attribute write handlers

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1515?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1515: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Improve PersistentResourceDefinition to make it easier to register attribute write handlers > ------------------------------------------------------------------------------------------- > > Key: WFCORE-1515 > URL: https://issues.jboss.org/browse/WFCORE-1515 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha7 > > > Currently if you want to take register custom write handler you need to override whole registerAttributes methods and do it yourself all the way. > We could add PersistentResourceDefinition.getAttributeHandlers() method that returns > a Map<String, OperationStepHandler>. > And then registerAttributes uses the map instead of hardcoding ReloadRequiredWriteAttributeHandler. Default impl just fills the map values with > ReloadRequiredWriteAttributeHandler. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1489) Expose (un)registerNotificationHandler() on OperationContext

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1489?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1489: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Expose (un)registerNotificationHandler() on OperationContext > ------------------------------------------------------------ > > Key: WFCORE-1489 > URL: https://issues.jboss.org/browse/WFCORE-1489 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha7 > > > Currently the only way to (un)register notifications is via the NotificationHandlerRegistration exposed by ModelController.getNotificationRegistry(). It would be nice to not have to install a service whose only purpose is to get hold of the ModelController from OSH's. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1438) Elytron integration with logging subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1438?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1438: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Elytron integration with logging subsystem > ------------------------------------------ > > Key: WFCORE-1438 > URL: https://issues.jboss.org/browse/WFCORE-1438 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > > This is primarily an investigation task to start with, Logging can use syslog, Syslog access can be protected with TLS, Elytron is providing unified SSL configuration - do we need to bring these together. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1400) Update management interfaces to obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1400?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1400: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Update management interfaces to obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1400 > URL: https://issues.jboss.org/browse/WFCORE-1400 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1598) Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1598?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1598: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Conversion of Elytron SecurityIdentity to Subject for communication with older hosts. > ------------------------------------------------------------------------------------- > > Key: WFCORE-1598 > URL: https://issues.jboss.org/browse/WFCORE-1598 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > > In the domain hierarchy clients trust the server they communicate with so this server currently sends a serialized representation of the Subject containing information about the user initiating the request. > For Elytron we will use the new identity propagation features however for older slaves we will need to convert to a Subject representation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1547) Integrate CredentialStore into Core

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1547?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1547: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Integrate CredentialStore into Core > ----------------------------------- > > Key: WFCORE-1547 > URL: https://issues.jboss.org/browse/WFCORE-1547 > Project: WildFly Core > Issue Type: Sub-task > Components: Security > Reporter: Peter Skopek > Assignee: Peter Skopek > Fix For: 3.0.0.Alpha7 > > > Create necessary API for integrating Elytron CredentialStore API into WildFly Core. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1533) Integrate Management Access Control permission assignment with Elytron

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1533?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1533: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Integrate Management Access Control permission assignment with Elytron > ---------------------------------------------------------------------- > > Key: WFCORE-1533 > URL: https://issues.jboss.org/browse/WFCORE-1533 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Alpha7 > > > A big portion of management role based access control is taking the assigned roles and then mapping these to the permissions for that role. > Elytron provides a new PermissionMapper interface that takes a SecurityIdentity and the roles mapped for that identity and returns a PermissionVerifier which can be as simple as a wrapper around a PermissionCollection. > This will also be a good opportunity to start to move the role mapping out of the core management model to Elytron. > After that Elytron allows for custom PermissionMapper implementations to be provided and associated with the domain using capabilities and requirements so we arrive at a point where provided the permission checks performed by management are generic enough custom PermissionMapper / PermissionVerifier implementations can be added that may or may not be role based. > _Note: As with everything we are doing old and new need to be supported in parallel for a while although this may be achieved by providing default Elytron implementations that are wrappers around the old._ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1693) Upgrade to JBoss Remoting 5.0.0.Beta4

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1693?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1693: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Upgrade to JBoss Remoting 5.0.0.Beta4 > ------------------------------------- > > Key: WFCORE-1693 > URL: https://issues.jboss.org/browse/WFCORE-1693 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1692) Upgrade to JBoss Modules 1.6.0.Beta1

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1692?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1692: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Upgrade to JBoss Modules 1.6.0.Beta1 > ------------------------------------ > > Key: WFCORE-1692 > URL: https://issues.jboss.org/browse/WFCORE-1692 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Modules > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1691) Upgrade to Remoting JMX 3.0.0.Alpha1

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1691?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1691: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Upgrade to Remoting JMX 3.0.0.Alpha1 > ------------------------------------ > > Key: WFCORE-1691 > URL: https://issues.jboss.org/browse/WFCORE-1691 > Project: WildFly Core > Issue Type: Component Upgrade > Components: JMX > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1602) Elytron integration with JMX

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1602?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1602: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Elytron integration with JMX > ---------------------------- > > Key: WFCORE-1602 > URL: https://issues.jboss.org/browse/WFCORE-1602 > Project: WildFly Core > Issue Type: Feature Request > Components: JMX > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1600) Update the legacy security realms to add factory methods to obtain SaslAuthenticationFactory and HttpAuthenticationFactory instances.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1600?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1600: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Update the legacy security realms to add factory methods to obtain SaslAuthenticationFactory and HttpAuthenticationFactory instances. > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1600 > URL: https://issues.jboss.org/browse/WFCORE-1600 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > > These are for use when security realms are directly referenced, although Elytron types these should not be advertised as capabilities as these are for specific backwards compatibility requirements and not to increase their use as Elytron capabilities. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1701) In-VM Identity Representation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1701?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1701: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > In-VM Identity Representation > ----------------------------- > > Key: WFCORE-1701 > URL: https://issues.jboss.org/browse/WFCORE-1701 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > > If Elytron has no current SecurityIdentity then an anonymous identity is used. The issue however is that this anonymous identity could be because the current user does not have access to be inflowed to the SecurityDomain being used for management or it could be because it is an in-vm call and no identity is established. > We need a solution to safely represent an in-vm call and differentiate it from a user with no appropriate identity, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1694) Upgrade to WildFly Client Config 1.0.0.Beta1

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1694?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1694: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > Upgrade to WildFly Client Config 1.0.0.Beta1 > -------------------------------------------- > > Key: WFCORE-1694 > URL: https://issues.jboss.org/browse/WFCORE-1694 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1733) SynchServerOperationHandler doesn't check ops for REQUIRE_RESTART properly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1733?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1733: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > SynchServerOperationHandler doesn't check ops for REQUIRE_RESTART properly > -------------------------------------------------------------------------- > > Key: WFCORE-1733 > URL: https://issues.jboss.org/browse/WFCORE-1733 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ken Wills > Assignee: Ken Wills > Fix For: 3.0.0.Alpha7 > > > Currently, SyncServerStateOperationHandler makes a simple check to determine if the result of an op should put a server into restart-required. This should be fixed to check the AttributeDefinition for the target of a write-attribute for restart-required, and the OperationDefinition of all other ops. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1741) read-content operation does not return the uuid of the stream as the operation result

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1741?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1741: ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha6) > read-content operation does not return the uuid of the stream as the operation result > ------------------------------------------------------------------------------------- > > Key: WFCORE-1741 > URL: https://issues.jboss.org/browse/WFCORE-1741 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Alpha7 > > > See the tail end of the discussion on WFCORE-1726. > The rules around streams in responses are: > 1) If the thing providing the stream is an attribute, the attribute value set by the read OperationStepHandler must be the uuid of the stream. > 2) If the thing providing the stream is a custom operation like :read-content, the result value in the response must be the uuid of the stream or a complex result object one of whose fields is the uuid of the stream. > Metadata about streams is propagated to the client using a response-header. But since a particular request can result in more than one attached stream, the normal non-response-header part of the result for a step must provide the uuid of the stream set by that step. This allows the client to correlate the various streams with the steps that provided them. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1682: ------------------------------------------ Did the revert resolve this? > Missleading tab completion for edit-batch-line command > ------------------------------------------------------ > > Key: WFCORE-1682 > URL: https://issues.jboss.org/browse/WFCORE-1682 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Petr Kremensky > Assignee: Jean-Francois Denise > > Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works. > *command usage* > {noformat} > [standalone@localhost:9990 /] batch > [standalone@localhost:9990 / #] :read-resource > [standalone@localhost:9990 / #] list-batch > #1 /:read-resource > [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type) > #1 :read-attribute(name=launch-type) > [standalone@localhost:9990 / #] list-batch > #1 :read-attribute(name=launch-type) > {noformat} > *actual* > {noformat} > [standalone@localhost:9990 / #] edit-batch-line <TAB> > [standalone@localhost:9990 / #] edit-batch-line --<TAB> > --help --line-number > [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type) > Failed to parse line number '--line-number=1': For input string: "--line-number=1" > {noformat} > {{--line-number}} shouldn't be offered by tab completion for the command. > Misleading tab completion ends up with syntax error. > *expected* > {noformat} > [standalone@localhost:9990 / #] edit-batch-line <TAB> > --help > {noformat} > The issue is a regression against EAP 7.0.0 release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1737) rrd on data-source=*/statistics=pool throws NPE

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1737?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1737: ------------------------------------------ This is fixed but note that if no DS is enabled, that operation will fail with a WFLYCTL0030. There is no "statistics=pool" registration if there's no enabled DS. > rrd on data-source=*/statistics=pool throws NPE > ----------------------------------------------- > > Key: WFCORE-1737 > URL: https://issues.jboss.org/browse/WFCORE-1737 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Claudio Miranda > Assignee: Brian Stansberry > Fix For: 3.0.0.Alpha6 > > > Run the following command in CLI it throws a NullPointerException > As it is a rrd it should not require a resolved wildcard > {code} > /subsystem=datasources/data-source=*/statistics=pool:read-resource-description > {code} > Results > {code} > { > "outcome" => "failed", > "result" => [], > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException", > "rolled-back" => true > } > {code} > The exception throws at server.log > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("resolve") failed - address: ([]): java.lang.NullPointerException > at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:422) > at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeSingleTargetChild(GlobalOperationHandlers.java:903) > at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:442) > at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeMultiTargetChildren(GlobalOperationHandlers.java:895) > at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:440) > at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeSingleTargetChild(GlobalOperationHandlers.java:903) > at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:442) > at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:337) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > This op works > {code} > /subsystem=datasources/data-source=*:read-resource-description > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1757) Add support for OpenSSL

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1757?page=com.atlassian.jira.plugi... ] Stuart Douglas reassigned WFCORE-1757: -------------------------------------- Assignee: Stuart Douglas > Add support for OpenSSL > ----------------------- > > Key: WFCORE-1757 > URL: https://issues.jboss.org/browse/WFCORE-1757 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1757) Add support for OpenSSL

by Stuart Douglas (JIRA)

Stuart Douglas created WFCORE-1757: -------------------------------------- Summary: Add support for OpenSSL Key: WFCORE-1757 URL: https://issues.jboss.org/browse/WFCORE-1757 Project: WildFly Core Issue Type: Feature Request Reporter: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2016