[JBoss JIRA] (WFCORE-3831) jboss-cli.ps1 script doesn't return exit value correctly
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3831?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise reassigned WFCORE-3831:
--------------------------------------------
Assignee: Jean-Francois Denise
> jboss-cli.ps1 script doesn't return exit value correctly
> --------------------------------------------------------
>
> Key: WFCORE-3831
> URL: https://issues.jboss.org/browse/WFCORE-3831
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Reporter: Marek Kopecký
> Assignee: Jean-Francois Denise
>
> jboss-cli.ps1 script doesn't return exit value correctly
> Steps to reproduce:
> # start Command prompt in Windows
> # PowerShell \-ExecutionPolicy Bypass -File jboss-cli.ps1 "\-\-commands=nonsence" \-\-timeout=10000
> # echo %ERRORLEVEL%
> #* "0" is printed, "1" should be printed
> # add "exit 5" to the end of jboss-cli.ps1 file
> # PowerShell \-ExecutionPolicy Bypass -File jboss-cli.ps1 "\-\-commands=nonsence" \-\-timeout=10000
> # echo %ERRORLEVEL%
> #* "5" is printed
> cc: [~jamezp], [~eduda], [~jdenise]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10833) Wildfly 13.0.0.Final deployment failed due to WELD-001409: Ambiguous dependencies for type CompensationManager with qualifiers @Default
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10833?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-10833:
----------------------------------------
[~westlake91361] nice, thank you! :)
> Wildfly 13.0.0.Final deployment failed due to WELD-001409: Ambiguous dependencies for type CompensationManager with qualifiers @Default
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10833
> URL: https://issues.jboss.org/browse/WFLY-10833
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 13.0.0.Final
> Environment: JDK 8
> Wildfly 13.0.0.Final
> Reporter: Angela Yuan
> Assignee: Ondra Chaloupka
>
> Able to deploy the same WAR and EAR to Wildfly 10.0.0.Final but not to 13.0.0.Final with the following error:
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."xxxxx.war".WeldStartService: org.jboss.msc.service.S
> tartException in service jboss.deployment.unit."fwdm-services-1.0-SNAPSHOT.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1728)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type CompensationManager with qualifiers @Default
> at injection point [UnbackedAnnotatedField] @Inject org.jboss.narayana.compensations.impl.CancelOnFailureInterceptor.compensationManager
> at org.jboss.narayana.compensations.impl.CancelOnFailureInterceptor.compensationManager(CancelOnFailureInterceptor.java:0)
> Possible dependencies:
> - Managed Bean [class org.jboss.narayana.compensations.internal.CompensationManagerImpl] with qualifiers [@Any @Default],
> - Managed Bean [class org.jboss.narayana.compensations.impl.CompensationManagerImpl] with qualifiers [@Any @Default]
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:386)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290)
> at org.jboss.weld.bootstrap.Validator.validateInterceptor(Validator.java:564)
> at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:81)
> at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:79)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10833) Wildfly 13.0.0.Final deployment failed due to WELD-001409: Ambiguous dependencies for type CompensationManager with qualifiers @Default
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10833?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka closed WFLY-10833.
----------------------------------
Resolution: Explained
> Wildfly 13.0.0.Final deployment failed due to WELD-001409: Ambiguous dependencies for type CompensationManager with qualifiers @Default
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10833
> URL: https://issues.jboss.org/browse/WFLY-10833
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 13.0.0.Final
> Environment: JDK 8
> Wildfly 13.0.0.Final
> Reporter: Angela Yuan
> Assignee: Ondra Chaloupka
>
> Able to deploy the same WAR and EAR to Wildfly 10.0.0.Final but not to 13.0.0.Final with the following error:
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."xxxxx.war".WeldStartService: org.jboss.msc.service.S
> tartException in service jboss.deployment.unit."fwdm-services-1.0-SNAPSHOT.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1728)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type CompensationManager with qualifiers @Default
> at injection point [UnbackedAnnotatedField] @Inject org.jboss.narayana.compensations.impl.CancelOnFailureInterceptor.compensationManager
> at org.jboss.narayana.compensations.impl.CancelOnFailureInterceptor.compensationManager(CancelOnFailureInterceptor.java:0)
> Possible dependencies:
> - Managed Bean [class org.jboss.narayana.compensations.internal.CompensationManagerImpl] with qualifiers [@Any @Default],
> - Managed Bean [class org.jboss.narayana.compensations.impl.CompensationManagerImpl] with qualifiers [@Any @Default]
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:386)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290)
> at org.jboss.weld.bootstrap.Validator.validateInterceptor(Validator.java:564)
> at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:81)
> at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:79)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2888) Data Type UX - dialog enhancements: Add and Reorder
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2888?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2888:
-------------------------------------
[~stetson.robinson] I was thinking the latter, unless that breaks consistency with other help touch points. I'll update the click-thru with a proposed short and long version. If you can review the content that would be great, thanks!
> Data Type UX - dialog enhancements: Add and Reorder
> ----------------------------------------------------
>
> Key: DROOLS-2888
> URL: https://issues.jboss.org/browse/DROOLS-2888
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: Screen Shot 2018-08-17 at 4.29.29 PM.png, previous.gif
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * Add fields first to last, not last to first, in an ordered list to support the "reading" order of the fields so that I can simplify my workflow.
> * Reorder the list of Custom data types so that I can arrange data types in a logical order.
> * Add list items in such a way that added Fields will be presented at the bottom of a structured list by default.
> Functional considerations/ pre conditions:
> * Fields will be presented at the bottom of a structured list by default.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> * Drag-n-drop be evaluated with regard to accessibility.
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10736) Server in cluster hangs during start after previous kill
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-10736?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFLY-10736:
-----------------------------------
[~jfclere] [~pferraro] [~rachmato] - As [~rhusar] is on PTO, who can look at this?
CC [~jamezp]
> Server in cluster hangs during start after previous kill
> --------------------------------------------------------
>
> Key: WFLY-10736
> URL: https://issues.jboss.org/browse/WFLY-10736
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Miroslav Novak
> Assignee: Radoslav Husar
> Priority: Blocker
> Labels: blocker-WF14
> Attachments: Lodh2TestCase.testRemoteJcaInboundOnly-traces.zip, Lodh2TestCase.testRemoteJcaInboundOnly.zip, clusterKilTest.zip, logs-with-workaround.zip, node-1-thread-dump-before-kill-shutdown-sequence.txt, server-with-mdb.log, standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> There is regression in JGroups or Infinispan in one of our tests for fault tolerance of JMS bridges. However work on JMS bridge appears to be unrelated. Issue was hit in WF weekly run.
> Test Scenario:
> * There are two servers. InQueue is deployed on Node 1,
> * OutQueue is deployed on Node 2. Both servers are started.
> * Large byte messages are sent to InQueue deployed on Node 1. Bridge between servers/queues transfers messages from node 1 to node 2.
> * Node 1 is killed and started again.
> * All messages are received from OutQueue deployed on Node 2.
> Result:
> Node 1 does not start after kill and hangs. There is following exception logged in node 2:
> {code}
> :26:17,894 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100000: Node node-1 joined the cluster
> 09:26:18,520 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,523 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,868 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) ISPN000310: Starting cluster-wide rebalance for cache default, topology CacheTopology{id=17, phase=READ_OLD_WRITE_ALL, rebalanceId=6, currentCH=ReplicatedConsistentHash{ns = 256, owners = (2)[node-2: 122, node-1: 134]}, pendingCH=ReplicatedConsistentHash{ns = 256, owners = (3)[node-2: 84, node-1: 90, node-1: 82]}, unionCH=null, actualMembers=[node-2, node-1, node-1], persistentUUIDs=[12443bfb-e88a-46f3-919e-9213bf38ce19, 2873237f-d881-463f-8a5a-940bf1d764e5, a05ea8af-a83b-42a9-b937-dc2da1cae6d1]}
> 09:26:18,869 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-2]ISPN100002: Started rebalance with topology id 17
> 09:26:18,870 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t5) [Context=default][Scope=node-2]ISPN100003: Node node-2 finished rebalance phase with topology id 17
> 09:26:18,981 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-1]ISPN100003: Node node-1 finished rebalance phase with topology id 17
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p15-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p16-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> {code}
> There is default JGroups udp stack configured which is used by Infinispan. Both of the servers (jgroups udp) are bound to 127.0.0.1. Node 2 has port offset 1000.
> Attaching thread dump from node 1 when it hangs during start.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4002) JDK11 Some security tests fail on closed channel exception
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4002?page=com.atlassian.jira.plugi... ]
Kabir Khan edited comment on WFCORE-4002 at 8/20/18 6:30 AM:
-------------------------------------------------------------
> The problem is TLSv1.3, where DSA keys are forbidden - keystores used in tests needs to be regenerated for RSA.
[~honza889] [~ropalka] who will be working on this? CC [~jamezp]
was (Author: kabirkhan):
> The problem is TLSv1.3, where DSA keys are forbidden - keystores used in tests needs to be regenerated for RSA.
[~honza889] [~ropalka] who will be working on this?
> JDK11 Some security tests fail on closed channel exception
> ----------------------------------------------------------
>
> Key: WFCORE-4002
> URL: https://issues.jboss.org/browse/WFCORE-4002
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Test Suite
> Affects Versions: 6.0.0.Alpha5
> Reporter: Richard Opalka
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: jdk11
> Fix For: 6.0.0.CR2
>
>
> With latest JDK11 (build 11-ea+25) the following tests fail due to closed channel exception:
> * domain-management/src/test/java/org/jboss/as/domain/management/security/auditlog/AuditLogHandlerBootEnabledTestCase.java
> * testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/HTTPSManagementInterfaceTestCase.java
> * testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosNativeMgmtSaslTestCase.java
> * testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/ScramPlusMgmtSaslTestCase.java
> * testsuite/manualmode/src/test/java/org/wildfly/core/test/standalone/mgmt/HTTPSManagementInterfaceTestCase.java
> Is there a known SSL issue in JDK11? Could somebody from our security team investigate this issue?
> When these tests will start passing WFCORE test suite will be passing 100% of tests on JDK11.
> Potential investigator from our security team may want to include this PR:
> https://github.com/wildfly/wildfly-core/pull/3420
> to fix known JDK11 issues.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4002) JDK11 Some security tests fail on closed channel exception
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4002?page=com.atlassian.jira.plugi... ]
Kabir Khan commented on WFCORE-4002:
------------------------------------
> The problem is TLSv1.3, where DSA keys are forbidden - keystores used in tests needs to be regenerated for RSA.
[~honza889] [~ropalka] who will be working on this?
> JDK11 Some security tests fail on closed channel exception
> ----------------------------------------------------------
>
> Key: WFCORE-4002
> URL: https://issues.jboss.org/browse/WFCORE-4002
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Test Suite
> Affects Versions: 6.0.0.Alpha5
> Reporter: Richard Opalka
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: jdk11
> Fix For: 6.0.0.CR2
>
>
> With latest JDK11 (build 11-ea+25) the following tests fail due to closed channel exception:
> * domain-management/src/test/java/org/jboss/as/domain/management/security/auditlog/AuditLogHandlerBootEnabledTestCase.java
> * testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/HTTPSManagementInterfaceTestCase.java
> * testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosNativeMgmtSaslTestCase.java
> * testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/ScramPlusMgmtSaslTestCase.java
> * testsuite/manualmode/src/test/java/org/wildfly/core/test/standalone/mgmt/HTTPSManagementInterfaceTestCase.java
> Is there a known SSL issue in JDK11? Could somebody from our security team investigate this issue?
> When these tests will start passing WFCORE test suite will be passing 100% of tests on JDK11.
> Potential investigator from our security team may want to include this PR:
> https://github.com/wildfly/wildfly-core/pull/3420
> to fix known JDK11 issues.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-9735) Add systemd unit file to zip distribution
by Arnav Bhati (JIRA)
[ https://issues.jboss.org/browse/WFLY-9735?page=com.atlassian.jira.plugin.... ]
Arnav Bhati commented on WFLY-9735:
-----------------------------------
[~ctomc] - Any updates on above ?
> Add systemd unit file to zip distribution
> -----------------------------------------
>
> Key: WFLY-9735
> URL: https://issues.jboss.org/browse/WFLY-9735
> Project: WildFly
> Issue Type: Feature Request
> Components: Scripts
> Reporter: Osamu Nagano
> Attachments: eap7-standalone.service, tomcat8.service
>
>
> Systemd can handle legacy init.d scripts, but many customers have asked for native integration to systemd. We may be able to provide the out-of-the-box unit file or a template of it with some documentation. It seems JWS is considering the same in JWS-811 so EAP may adopt the same way.
> One advantage of systemd is the ability to depends on socket unit file so that we may be able to omit jsvc to listen a privileged port.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months