May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1524) Scanner deployment failing at boot passes readiness/liveness checks

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1524?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1524: ------------------------------------------ >From an IRC chat with Rob Cernich: {code} [11:17am] rcernich: bstansberry: quick question, we're seeing the cli return deployment-info of failed for a deployment, but there's a .deployed file in the deployments directory (eap7) [11:17am] bstansberry: rcernich: hi rob [11:17am] bstansberry: rcernich: that doesn’t sound right [11:17am] rcernich: bstansberry: infinispan fails to start (times out) and thus the deployment fails (sort of) [11:18am] rcernich: bstansberry: the log includes "Deployed "ROOT.war" (runtime-name: "ROOT.war") [11:19am] bstansberry: rcernich: this is all during boot, right? [11:19am] rcernich: bstansberry: yes [11:19am] rcernich: bstansberry: here's a link to our issue: https://issues.jboss.org/browse/CLOUD-615 [11:19am] rcernich: the log is attached [11:20am] bstansberry: rcernich: ok, I *suspect* this is related to how failures are handled during boot [11:21am] rcernich: bstansberry: the deployment seems to fail, as eap is returning 404's for the app url's [11:22am] bstansberry: rcernich: right; the problem AIUI is there is no .failed file, right? [11:22am] rcernich: bstansberry: correct (and you could say the entry in the log is misleading as well) [11:23am] bstansberry: rcernich: I’m going to clone that JIRA into WFCORE {code} Note Rob's comment about the logging, which is valid in addition to the issue with the deployment marker file. > Scanner deployment failing at boot passes readiness/liveness checks > ------------------------------------------------------------------- > > Key: WFCORE-1524 > URL: https://issues.jboss.org/browse/WFCORE-1524 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner, Domain Management > Environment: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7/eap70-openshift:1.3-11 > Reporter: Marek Schmidt > Assignee: ehsavoie Hugonnet > > During larger scale-ups (e.g. from 1 to 6 on nodes under load) deployments sometimes fail with "org.infinispan.util.concurrent.TimeoutException: Replication timeout for foo-1-xxxxx". > That by itself is expected with the default timeouts, however, the problem is that such failed deployments pass the default EAP readiness and liveness checks, which results in HTTP 404 responses. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1524) Scanner deployment failing at boot passes readiness/liveness checks

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1524?page=com.atlassian.jira.plugi... ] Brian Stansberry moved CLOUD-647 to WFCORE-1524: ------------------------------------------------ Project: WildFly Core (was: Cloud Enablement) Key: WFCORE-1524 (was: CLOUD-647) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: Deployment Scanner Domain Management (was: EAP7) Target Release: (was: 1.3.1.GA) Fix Version/s: (was: 1.3.1.GA) > Scanner deployment failing at boot passes readiness/liveness checks > ------------------------------------------------------------------- > > Key: WFCORE-1524 > URL: https://issues.jboss.org/browse/WFCORE-1524 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner, Domain Management > Environment: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7/eap70-openshift:1.3-11 > Reporter: Marek Schmidt > > During larger scale-ups (e.g. from 1 to 6 on nodes under load) deployments sometimes fail with "org.infinispan.util.concurrent.TimeoutException: Replication timeout for foo-1-xxxxx". > That by itself is expected with the default timeouts, however, the problem is that such failed deployments pass the default EAP readiness and liveness checks, which results in HTTP 404 responses. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1524) Scanner deployment failing at boot passes readiness/liveness checks

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1524?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1524: ---------------------------------------- Assignee: ehsavoie Hugonnet > Scanner deployment failing at boot passes readiness/liveness checks > ------------------------------------------------------------------- > > Key: WFCORE-1524 > URL: https://issues.jboss.org/browse/WFCORE-1524 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner, Domain Management > Environment: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7/eap70-openshift:1.3-11 > Reporter: Marek Schmidt > Assignee: ehsavoie Hugonnet > > During larger scale-ups (e.g. from 1 to 6 on nodes under load) deployments sometimes fail with "org.infinispan.util.concurrent.TimeoutException: Replication timeout for foo-1-xxxxx". > That by itself is expected with the default timeouts, however, the problem is that such failed deployments pass the default EAP readiness and liveness checks, which results in HTTP 404 responses. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6583) Session leak on SmartOS hosts

by Michael Noack (JIRA)

Michael Noack created WFLY-6583: ----------------------------------- Summary: Session leak on SmartOS hosts Key: WFLY-6583 URL: https://issues.jboss.org/browse/WFLY-6583 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.Final, 9.0.0.Final, 8.2.0.Final Environment: CentOS 7 or SmartOS instance using Joyents Infrastructure/Bare metal container. [root@979638eb-b45c-45b3-9fdb-d7f48276e4ef /]# java -version java version "1.8.0_77" Java(TM) SE Runtime Environment (build 1.8.0_77-b03) Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode) [root@979638eb-b45c-45b3-9fdb-d7f48276e4ef /]# uname -a Linux 979638eb-b45c-45b3-9fdb-d7f48276e4ef 3.10.0 BrandZ virtual linux x86_64 x86_64 x86_64 GNU/Linux [root@979638eb-b45c-45b3-9fdb-d7f48276e4ef /]# cat /etc/issue \S Kernel \r on an \m Reporter: Michael Noack Assignee: Paul Ferraro Priority: Minor When running Wildfly 8.2.0-Final, 9.0.0-Final or 10.0.0-Final in domain mode using the full-ha profile some sessions never get closed when running on SmartOS or a BrandZ kernel on SmartOS. The amount of unclosed sessions rises slowly. I've been keeping track of this issue for almost a year now and handled it by restarting the entire cluster at first. When registering a HttpSessionListener and logging any sessionCreated(HttpSessionEvent se) and sessionDestroyed(HttpSessionEvent se) one can cleary see some sessions never generate the sessionDestroyed event. The problem disappears when running the very same setup on a KVM instance of CentOS 6 or 7 (regardless whether the KVM host is SmartOS or Linux). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1523) Removing of non-existent policy-module finishes with outcome success

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1523?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Śmietanko updated WFCORE-1523: --------------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/8896, https://github.com/wildfly/wildfly-core/pull/1543 (was: https://github.com/wildfly/wildfly/pull/8896) > Removing of non-existent policy-module finishes with outcome success > -------------------------------------------------------------------- > > Key: WFCORE-1523 > URL: https://issues.jboss.org/browse/WFCORE-1523 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.1.0.Final > Reporter: Ondrej Lukas > Assignee: Bartosz Spyrko-Śmietanko > Priority: Minor > > In case when non-existent policy-module is removed through Management CLI, operation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-915) LeftTuples don't get deleted from segment memories when the segment itself is unlinked

