[JBoss JIRA] (JGRP-2277) GMS: change the way a coordinator leaves gracefully
by Bela Ban (JIRA)
Bela Ban created JGRP-2277:
------------------------------
Summary: GMS: change the way a coordinator leaves gracefully
Key: JGRP-2277
URL: https://issues.jboss.org/browse/JGRP-2277
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0.13
Consider a cluster \{A,B,C,D\} with view A|5.
There's a discrepancy in handling coordinator A (1) leaving gracefully and (2) crashing.
When A crashes, the second-in-line (B) will install new view B|6=\{B,C,D\} in the cluster.
However, when A leaves _gracefully_, then *A itself* installs view B|6=\{B,C,D\}. The problem with this is that A is not able to retransmit the {{VIEW}} message to a member which dropped it, so inconsistencies may arise, which have to be healed by {{MERGE3}} (see JGRP-2276 for a description).
A better scheme would be for A to send a LEAVE message to the second-in-line (B), which then creates and installs view B|6, and then replies with a {{LEAVE_RSP}} message to A.
This has the following advantages:
* The code for handling a crashed coordinator, and a coordinator which leaves gracefully, is similar, and in both cases the second-in-line member installs the new view
* The second-in-line (B) stays up and can therefore retransmit a dropped {{VIEW}} message (contrary to A which terminates after a timeout). As long as A is able to send a {{LEAVE-REQ}} to B, B will handle it. If A crashes, B can also handle the view installation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SWSQE-294) Investigate ElasticSearch memory requirements on B24 cluster
by Kevin Earls (JIRA)
[ https://issues.jboss.org/browse/SWSQE-294?page=com.atlassian.jira.plugin.... ]
Kevin Earls commented on SWSQE-294:
-----------------------------------
Hi [~gbaufake] . I'll attach a log, but I'm not sure it will help. The one I'm attaching is from a node that failed after 1 of the other nodes got the OOMKilled action. I was doing a "oc logs -f" on all nodes, but the problem is that when a node is killed it just terminates. There's nothing of interest in the log. I'm guessing we'd need to figure out who is killing it and look at their log.
You might want to try creating a temporary project and doing the curl and oc create steps above, that may give you more info.
> Investigate ElasticSearch memory requirements on B24 cluster
> ------------------------------------------------------------
>
> Key: SWSQE-294
> URL: https://issues.jboss.org/browse/SWSQE-294
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Kevin Earls
> Assignee: Guilherme Baufaker Rêgo
> Priority: Minor
> Attachments: es1.log
>
>
> On minishift and the CNCF CI OpenShift cluster, we install ElasticSearch using the commands:
> curl https://raw.githubusercontent.com/RHsyseng/docker-rhel-elasticsearch/5.x/... --output es-cluster-deployment.yml
> oc create -f es-cluster-deployment.yml
> However, on B24 this fails. The first 2 elasticsearch pods will start up, but then elasticsearch-2 gets into the following failure loop like:
> elasticsearch-2 1/1 Running 3 1m
> elasticsearch-2 0/1 OOMKilled 3 1m
> elasticsearch-2 0/1 CrashLoopBackOff 3 2m
> If I increase memory in the es-cluster-deployment.yml to 1Gi it will at least start, but I've found I really need to increase it to 2Gi to do anything non trivial.
> We may need to track down the people who originally created this template for help on this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SWSQE-294) Investigate ElasticSearch memory requirements on B24 cluster
by Kevin Earls (JIRA)
[ https://issues.jboss.org/browse/SWSQE-294?page=com.atlassian.jira.plugin.... ]
Kevin Earls updated SWSQE-294:
------------------------------
Attachment: es1.log
> Investigate ElasticSearch memory requirements on B24 cluster
> ------------------------------------------------------------
>
> Key: SWSQE-294
> URL: https://issues.jboss.org/browse/SWSQE-294
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Kevin Earls
> Assignee: Guilherme Baufaker Rêgo
> Priority: Minor
> Attachments: es1.log
>
>
> On minishift and the CNCF CI OpenShift cluster, we install ElasticSearch using the commands:
> curl https://raw.githubusercontent.com/RHsyseng/docker-rhel-elasticsearch/5.x/... --output es-cluster-deployment.yml
> oc create -f es-cluster-deployment.yml
> However, on B24 this fails. The first 2 elasticsearch pods will start up, but then elasticsearch-2 gets into the following failure loop like:
> elasticsearch-2 1/1 Running 3 1m
> elasticsearch-2 0/1 OOMKilled 3 1m
> elasticsearch-2 0/1 CrashLoopBackOff 3 2m
> If I increase memory in the es-cluster-deployment.yml to 1Gi it will at least start, but I've found I really need to increase it to 2Gi to do anything non trivial.
> We may need to track down the people who originally created this template for help on this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10520) Add Hibernate ORM 5.3 compatibility transformer
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10520?page=com.atlassian.jira.plugin... ]
Scott Marlow edited comment on WFLY-10520 at 6/13/18 10:13 AM:
---------------------------------------------------------------
Note from [~gbadner]:
{quote}
I ran a simple test that executed:
s.createQuery( "from A" ).setMaxResults( 0 ).list()
When built with 5.1, it returns all A entities.
When built with 5.3, it returns an empty list.
This is not good.
{quote}
I can think of two options:
# If the WF bytecode transformer doesn't handle Query#getMaxResults, then the application will need to be rewritten to properly use the new Query#getMaxResults as well as Query#setMaxResults() behaviour.
# Other approach might be for the WF bytecode transformer to check for calls to Query#setMaxResults and rewrite the bytecode to work, not that we know yet, what code changes are needed to make the 5.1 app code work with 5.3 yet (Gail?).
A concern about the second approach of the transformer going a bit deeper into application code rewriting, is if the Hibernate team fixes a bug in 5.3.x that impacts the setMaxResults behaviour, the transformer would also need to be fixed as well.
was (Author: smarlow):
Note from [~gbadner]:
{quote}
I ran a simple test that executed:
s.createQuery( "from A" ).setMaxResults( 0 ).list()
When built with 5.1, it returns all A entities.
When built with 5.3, it returns an empty list.
This is not good.
{quote}
I can think of two options:
# If the WF bytecode transformer doesn't handle Query#getMaxResults, then the application will need to be rewritten to properly use the new Query#getMaxResults as well as Query#setMaxResults() behaviour.
# Other approach might be for the WF bytecode transformer to check for calls to Query#setMaxResults and rewrite the bytecode to work.
> Add Hibernate ORM 5.3 compatibility transformer
> -----------------------------------------------
>
> Key: WFLY-10520
> URL: https://issues.jboss.org/browse/WFLY-10520
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Scott Marlow
> Fix For: 14.0.0.CR1
>
>
> A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1.
> From https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-w...
> # Change call to org.hibernate.BasicQueryContract.getFlushMode() to instead call BasicQueryContract.getHibernateFlushMode().
> # Change call to org.hibernate.Session.getFlushMode, to instead call Session.getHibernateFlushMode()
> # Modify calls to org.hibernate.Query.getFirstResult() to convert returned int, to Integer result.
> # Modify calls to org.hibernate.Query.getMaxResults() to convert returned int, to Integer result, if returned int value is <= 0, null should be used, if Integer.MAX_VALUE is, the transformer should replace with null reference.
> # App References to Enum org.hibernate.FlushMode.NEVER (0) should be transformed to reference FlushMode.MANUAL (0) instead.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10411) TLDs under META-INF/resources inside the web-fragment jar is not loaded
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-10411?page=com.atlassian.jira.plugin... ]
Tomas Hofman reassigned WFLY-10411:
-----------------------------------
Assignee: Tomas Hofman (was: Stuart Douglas)
> TLDs under META-INF/resources inside the web-fragment jar is not loaded
> -----------------------------------------------------------------------
>
> Key: WFLY-10411
> URL: https://issues.jboss.org/browse/WFLY-10411
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 13.0.0.Beta1
> Reporter: Masafumi Miura
> Assignee: Tomas Hofman
> Attachments: jsp-taglib-jar-in-war.zip
>
>
> TLDs under META-INF/resources inside the web-fragment jar is not loaded.
> {code:title=directory structure of the web-fragment jar}
> taglib-jar
> |-- META-INF
> | |-- resources
> | | `-- WEB-INF
> | | `-- tlds
> | | `-- hi.tld
> | `-- web-fragment.xml
> `-- simple
> `-- HiTag.class
> {code}
> {code:title=web-fragment.xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <web-fragment id="WebFragment_ID"
> version="3.0"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd">
> ...(snip)...
> <jsp-config>
> <taglib>
> <taglib-uri>/HiTag</taglib-uri>
> <taglib-location>/WEB-INF/tlds/hi.tld</taglib-location>
> </taglib>
> </jsp-config>
> </web-fragment>
> {code}
> The following ERROR is thrown at the deployment:
> {code}
> ERROR [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0074: Could not find TLD /WEB-INF/tlds/hi.tld
> {code}
> JSP returns "500 Internal Server Error" and Jastow throws the following ERROR when accessing the JSP which has {{<%@ taglib uri="/HiTag" prefix="say"%>}} or {{<%@ taglib uri="/WEB-INF/tlds/hi.tld" prefix="say"%>}}:
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /taglib-jar-in-war/hi.jsp: org.apache.jasper.JasperException: JBWEB004036: File "/HiTag" not found
> at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:57)
> at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:278)
> at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:75)
> at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:171)
> at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:412)
> at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:475)
> at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1459)
> at org.apache.jasper.compiler.Parser.parse(Parser.java:143)
> at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:223)
> at org.apache.jasper.compiler.ParserController.parse(ParserController.java:102)
> at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:200)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
> at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...(snip)...
> {code}
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /taglib-jar-in-war/index.jsp: org.apache.jasper.JasperException: JBWEB004036: File "/WEB-INF/tlds/hi.tld" not found
> at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:57)
> at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:278)
> at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:75)
> at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:171)
> at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:412)
> at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:475)
> at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1459)
> at org.apache.jasper.compiler.Parser.parse(Parser.java:143)
> at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:223)
> at org.apache.jasper.compiler.ParserController.parse(ParserController.java:102)
> at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:200)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
> at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...(snip)...
> {code}
> Note that the same war file can be deployed and the JSPs works on Tomcat 8.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10520) Add Hibernate ORM 5.3 compatibility transformer
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10520?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-10520:
-------------------------------------
Note from [~gbadner]:
{quote}
I ran a simple test that executed:
s.createQuery( "from A" ).setMaxResults( 0 ).list()
When built with 5.1, it returns all A entities.
When built with 5.3, it returns an empty list.
This is not good.
{quote}
I can think of two options:
# If the WF bytecode transformer doesn't handle Query#getMaxResults, then the application will need to be rewritten to properly use the new Query#getMaxResults as well as Query#setMaxResults() behaviour.
# Other approach might be for the WF bytecode transformer to check for calls to Query#setMaxResults and rewrite the bytecode to work.
> Add Hibernate ORM 5.3 compatibility transformer
> -----------------------------------------------
>
> Key: WFLY-10520
> URL: https://issues.jboss.org/browse/WFLY-10520
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Scott Marlow
> Fix For: 14.0.0.CR1
>
>
> A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1.
> From https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-w...
> # Change call to org.hibernate.BasicQueryContract.getFlushMode() to instead call BasicQueryContract.getHibernateFlushMode().
> # Change call to org.hibernate.Session.getFlushMode, to instead call Session.getHibernateFlushMode()
> # Modify calls to org.hibernate.Query.getFirstResult() to convert returned int, to Integer result.
> # Modify calls to org.hibernate.Query.getMaxResults() to convert returned int, to Integer result, if returned int value is <= 0, null should be used, if Integer.MAX_VALUE is, the transformer should replace with null reference.
> # App References to Enum org.hibernate.FlushMode.NEVER (0) should be transformed to reference FlushMode.MANUAL (0) instead.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month