January 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11629) Transaction service isn't available when dynamically adding transactional annotation

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/WFLY-11629?page=com.atlassian.jira.plugin... ] Tom Jenkinson reassigned WFLY-11629: ------------------------------------ Assignee: Ondra Chaloupka (was: Tom Jenkinson) > Transaction service isn't available when dynamically adding transactional annotation > ------------------------------------------------------------------------------------ > > Key: WFLY-11629 > URL: https://issues.jboss.org/browse/WFLY-11629 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 15.0.1.Final > Reporter: Juan Gonzalez > Assignee: Ondra Chaloupka > Priority: Major > Attachments: wildfly_dynamic_tx_reproducer.zip > > > When adding dynamically a transactional annotation, transactional module isn't loaded, so transactions aren't available and throws this error: > {noformat} > javax.persistence.TransactionRequiredException: WFLYJPA0060: Transaction is required to perform this operation (either use a transaction or extended persistence context) > {noformat} > I've attached a reproducer with a test in order to reproduce this. There you can see that there is a CDI producer that dynamically adds the annotation for transactions, that doesn't work. > [~mkouba] found this could be an optimization for not loading JTS module: https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... > In order to execute tests: > mvn clean test > To execute test, passing in Payara: > mvn clean test -Ppayara -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11629) Transaction service isn't available when dynamically adding transactional annotation

by Juan Gonzalez (Jira)

Juan Gonzalez created WFLY-11629: ------------------------------------ Summary: Transaction service isn't available when dynamically adding transactional annotation Key: WFLY-11629 URL: https://issues.jboss.org/browse/WFLY-11629 Project: WildFly Issue Type: Bug Components: Transactions Affects Versions: 15.0.1.Final Reporter: Juan Gonzalez Assignee: Tom Jenkinson Attachments: wildfly_dynamic_tx_reproducer.zip When adding dynamically a transactional annotation, transactional module isn't loaded, so transactions aren't available and throws this error: {noformat} javax.persistence.TransactionRequiredException: WFLYJPA0060: Transaction is required to perform this operation (either use a transaction or extended persistence context) {noformat} I've attached a reproducer with a test in order to reproduce this. There you can see that there is a CDI producer that dynamically adds the annotation for transactions, that doesn't work. [~mkouba] found this could be an optimization for not loading JTS module: https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... In order to execute tests: mvn clean test To execute test, passing in Payara: mvn clean test -Ppayara -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11629) Transaction service isn't available when dynamically adding transactional annotation

by Juan Gonzalez (Jira)

