July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12310) JPA (Hibernate) second level cache (additional) testing requirements

by Tommasso Borgato (Jira)

[ https://issues.jboss.org/browse/WFLY-12310?page=com.atlassian.jira.plugin... ] Tommasso Borgato reassigned WFLY-12310: --------------------------------------- Assignee: Tommasso Borgato (was: Scott Marlow) > JPA (Hibernate) second level cache (additional) testing requirements > -------------------------------------------------------------------- > > Key: WFLY-12310 > URL: https://issues.jboss.org/browse/WFLY-12310 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Reporter: Tommasso Borgato > Assignee: Tommasso Borgato > Priority: Major > Labels: EAP-CD18 > Fix For: 18.0.0.Beta1 > > > This jira is a placeholder for collecting requirements for (additional) JPA second level cache testing. I asked [~stephen.fikes] for his input here, as he has helped many customers with various 2lc issues. > Others are welcome to add ideas here as well, as to what additional 2lc testing we should do in the WF or external QE testsuite. > Current 2lc tests in WildFly (external QE testsuite has zero 2lc tests): > # Clustered test [https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clus...] > # Clustered extended persistence context failover test [https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clus...] > # non-JPA testing [https://github.com/wildfly/wildfly/tree/master/testsuite/integration/basi...] > # JPA testing [https://github.com/wildfly/wildfly/tree/master/testsuite/integration/basi...] -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12310) JPA (Hibernate) second level cache (additional) testing requirements

by Tommasso Borgato (Jira)

[ https://issues.jboss.org/browse/WFLY-12310?page=com.atlassian.jira.plugin... ] Tommasso Borgato updated WFLY-12310: ------------------------------------ Issue Type: Task (was: Bug) > JPA (Hibernate) second level cache (additional) testing requirements > -------------------------------------------------------------------- > > Key: WFLY-12310 > URL: https://issues.jboss.org/browse/WFLY-12310 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Tommasso Borgato > Assignee: Tommasso Borgato > Priority: Major > Labels: EAP-CD18 > Fix For: 18.0.0.Beta1 > > > This jira is a placeholder for collecting requirements for (additional) JPA second level cache testing. I asked [~stephen.fikes] for his input here, as he has helped many customers with various 2lc issues. > Others are welcome to add ideas here as well, as to what additional 2lc testing we should do in the WF or external QE testsuite. > Current 2lc tests in WildFly (external QE testsuite has zero 2lc tests): > # Clustered test [https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clus...] > # Clustered extended persistence context failover test [https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clus...] > # non-JPA testing [https://github.com/wildfly/wildfly/tree/master/testsuite/integration/basi...] > # JPA testing [https://github.com/wildfly/wildfly/tree/master/testsuite/integration/basi...] -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12310) JPA (Hibernate) second level cache (additional) testing requirements

by Tommasso Borgato (Jira)

Tommasso Borgato created WFLY-12310: --------------------------------------- Summary: JPA (Hibernate) second level cache (additional) testing requirements Key: WFLY-12310 URL: https://issues.jboss.org/browse/WFLY-12310 Project: WildFly Issue Type: Bug Components: JPA / Hibernate Reporter: Tommasso Borgato Assignee: Scott Marlow Fix For: 18.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12310) JPA (Hibernate) second level cache (additional) testing requirements

by Tommasso Borgato (Jira)

[ https://issues.jboss.org/browse/WFLY-12310?page=com.atlassian.jira.plugin... ] Tommasso Borgato updated WFLY-12310: ------------------------------------ Description: This jira is a placeholder for collecting requirements for (additional) JPA second level cache testing. I asked [~stephen.fikes] for his input here, as he has helped many customers with various 2lc issues. Others are welcome to add ideas here as well, as to what additional 2lc testing we should do in the WF or external QE testsuite. Current 2lc tests in WildFly (external QE testsuite has zero 2lc tests): # Clustered test [https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clus...] # Clustered extended persistence context failover test [https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clus...] # non-JPA testing [https://github.com/wildfly/wildfly/tree/master/testsuite/integration/basi...] # JPA testing [https://github.com/wildfly/wildfly/tree/master/testsuite/integration/basi...] > JPA (Hibernate) second level cache (additional) testing requirements > -------------------------------------------------------------------- > > Key: WFLY-12310 > URL: https://issues.jboss.org/browse/WFLY-12310 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Reporter: Tommasso Borgato > Assignee: Scott Marlow > Priority: Major > Labels: EAP-CD18 > Fix For: 18.0.0.Beta1 > > > This jira is a placeholder for collecting requirements for (additional) JPA second level cache testing. I asked [~stephen.fikes] for his input here, as he has helped many customers with various 2lc issues. > Others are welcome to add ideas here as well, as to what additional 2lc testing we should do in the WF or external QE testsuite. > Current 2lc tests in WildFly (external QE testsuite has zero 2lc tests): > # Clustered test [https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clus...] > # Clustered extended persistence context failover test [https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clus...] > # non-JPA testing [https://github.com/wildfly/wildfly/tree/master/testsuite/integration/basi...] > # JPA testing [https://github.com/wildfly/wildfly/tree/master/testsuite/integration/basi...] -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2363) DNS Ping cannot lookup SRV record for service port

by Howard Gao (Jira)

[ https://issues.jboss.org/browse/JGRP-2363?page=com.atlassian.jira.plugin.... ] Howard Gao updated JGRP-2363: ----------------------------- Attachment: App2.java > DNS Ping cannot lookup SRV record for service port > -------------------------------------------------- > > Key: JGRP-2363 > URL: https://issues.jboss.org/browse/JGRP-2363 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.20 > Reporter: Howard Gao > Assignee: Bela Ban > Priority: Major > Attachments: App2.java > > > I've got a problem regarding getting service port in DNS_PING DNS lookup. > It seems in my openshift environment the JNDI DNS lookup cannot query the > correct SRV record from the openshift DNS server. Ref: > https://github.com/jboss-openshift/openshift-ping/blob/1.2.1.Final/dns/sr... > For example, here is the ping service: > apiVersion: v1 > kind: Service > metadata: > annotations: > description: The JGroups ping port for clustering. > service.alpha.kubernetes.io/tolerate-unready-endpoints: 'true' > labels: > application: application0 > template: amq-broker-73-persistence-clustered > xpaas: 1.4.16 > name: application0-ping > spec: > clusterIP: None > publishNotReadyAddresses: true > ports: > port: 8888 > protocol: TCP > name: jgroup-port > targetPort: 8888 > selector: > deploymentConfig: application0-amq > After it is deployed I deployed a application pod > with JGroups DNS_PING protocol loaded. The relevant > jgroups xml part looks like this: > <config> ... <openshift.DNS_PING timeout="3000" serviceName="application0-ping" /> ... </config> > After my application pod is in running state, I checked the log > and there is a warning message from DNS_PING: > 2019-07-22 04:16:59,600 INFO [org.openshift.ping.common.Utils] 3 attempt(s) with a 1000ms sleep to execute [GetServicePort] failed. Last failure was [java.lang.NullPointerException: null] > 2019-07-22 04:16:59,601 WARNING [org.jgroups.protocols.openshift.DNS_PING] No DNS SRV record found for service [application0-ping] > After some debugging it turns out that the DNS lookup for the record by this name > "_tcp.application0-ping" returned null. > However if I logged into the application pod and do nslookup it will give me correct record: > sh-5.0# nslookup -type=srv _tcp.application0-ping > Server: 10.74.177.77 > Address: 10.74.177.77#53 > _tcp.application0-ping.default.svc.cluster.local service = 10 100 8888 44c84e52.application0-ping.default.svc.cluster.local. > And you can get the full name from the record, which is > _tcp.application0-ping.default.svc.cluster.local > If I then pass the full qualified name into the application and it can query the SRV > record successfully. > I have no idea why my application can't query the record using the short form name (i.e. _tcp.application0-ping). Could it be some configuration issue for the DNS ping? > My openshift env details are: > oc v3.11.117 > kubernetes v1.11.0+d4cacc0 > features: Basic-Auth GSSAPI Kerberos SPNEGO > and the java version used in pod: > sh-5.0# java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-b04) > OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode) > and the base OS is fedora 30. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2363) DNS Ping cannot lookup SRV record for service port

by Howard Gao (Jira)

[ https://issues.jboss.org/browse/JGRP-2363?page=com.atlassian.jira.plugin.... ] Howard Gao commented on JGRP-2363: ---------------------------------- upstream ref: https://github.com/jboss-openshift/openshift-ping/issues/45 > DNS Ping cannot lookup SRV record for service port > -------------------------------------------------- > > Key: JGRP-2363 > URL: https://issues.jboss.org/browse/JGRP-2363 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.20 > Reporter: Howard Gao > Assignee: Bela Ban > Priority: Major > > I've got a problem regarding getting service port in DNS_PING DNS lookup. > It seems in my openshift environment the JNDI DNS lookup cannot query the > correct SRV record from the openshift DNS server. Ref: > https://github.com/jboss-openshift/openshift-ping/blob/1.2.1.Final/dns/sr... > For example, here is the ping service: > apiVersion: v1 > kind: Service > metadata: > annotations: > description: The JGroups ping port for clustering. > service.alpha.kubernetes.io/tolerate-unready-endpoints: 'true' > labels: > application: application0 > template: amq-broker-73-persistence-clustered > xpaas: 1.4.16 > name: application0-ping > spec: > clusterIP: None > publishNotReadyAddresses: true > ports: > port: 8888 > protocol: TCP > name: jgroup-port > targetPort: 8888 > selector: > deploymentConfig: application0-amq > After it is deployed I deployed a application pod > with JGroups DNS_PING protocol loaded. The relevant > jgroups xml part looks like this: > <config> ... <openshift.DNS_PING timeout="3000" serviceName="application0-ping" /> ... </config> > After my application pod is in running state, I checked the log > and there is a warning message from DNS_PING: > 2019-07-22 04:16:59,600 INFO [org.openshift.ping.common.Utils] 3 attempt(s) with a 1000ms sleep to execute [GetServicePort] failed. Last failure was [java.lang.NullPointerException: null] > 2019-07-22 04:16:59,601 WARNING [org.jgroups.protocols.openshift.DNS_PING] No DNS SRV record found for service [application0-ping] > After some debugging it turns out that the DNS lookup for the record by this name > "_tcp.application0-ping" returned null. > However if I logged into the application pod and do nslookup it will give me correct record: > sh-5.0# nslookup -type=srv _tcp.application0-ping > Server: 10.74.177.77 > Address: 10.74.177.77#53 > _tcp.application0-ping.default.svc.cluster.local service = 10 100 8888 44c84e52.application0-ping.default.svc.cluster.local. > And you can get the full name from the record, which is > _tcp.application0-ping.default.svc.cluster.local > If I then pass the full qualified name into the application and it can query the SRV > record successfully. > I have no idea why my application can't query the record using the short form name (i.e. _tcp.application0-ping). Could it be some configuration issue for the DNS ping? > My openshift env details are: > oc v3.11.117 > kubernetes v1.11.0+d4cacc0 > features: Basic-Auth GSSAPI Kerberos SPNEGO > and the java version used in pod: > sh-5.0# java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-b04) > OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode) > and the base OS is fedora 30. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4317) [DMN Designer] Documentation - Add the "Download .html file" button to the documentation tab

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4317?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-4317: -------------------------------- Description: Add a regular button into the Documentation tab: !component-3.png|thumbnail! h3. Manual Acceptance Test Using Chrome and Firefox - Download and open in new tab - Download twice, update (do not save) diagram between downloads - Download two different - Download for file with multibyte characters in name - Download for file with white space characters in name was: Add a regular button into the Documentation tab: !component-3.png|thumbnail! > [DMN Designer] Documentation - Add the "Download .html file" button to the documentation tab > -------------------------------------------------------------------------------------------- > > Key: DROOLS-4317 > URL: https://issues.jboss.org/browse/DROOLS-4317 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools > Attachments: component-3.png > > > Add a regular button into the Documentation tab: > !component-3.png|thumbnail! > h3. Manual Acceptance Test > Using Chrome and Firefox > - Download and open in new tab > - Download twice, update (do not save) diagram between downloads > - Download two different > - Download for file with multibyte characters in name > - Download for file with white space characters in name -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2363) DNS Ping cannot lookup SRV record for service port

by Howard Gao (Jira)

Howard Gao created JGRP-2363: -------------------------------- Summary: DNS Ping cannot lookup SRV record for service port Key: JGRP-2363 URL: https://issues.jboss.org/browse/JGRP-2363 Project: JGroups Issue Type: Bug Affects Versions: 4.0.20 Reporter: Howard Gao Assignee: Bela Ban I've got a problem regarding getting service port in DNS_PING DNS lookup. It seems in my openshift environment the JNDI DNS lookup cannot query the correct SRV record from the openshift DNS server. Ref: https://github.com/jboss-openshift/openshift-ping/blob/1.2.1.Final/dns/sr... For example, here is the ping service: apiVersion: v1 kind: Service metadata: annotations: description: The JGroups ping port for clustering. service.alpha.kubernetes.io/tolerate-unready-endpoints: 'true' labels: application: application0 template: amq-broker-73-persistence-clustered xpaas: 1.4.16 name: application0-ping spec: clusterIP: None publishNotReadyAddresses: true ports: port: 8888 protocol: TCP name: jgroup-port targetPort: 8888 selector: deploymentConfig: application0-amq After it is deployed I deployed a application pod with JGroups DNS_PING protocol loaded. The relevant jgroups xml part looks like this: <config> ... <openshift.DNS_PING timeout="3000" serviceName="application0-ping" /> ... </config> After my application pod is in running state, I checked the log and there is a warning message from DNS_PING: 2019-07-22 04:16:59,600 INFO [org.openshift.ping.common.Utils] 3 attempt(s) with a 1000ms sleep to execute [GetServicePort] failed. Last failure was [java.lang.NullPointerException: null] 2019-07-22 04:16:59,601 WARNING [org.jgroups.protocols.openshift.DNS_PING] No DNS SRV record found for service [application0-ping] After some debugging it turns out that the DNS lookup for the record by this name "_tcp.application0-ping" returned null. However if I logged into the application pod and do nslookup it will give me correct record: sh-5.0# nslookup -type=srv _tcp.application0-ping Server: 10.74.177.77 Address: 10.74.177.77#53 _tcp.application0-ping.default.svc.cluster.local service = 10 100 8888 44c84e52.application0-ping.default.svc.cluster.local. And you can get the full name from the record, which is _tcp.application0-ping.default.svc.cluster.local If I then pass the full qualified name into the application and it can query the SRV record successfully. I have no idea why my application can't query the record using the short form name (i.e. _tcp.application0-ping). Could it be some configuration issue for the DNS ping? My openshift env details are: oc v3.11.117 kubernetes v1.11.0+d4cacc0 features: Basic-Auth GSSAPI Kerberos SPNEGO and the java version used in pod: sh-5.0# java -version openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-b04) OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode) and the base OS is fedora 30. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4354) [DMN Designer] No Such Method exception is thrown

by Guilherme Gomes (Jira)

[ https://issues.jboss.org/browse/DROOLS-4354?page=com.atlassian.jira.plugi... ] Guilherme Gomes reassigned DROOLS-4354: --------------------------------------- Assignee: Guilherme Gomes (was: Mario Fusco) > [DMN Designer] No Such Method exception is thrown > ------------------------------------------------- > > Key: DROOLS-4354 > URL: https://issues.jboss.org/browse/DROOLS-4354 > Project: Drools > Issue Type: Bug > Affects Versions: 7.25.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Blocker > Labels: drools-tools > Attachments: error.log, no-such-method.webm > > > A NoSuchMethod exception is thrown when user tries to expand the diagram properties panel and having some dmn diagram node selected at the same time. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4354) [DMN Designer] No Such Method exception is thrown

by Jozef Marko (Jira)

Jozef Marko created DROOLS-4354: ----------------------------------- Summary: [DMN Designer] No Such Method exception is thrown Key: DROOLS-4354 URL: https://issues.jboss.org/browse/DROOLS-4354 Project: Drools Issue Type: Bug Affects Versions: 7.25.0.Final Reporter: Jozef Marko Assignee: Mario Fusco Attachments: error.log, no-such-method.webm A NoSuchMethod exception is thrown when user tries to expand the diagram properties panel and having some dmn diagram node selected at the same time. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 12 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 July 2019