by Dmitry Toptygin (JIRA)

[ https://issues.jboss.org/browse/DROOLS-915?page=com.atlassian.jira.plugin... ] Dmitry Toptygin commented on DROOLS-915: ---------------------------------------- Maybe this comment will help if anybody experiences this issue in the field. This defect, while not a true memory leak, has manifested itself for us this way: In the exaggerated rule example below, if AlarmFacts are rarely created (let's say one per day), and if ClearEvents come in very frequently (let's say once a second), then every day kSession would maintain references to unnecessary ClearEvents (up to 86000 of them). These ClearEvents are expired and not visible to the rules, kSession.getFactHandles() does not return them. But they are being kept in JVM memory by JoinNodeLeftTuple(s), via EventHactHandle. In order to release those ClearEvents, an artificial AlarmFact can be inserted periodically, which is not practical, or the rule can be rewritten - see "fixed rule example" at the end of the comment. --- begin bad rule example --- {code:java} package rules import org.example.memoryleak.events.ClearEvent import org.example.memoryleak.events.AlarmFact declare org.example.memoryleak.events.ClearEvent @role( event ) @timestamp( eventTimestamp ) @expires( 5s ) end rule "Delete alarm on clearEvent" when ClearEvent($devId: deviceId) $alarm: AlarmFact($devId == deviceId) then delete($alarm); end {code} --- end bad rule example --- --- begin fixed rule example --- {code:java} ... rule "Delete alarm on clearEvent" when $alarm: AlarmFact($devId: deviceId) ClearEvent(deviceId == $devId) then delete($alarm); end {code} --- end fixed rule example --- > LeftTuples don't get deleted from segment memories when the segment itself is unlinked > -------------------------------------------------------------------------------------- > > Key: DROOLS-915 > URL: https://issues.jboss.org/browse/DROOLS-915 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > > LeftTuples should be deleted from segment memories when the segment itself is unlinked. At the moment they remain in the segment memory forever until the segment is linked in again. This is not a memory leak because the segment memory cannot grow when the segment itself is unlinked, but just an optimization to free memory as early as possible. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2049) Measure round trip time for blocking RPCs via probe

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2049?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2049. ---------------------------- Resolution: Done Backported to the 3.6 branch > Measure round trip time for blocking RPCs via probe > --------------------------------------------------- > > Key: JGRP-2049 > URL: https://issues.jboss.org/browse/JGRP-2049 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.10, 4.0 > > > Currently, RPC RTT is measured at the {{RpcDispatcher}} level. The current code doesn't measure blocking RPCs which return a future. > Moving this code to the {{RequestCorrelator}} level would allow us to measure RTTs for this as well, as an RPC is terminated via {{done()}} or {{cancel()}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1159) Project examples are created with lots of unresolved types

by Andrej Podhradsky (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1159?page=com.atlassian.jira.plugi... ] Andrej Podhradsky closed DROOLS-1159. ------------------------------------- Resolution: Duplicate Issue This is a duplicate issue of DROOLS-1151 > Project examples are created with lots of unresolved types > ---------------------------------------------------------- > > Key: DROOLS-1159 > URL: https://issues.jboss.org/browse/DROOLS-1159 > Project: Drools > Issue Type: Bug > Components: eclipse plugin > Affects Versions: 6.4.0.Final > Reporter: Andrej Podhradsky > Assignee: Robert (Bob) Brodt > > After creating an example form online repository there are lots of errors such as unresolved types. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1159) Project examples are created with lots of unresolved types

by Andrej Podhradsky (JIRA)

Andrej Podhradsky created DROOLS-1159: ----------------------------------------- Summary: Project examples are created with lots of unresolved types Key: DROOLS-1159 URL: https://issues.jboss.org/browse/DROOLS-1159 Project: Drools Issue Type: Bug Components: eclipse plugin Affects Versions: 6.4.0.Final Reporter: Andrej Podhradsky Assignee: Robert (Bob) Brodt After creating an example form online repository there are lots of errors such as unresolved types. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1523) Removing of non-existent policy-module finishes with outcome success

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1523?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Śmietanko moved WFLY-6101 to WFCORE-1523: -------------------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-1523 (was: WFLY-6101) Component/s: Domain Management Security (was: Domain Management) (was: Security) Affects Version/s: 2.1.0.Final (was: 10.0.0.Final) > Removing of non-existent policy-module finishes with outcome success > -------------------------------------------------------------------- > > Key: WFCORE-1523 > URL: https://issues.jboss.org/browse/WFCORE-1523 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.1.0.Final > Reporter: Ondrej Lukas > Assignee: Bartosz Spyrko-Śmietanko > Priority: Minor > > In case when non-existent policy-module is removed through Management CLI, operation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2016