[ https://issues.jboss.org/browse/WFLY-11629?page=com.atlassian.jira.plugin... ] Juan Gonzalez updated WFLY-11629: --------------------------------- Attachment: wildfly_dynamic_tx_reproducer.zip > Transaction service isn't available when dynamically adding transactional annotation > ------------------------------------------------------------------------------------ > > Key: WFLY-11629 > URL: https://issues.jboss.org/browse/WFLY-11629 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 15.0.1.Final > Reporter: Juan Gonzalez > Assignee: Tom Jenkinson > Priority: Major > Attachments: wildfly_dynamic_tx_reproducer.zip > > > When adding dynamically a transactional annotation, transactional module isn't loaded, so transactions aren't available and throws this error: > {noformat} > javax.persistence.TransactionRequiredException: WFLYJPA0060: Transaction is required to perform this operation (either use a transaction or extended persistence context) > {noformat} > I've attached a reproducer with a test in order to reproduce this. There you can see that there is a CDI producer that dynamically adds the annotation for transactions, that doesn't work. > [~mkouba] found this could be an optimization for not loading JTS module: https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... > In order to execute tests: > mvn clean test > To execute test, passing in Payara: > mvn clean test -Ppayara -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2320) FILE_PING.findMembers() optimizations

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2320?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2320: --------------------------- Fix Version/s: 4.0.18 (was: 4.0.17) > FILE_PING.findMembers() optimizations > ------------------------------------- > > Key: JGRP-2320 > URL: https://issues.jboss.org/browse/JGRP-2320 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.16, 4.0.15 > Reporter: Nick Sawadsky > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.18 > > > Following on from JGRP-2288, a couple of possible optimizations/improvements to {{FILE_PING.findMembers()}} were identified. > 1. After the initial call to {{readAll()}}, some corrective steps are taken if the local node address was not returned by {{readAll()}}. However, in the case where {{findMembers()}} is invoked by {{TP.fetchResponsesFromDiscoveryProtocol()}}, it is normal if the local node address is not returned, since the {{readAll()}} responses are filtered based on the {{members}} parameter. > To avoid unnecessary writes to the file or cloud store, it would be good to add some checks based on whether {{members}} is null or not. For example, the calls to {{write()}} and {{writeAll()}} should probably not occur unless {{members}} is null. > 2. In the call to {{sendDiscoveryResponse()}}, the last parameter is always {{false}}. However, it seems possible for a coordinator to get to this point in some edge cases. Though I haven't been able to identify any clear bugs that this would lead to, it might be better to pass {{is_coord}} as the last parameter. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2310) SubstrateVM

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2310?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2310: --------------------------- Fix Version/s: 4.0.18 (was: 4.0.17) > SubstrateVM > ----------- > > Key: JGRP-2310 > URL: https://issues.jboss.org/browse/JGRP-2310 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.18 > > > Compile JGroups to run with SubstrateVM and run (e.g.) Draw with it -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2318) KUBE_PING: test with RBAC

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2318?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2318: --------------------------- Fix Version/s: 4.0.18 (was: 4.0.17) > KUBE_PING: test with RBAC > ------------------------- > > Key: JGRP-2318 > URL: https://issues.jboss.org/browse/JGRP-2318 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.18 > > > Test if KUBE_PING still works with the latest minikube/RBAC combo -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2311) tshark/wireshark support

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2311?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2311: --------------------------- Fix Version/s: 4.0.18 (was: 4.0.17) > tshark/wireshark support > ------------------------ > > Key: JGRP-2311 > URL: https://issues.jboss.org/browse/JGRP-2311 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.18 > > Attachments: tshark-convert.py > > > 1. Dump contents of wireshark/tahsrk/tcpdump-generated (PCAP) files (using {{ParseMessages}} > 2. Do this dynamically, e.g. `tshark -Tfields -e data` | java ParseMessages > In the second instantiation, ParseMessages would read packets from stdin. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2299: --------------------------- Fix Version/s: 4.0.18 (was: 4.0.17) > LockService does not work correctly if unlock/lock is called in immediate succession > ------------------------------------------------------------------------------------ > > Key: JGRP-2299 > URL: https://issues.jboss.org/browse/JGRP-2299 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Environment: Windows 10 Oracle JDK 1.8 131 > AIX IBM Java 8 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.18 > > Attachments: JGroupsExample.java, udp+lock.xml > > > In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected. > This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded. > If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock(). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2284) Discovery protocol for members in the same process

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2284?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2284: --------------------------- Fix Version/s: 4.0.18 (was: 4.0.17) > Discovery protocol for members in the same process > -------------------------------------------------- > > Key: JGRP-2284 > URL: https://issues.jboss.org/browse/JGRP-2284 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.18 > > > Discovery protocol that works for members in the same process. Something like SHARED_LOOPBACK_PING, but without the requirement for SHARED_LOOPBACK as transport, but it should work over UDP, TCP, TCP_NIO2 etc. > Similar to TEST_PING in Infinispan. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2283) Lock race condition

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2283?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2283: --------------------------- Fix Version/s: 4.0.18 (was: 4.0.17) > Lock race condition > ------------------- > > Key: JGRP-2283 > URL: https://issues.jboss.org/browse/JGRP-2283 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.18 > > Attachments: RDBXGNBM.txt, m1PNLdDr.txt > > > The attached program fails to run repeats of tryLock-unlock sequences. > Program and config are attached -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 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 January 2019