April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2951) Add JSON formatter resources to the logging subsystem

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2951?page=com.atlassian.jira.plugi... ] James Perkins edited comment on WFCORE-2951 at 4/9/18 1:30 PM: --------------------------------------------------------------- Analysis Document: https://github.com/wildfly/wildfly-proposals/pull/47 was (Author: jamezp): Analysis Document: https://developer.jboss.org/docs/DOC-56153 > Add JSON formatter resources to the logging subsystem > ----------------------------------------------------- > > Key: WFCORE-2951 > URL: https://issues.jboss.org/browse/WFCORE-2951 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > The logging subsystem should include resources for a {{json-formatter}} -and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires-. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-118) ElasticSearch deployment fails on B11 cluster with out of memory errors

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-118?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo commented on SWSQE-118: ----------------------------------------------- [~kearls] Hi Kevin, I changed ElasticSearch Stateful Set from 512MB to 2GB and it seems to be working !screenshot-1.png|thumbnail! I would change that on the template > ElasticSearch deployment fails on B11 cluster with out of memory errors > ----------------------------------------------------------------------- > > Key: SWSQE-118 > URL: https://issues.jboss.org/browse/SWSQE-118 > Project: Kiali QE > Issue Type: QE Task > Reporter: Kevin Earls > Assignee: Guilherme Baufaker Rêgo > Priority: Blocker > Attachments: screenshot-1.png > > > As part of KIALI-336 I'm trying to run Jaeger with ElasticSearch as its storage, using this Jenkinsfile: https://github.com/jaegertracing/jaeger-performance/blob/master/standalon... > The test is setup on B11 in the jaeger-test project https://jenkins-jaeger-test.openshift4.jonqe.lab.eng.bos.redhat.com/job/J... > I'm running into a few problems here, which may or may not be related. > 1. Even though I've run this test twice, Jenkins does not have any logs. > 2. ElasticSearch will not start up. I don't have the exact log of the problem yet, as it keeps trying to redeploy, but I have seen "Oom" errors messages, which I assume means out of memory. I will attach logs if I can catch it in this exact state. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-118) ElasticSearch deployment fails on B11 cluster with out of memory errors

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-118?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-118: ------------------------------------------ Attachment: screenshot-1.png > ElasticSearch deployment fails on B11 cluster with out of memory errors > ----------------------------------------------------------------------- > > Key: SWSQE-118 > URL: https://issues.jboss.org/browse/SWSQE-118 > Project: Kiali QE > Issue Type: QE Task > Reporter: Kevin Earls > Assignee: Guilherme Baufaker Rêgo > Priority: Blocker > Attachments: screenshot-1.png > > > As part of KIALI-336 I'm trying to run Jaeger with ElasticSearch as its storage, using this Jenkinsfile: https://github.com/jaegertracing/jaeger-performance/blob/master/standalon... > The test is setup on B11 in the jaeger-test project https://jenkins-jaeger-test.openshift4.jonqe.lab.eng.bos.redhat.com/job/J... > I'm running into a few problems here, which may or may not be related. > 1. Even though I've run this test twice, Jenkins does not have any logs. > 2. ElasticSearch will not start up. I don't have the exact log of the problem yet, as it keeps trying to redeploy, but I have seen "Oom" errors messages, which I assume means out of memory. I will attach logs if I can catch it in this exact state. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2467) Static imports in generated executable model dsl can cause method name clashes

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2467: ----------------------------------- Summary: Static imports in generated executable model dsl can cause method name clashes Key: DROOLS-2467 URL: https://issues.jboss.org/browse/DROOLS-2467 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2466) Static imports in generated executable model dsl can cause method name clashes

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2466?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-2466. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/331195dc4bd0525e59805fad5a5bebd... > Static imports in generated executable model dsl can cause method name clashes > ------------------------------------------------------------------------------ > > Key: DROOLS-2466 > URL: https://issues.jboss.org/browse/DROOLS-2466 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-124) Fix or replace the CNCF CI OpenShift Cluster

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-124?page=com.atlassian.jira.plugin.... ] Matt Mahoney commented on SWSQE-124: ------------------------------------ Setup RHEL OS instance: https://147.75.54.137:8443/console/ user1/redhat Jenkins as admin > Fix or replace the CNCF CI OpenShift Cluster > -------------------------------------------- > > Key: SWSQE-124 > URL: https://issues.jboss.org/browse/SWSQE-124 > Project: Kiali QE > Issue Type: QE Task > Reporter: Kevin Earls > Assignee: Matt Mahoney > > As we've discussed in email, the CNCF CI OpenShift cluster is currently in a state where deleting some resources is impossible, which makes it impossible to run Jenkins tests. I first saw this when a test tried to delete ElasticSearch. Then after a cluster restart I saw the same problem with Cassandra. > We either need to figure out how to resolve the problem, or replace the cluster. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9521) CacheRegistry and CacheServiceProviderRegistry use inefficient marshalling of Node objects.

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-9521?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-9521: ------------------------------- Summary: CacheRegistry and CacheServiceProviderRegistry use inefficient marshalling of Node objects. (was: CacheRegistry and CacheServiceProviderRegistry cache mapping is suboptimal) > CacheRegistry and CacheServiceProviderRegistry use inefficient marshalling of Node objects. > ------------------------------------------------------------------------------------------- > > Key: WFLY-9521 > URL: https://issues.jboss.org/browse/WFLY-9521 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Both the org.wildfly.clustering.registry.Registry and org.wildfly.clustering.provider.ServiceProviderRegistry currently store references to a Node object in their respective caches. The AddressableNode implementation currently serializes: > * org.jgroups.Address > * The logical name (typically a host name) > * The socket binding address/port of its transport > This is overkill. The Node should only need to serialize enough information to reconstruct itself using a NodeFactory<Address>, which should only include: > * its Address > * something to minimally identify the NodeFactory<Address>, with which to use to reconstruct the Node, e.g. a group name > Unfortunately, getting a reference to the NodeFactory during deserialization isn't trivial, as these are on-demand services. > Another approach, is to avoid referencing the Node in cache keys/values altogether. Currently, Registry<K, V> uses a Cache<Node, Map.Entry<K, V>> and ServiceProviderRegistry<K> uses a Cache<K, Set<Node>>. In both cases, we can replace Node with Address, and thus avoid unnecessary marshalling of the logical name and physical address of a member. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9521) CacheRegistry and CacheServiceProviderRegistry cache mapping is suboptimal

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-9521?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-9521: ------------------------------- Summary: CacheRegistry and CacheServiceProviderRegistry cache mapping is suboptimal (was: Marshalling of org.wildfly.clustering.group.Node implementations is suboptimal) > CacheRegistry and CacheServiceProviderRegistry cache mapping is suboptimal > -------------------------------------------------------------------------- > > Key: WFLY-9521 > URL: https://issues.jboss.org/browse/WFLY-9521 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Both the org.wildfly.clustering.registry.Registry and org.wildfly.clustering.provider.ServiceProviderRegistry currently store references to a Node object in their respective caches. The AddressableNode implementation currently serializes: > * org.jgroups.Address > * The logical name (typically a host name) > * The socket binding address/port of its transport > This is overkill. The Node should only need to serialize enough information to reconstruct itself using a NodeFactory<Address>, which should only include: > * its Address > * something to minimally identify the NodeFactory<Address>, with which to use to reconstruct the Node, e.g. a group name > Unfortunately, getting a reference to the NodeFactory during deserialization isn't trivial, as these are on-demand services. > Another approach, is to avoid referencing the Node in cache keys/values altogether. Currently, Registry<K, V> uses a Cache<Node, Map.Entry<K, V>> and ServiceProviderRegistry<K> uses a Cache<K, Set<Node>>. In both cases, we can replace Node with Address, and thus avoid unnecessary marshalling of the logical name and physical address of a member. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9521) Marshalling of org.wildfly.clustering.group.Node implementations is suboptimal

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-9521?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-9521: ------------------------------- Description: Both the org.wildfly.clustering.registry.Registry and org.wildfly.clustering.provider.ServiceProviderRegistry currently store references to a Node object in their respective caches. The AddressableNode implementation currently serializes: * org.jgroups.Address * The logical name (typically a host name) * The socket binding address/port of its transport This is overkill. The Node should only need to serialize enough information to reconstruct itself using a NodeFactory<Address>, which should only include: * its Address * something to minimally identify the NodeFactory<Address>, with which to use to reconstruct the Node, e.g. a group name Unfortunately, getting a reference to the NodeFactory during deserialization isn't trivial, as these are on-demand services. Another approach, is to avoid referencing the Node in cache keys/values altogether. Currently, Registry<K, V> uses a Cache<Node, Map.Entry<K, V>> and ServiceProviderRegistry<K> uses a Cache<K, Set<Node>>. In both cases, we can replace Node with Address, and thus avoid unnecessary marshalling of the logical name and physical address of a member. was: The Node implementations currently serialize: * org.jgroups.Address * The logical name (typically a host name) * The socket binding address/port of its transport This is overkill. The Node should only need to serialize enough information to reconstruct itself using a NodeFactory<Address>, which should only include: * its Address * something to minimally identify the NodeFactory<Address>, with which to use to reconstruct the Node, e.g. a group name Unfortunately, getting a reference to the NodeFactory during deserialization isn't trivial, as these are on-demand services. Another approach, is to avoid referencing the Node in cache keys/values altogether. Currently, org.wildfly.clustering.registry.Registry uses a Cache<Node, Map.Entry<K, V>> and org.wildfly.clustering.provider.ServiceProviderRegistry uses a Cache<K, Set<Node>>. In both cases, we can replace Node with Address, and thus avoid unnecessary marshalling of the logical name and physical address of a member. > Marshalling of org.wildfly.clustering.group.Node implementations is suboptimal > ------------------------------------------------------------------------------ > > Key: WFLY-9521 > URL: https://issues.jboss.org/browse/WFLY-9521 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Both the org.wildfly.clustering.registry.Registry and org.wildfly.clustering.provider.ServiceProviderRegistry currently store references to a Node object in their respective caches. The AddressableNode implementation currently serializes: > * org.jgroups.Address > * The logical name (typically a host name) > * The socket binding address/port of its transport > This is overkill. The Node should only need to serialize enough information to reconstruct itself using a NodeFactory<Address>, which should only include: > * its Address > * something to minimally identify the NodeFactory<Address>, with which to use to reconstruct the Node, e.g. a group name > Unfortunately, getting a reference to the NodeFactory during deserialization isn't trivial, as these are on-demand services. > Another approach, is to avoid referencing the Node in cache keys/values altogether. Currently, Registry<K, V> uses a Cache<Node, Map.Entry<K, V>> and ServiceProviderRegistry<K> uses a Cache<K, Set<Node>>. In both cases, we can replace Node with Address, and thus avoid unnecessary marshalling of the logical name and physical address of a member. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2466) Static imports in generated executable model dsl can cause method name clashes

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2466: ----------------------------------- Summary: Static imports in generated executable model dsl can cause method name clashes Key: DROOLS-2466 URL: https://issues.jboss.org/browse/DROOLS-2466 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 April 2018