April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11990) Separate opentracing from observability layer

by Jean Francois Denise (Jira)

Jean Francois Denise created WFLY-11990: ------------------------------------------- Summary: Separate opentracing from observability layer Key: WFLY-11990 URL: https://issues.jboss.org/browse/WFLY-11990 Project: WildFly Issue Type: Feature Request Components: Build System Reporter: Jean Francois Denise Assignee: Jean Francois Denise It appears that the opentracing should have its own dedicated layer. observability layer not including it. cloud-profile not including it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4421) Upgrade JBoss Remoting from 5.0.8 to 5.0.9

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFCORE-4421?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFCORE-4421: ---------------------------------- Labels: downstream_dependency (was: ) > Upgrade JBoss Remoting from 5.0.8 to 5.0.9 > ------------------------------------------ > > Key: WFCORE-4421 > URL: https://issues.jboss.org/browse/WFCORE-4421 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > Labels: downstream_dependency > > https://github.com/jboss-remoting/jboss-remoting/compare/5.0.8.Final...5.0 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4421) Upgrade JBoss Remoting from 5.0.8 to 5.0.9

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFCORE-4421?page=com.atlassian.jira.plugi... ] Ilia Vassilev reassigned WFCORE-4421: ------------------------------------- Assignee: Flavia Rainone (was: Ilia Vassilev) > Upgrade JBoss Remoting from 5.0.8 to 5.0.9 > ------------------------------------------ > > Key: WFCORE-4421 > URL: https://issues.jboss.org/browse/WFCORE-4421 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Flavia Rainone > Priority: Major > Labels: downstream_dependency > > https://github.com/jboss-remoting/jboss-remoting/compare/5.0.8.Final...5.0 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4421) Upgrade JBoss Remoting from 5.0.8 to 5.0.9

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFCORE-4421?page=com.atlassian.jira.plugi... ] Ilia Vassilev moved JBEAP-16734 to WFCORE-4421: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-4421 (was: JBEAP-16734) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Build System (was: Build System) Fix Version/s: (was: 7.2.2.GA) > Upgrade JBoss Remoting from 5.0.8 to 5.0.9 > ------------------------------------------ > > Key: WFCORE-4421 > URL: https://issues.jboss.org/browse/WFCORE-4421 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > > https://github.com/jboss-remoting/jboss-remoting/compare/5.0.8.Final...5.0 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2334) TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2334?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2334: --------------------------- Fix Version/s: 4.1.0 (was: 4.1.1) > TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses > ----------------------------------------------------------------------------- > > Key: JGRP-2334 > URL: https://issues.jboss.org/browse/JGRP-2334 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 4.0.19 > Reporter: Falco Thiel > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.0 > > > We want to discuss a change in the TCPPing module. > We plan to run wildfly instances in a container orchestration system. In the system which we want to use, the node discovery over multicast is not working. > The other solution is to use TCPPing with initial_hosts set. But now we have to solve the following problems: > * the initial_hosts property is not very dynamic > * the ip addresses will/can change if a container is restarted > * the host names are dynamically generated > At this point it seems the node discovery can not be done with TCPPing, at least not in an easy way. > The main problem: How to find out all running nodes for a server group? > Now we investigate our orchestration system and find a solution to solve the problem. Our orchestration system (and we think others will have this too) has an internal DNS service. > Over this service all containers for a dns name can be resolved with a nslookup request. > Example: > We have a scalable wildfly service. We name it "wildfly-server". If a container under this service is started then the container gets a host name like "wildfly-server-0" and a dynamic ip address. > After starting one or more container we can do a nslookup with the service name: > >nslookup wildfly-server > Name: wildfly-server > Address 1: 10.42.2.139 wildfly-server-1.wildfly-server > Address 2: 10.42.1.198 wildfly-server-0.wildfly-server > Address 3: 10.42.0.161 wildfly-server-2.wildfly-server > The service name has multiple A-Records registered. If an instance is started or stopped then the DNS Records are updated. Now we tried to use this service name for the initial_hosts property. > initial_hosts=wildfly-server[7600] > Sometimes it worked and sometimes it doesn't. The reason was that only the first InetAddress entry was used in the org.jgroups.util.Util class (method parseCommaDelimitedHosts). After we changed it a bit (see [https://github.com/Sternwald-Systems/JGroups/commit/db0b899f9c67348a0cb07...] ) it worked as expected. What we do is to call InetAddress.getAllByName(host) and loop over the result array, instead of just using the first array element. > There is only one limitation if the domain mode with more than one server group is used. Here the same port offset for all servers of one server group must be set. > *Conclusion* > There are different orchestration systems available on the market. The worst case will be to write a custom discovery service for jgroups for each of them. > For instance for the kubernetes system there already exists such a service (jgroups-kubernetes). > But if an orchestration system already has an internal DNS service to resolve a dns name to get all running containers TCPPing (with our changes) could be used out of the box. > Additionally there is a second method in the org.jgroups.util.Util class called parseCommaDelimitedHosts2 which does nearly the same but for the TCPGossip protocol. > We think it would make sense to change this method too, otherwise there are different behaviors. I you don't mind, we would apply the changes to this method too, before creating a pull request. > It is also important to document this well so other people can find this information if they have the same problem. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2333) pbcast.GMS#getView returns ViewId as opposed to the View

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2333?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2333: --------------------------- Fix Version/s: 4.1.0 (was: 4.1.1) > pbcast.GMS#getView returns ViewId as opposed to the View > -------------------------------------------------------- > > Key: JGRP-2333 > URL: https://issues.jboss.org/browse/JGRP-2333 > Project: JGroups > Issue Type: Bug > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 4.1.0 > > > Basically org.jgroups.protocols.pbcast.GMS#getView is now identical to org.jgroups.protocols.pbcast.GMS#getViewId while the intention is to be able to see the current view. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3885) Implement POC of tests for HA CEP

by Jiri Petrlik (Jira)

[ https://issues.jboss.org/browse/DROOLS-3885?page=com.atlassian.jira.plugi... ] Jiri Petrlik updated DROOLS-3885: --------------------------------- Story Points: 5 > Implement POC of tests for HA CEP > --------------------------------- > > Key: DROOLS-3885 > URL: https://issues.jboss.org/browse/DROOLS-3885 > Project: Drools > Issue Type: Task > Reporter: Jiri Petrlik > Assignee: Jiri Petrlik > Priority: Major > > Implement proof of concept of tests for HA CEP. Will use example from milestone 1 in https://github.com/desmax74/openshift-hacep/tree/master/client-producer and try to convert it to test. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11116) Wildfly 12.0.0 Final Delay in Getting the Value Attributes of the Session Variables (Result in Null Pointer Exception)

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11116?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-11116: ------------------------------------- {quote}I noticed that the problem is only with Session Bean variables (session.getAttribute("testBean") ) where other Session variable are passing correctly, Note that in the provided example there only two variable in the testBean however in the reproduced scenario there's 30 variables, which causing the load delay.{quote} This is the first that you mentioned that the problematic session attribute is a SFSB. The code in the description certainly makes no indication of this (new TestBean() is not how SFSBs are created). Something is definitely not right - and without source code I can't tell exactly what. I would suggest the following. Don't store your SFSB in the session directly, but make use of contextualized EJBs. Specifically, annotate your SFSB with @SessionScoped. You can then inject it (via @EJB) into your Servlet - and let the contain manage its lifecycle and association with the session. The SFSB will be automatically removed when it goes out of scope (i.e. when the session is destroyed). > Wildfly 12.0.0 Final Delay in Getting the Value Attributes of the Session Variables (Result in Null Pointer Exception) > ---------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-11116 > URL: https://issues.jboss.org/browse/WFLY-11116 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 14.0.1.Final, 12.0.0.Final, 13.0.0.Final, 15.0.0.Final > Reporter: ziad saade > Assignee: Paul Ferraro > Priority: Critical > > I have two Servlets Book and BookPreview the attribute is set in Book Servlet as follow: > > Book.java > TestBean testBean=null; > if(session.getAttribute("testBean")!=null) > testBean = (TestBean)session.getAttribute("testBean"); > else{ > testBean=new TestBean(); > session.setAttribute("testBean",testBean); > } > testBean.setAmount("10"); > > response.sendRedirect("BookPreview"); > > > The session attribute can be retrieved and the page is loaded normally and the Amount value is displayed however when submitting the form (Post Action in BookPreview.java) Null Pointer exception is generated. > > BookPreview.java > > TestBean testBean = (TestBean)session.getAttribute("testBean"); > String amount = testBean.getAmount; //Null pointer exception when submitting the form > > <form method="Post" action="BookPreview"> > > </form> > > TestBean.java > > public class TestBean implements java.io.Serializable { > > private static final long serialVersionUID = 1L; > private String amount; > > public String getAmount() { > return amount; > } > > public void setAmount(String amount) { > this.amount = amount; > } > } > > Kindly advice how to fix the problem at the level of the server configuration. > PS: I am not getting the exception when deploying the same application under other J EE application servers (Tomcat....) > > Thanks and Best Regards -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3885) Implement POC of tests for HA CEP

by Jiri Petrlik (Jira)

[ https://issues.jboss.org/browse/DROOLS-3885?page=com.atlassian.jira.plugi... ] Jiri Petrlik updated DROOLS-3885: --------------------------------- Sprint: 2019 Week 14-16 > Implement POC of tests for HA CEP > --------------------------------- > > Key: DROOLS-3885 > URL: https://issues.jboss.org/browse/DROOLS-3885 > Project: Drools > Issue Type: Task > Reporter: Jiri Petrlik > Assignee: Jiri Petrlik > Priority: Major > > Implement proof of concept of tests for HA CEP. Will use example from milestone 1 in https://github.com/desmax74/openshift-hacep/tree/master/client-producer and try to convert it to test. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3885) Implement POC of tests for HA CEP

by Jiri Petrlik (Jira)

Jiri Petrlik created DROOLS-3885: ------------------------------------ Summary: Implement POC of tests for HA CEP Key: DROOLS-3885 URL: https://issues.jboss.org/browse/DROOLS-3885 Project: Drools Issue Type: Task Reporter: Jiri Petrlik Assignee: Jiri Petrlik Implement proof of concept of tests for HA CEP. Will use example from milestone 1 in https://github.com/desmax74/openshift-hacep/tree/master/client-producer and try to convert it to test. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 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 2019