February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AG-49) Reset transaction check callback when returning connection to the pool

by Luis Barreiro (JIRA)

[ https://issues.jboss.org/browse/AG-49?page=com.atlassian.jira.plugin.syst... ] Luis Barreiro resolved AG-49. ----------------------------- Resolution: Done > Reset transaction check callback when returning connection to the pool > ---------------------------------------------------------------------- > > Key: AG-49 > URL: https://issues.jboss.org/browse/AG-49 > Project: Agroal > Issue Type: Bug > Components: pool > Affects Versions: 0.3 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Priority: Minor > Fix For: 0.4 > > > The callback that prevents lazy enlistment, once set, is never reset. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AG-49) Reset transaction check callback when returning connection to the pool

by Luis Barreiro (JIRA)

Luis Barreiro created AG-49: ------------------------------- Summary: Reset transaction check callback when returning connection to the pool Key: AG-49 URL: https://issues.jboss.org/browse/AG-49 Project: Agroal Issue Type: Bug Components: pool Affects Versions: 0.3 Reporter: Luis Barreiro Assignee: Luis Barreiro Priority: Minor Fix For: 0.4 The callback that prevents lazy enlistment, once set, is never reset. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AG-48) Remove autocommit stash from WrappedConnection

by Luis Barreiro (JIRA)

[ https://issues.jboss.org/browse/AG-48?page=com.atlassian.jira.plugin.syst... ] Luis Barreiro resolved AG-48. ----------------------------- Resolution: Done > Remove autocommit stash from WrappedConnection > ---------------------------------------------- > > Key: AG-48 > URL: https://issues.jboss.org/browse/AG-48 > Project: Agroal > Issue Type: Bug > Components: pool > Affects Versions: 0.3 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Priority: Minor > Fix For: 0.4 > > > This logic is not needed anymore, as it's provided by AG-34 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AG-48) Remove autocommit stash from WrappedConnection

by Luis Barreiro (JIRA)

Luis Barreiro created AG-48: ------------------------------- Summary: Remove autocommit stash from WrappedConnection Key: AG-48 URL: https://issues.jboss.org/browse/AG-48 Project: Agroal Issue Type: Bug Components: pool Affects Versions: 0.3 Reporter: Luis Barreiro Assignee: Luis Barreiro Priority: Minor Fix For: 0.4 This logic is not needed anymore, as it's provided by AG-34 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2235) ConcurrentModificationException when resend pending lock requests

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2235?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2235. ---------------------------- Resolution: Done Fixed by synchronizing on the table iteration > ConcurrentModificationException when resend pending lock requests > ----------------------------------------------------------------- > > Key: JGRP-2235 > URL: https://issues.jboss.org/browse/JGRP-2235 > Project: JGroups > Issue Type: Bug > Reporter: Bram Klein Gunnewiek > Assignee: Bela Ban > Fix For: 4.0.11 > > > While testing JGRP-2234 we saw a ConcurrentModificationException in the locking protocol in some (rare) situations: > {noformat} > 09:46:42.856 [jgroups-7,TEST,B] ERROR org.jgroups.protocols.pbcast.GMS - JGRP000027: failed passing message up > java.util.ConcurrentModificationException: null > at java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1630) ~[?:1.8.0_151] > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:1.8.0_151] > at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:1.8.0_151] > at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) ~[?:1.8.0_151] > at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) ~[?:1.8.0_151] > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_151] > at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) ~[?:1.8.0_151] > at org.jgroups.protocols.Locking$ClientLockTable.lambda$resendPendingLockRequests$3(Locking.java:1085) ~[classes/:?] > at java.util.concurrent.ConcurrentHashMap$ValuesView.forEach(ConcurrentHashMap.java:4707) ~[?:1.8.0_151] > at org.jgroups.protocols.Locking$ClientLockTable.resendPendingLockRequests(Locking.java:1084) ~[classes/:?] > at org.jgroups.protocols.CENTRAL_LOCK.handleView(CENTRAL_LOCK.java:147) ~[classes/:?] > at org.jgroups.protocols.Locking.up(Locking.java:218) ~[classes/:?] > at org.jgroups.protocols.FRAG2.up(FRAG2.java:163) ~[classes/:?] > at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:702) ~[classes/:?] > at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:135) ~[classes/:?] > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:918) ~[classes/:?] > at org.jgroups.stack.Protocol.up(Protocol.java:364) [classes/:?] > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:293) [classes/:?] > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:428) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:962) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.removeAndDeliver(NAKACK2.java:896) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.handleMessages(NAKACK2.java:870) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:690) [classes/:?] > at org.jgroups.stack.Protocol.up(Protocol.java:372) [classes/:?] > at org.jgroups.protocols.TP.passBatchUp(TP.java:1255) [classes/:?] > at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.passBatchUp(MaxOneThreadPerSender.java:284) [classes/:?] > at org.jgroups.util.SubmitToThreadPool$BatchHandler.run(SubmitToThreadPool.java:136) [classes/:?] > at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.run(MaxOneThreadPerSender.java:273) [classes/:?] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_151] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_151] > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_151] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1468) IBM java, 403 instead of 401 sent, when kerberos mechanism is not supported

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1468?page=com.atlassian.jira.plugin.s... ] Martin Choma updated ELY-1468: ------------------------------ Comment: was deleted (was: As a side effect of JBEAP-14187 fix this seems be fixed for IBM, however popped up for Oracle/OpenJDK ) > IBM java, 403 instead of 401 sent, when kerberos mechanism is not supported > --------------------------------------------------------------------------- > > Key: ELY-1468 > URL: https://issues.jboss.org/browse/ELY-1468 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Affects Versions: 1.2.0.Beta10 > Reporter: Martin Choma > Priority: Minor > > When more mechanismTypes is provided but the Kerberos mechanism is not listed as the supported one then authentication should fail. And 401 should be returned, but 403 is on IBM java. > This issue was hidden by ELY-1340. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9749) Drop old & legacy batch subsystem

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9749?page=com.atlassian.jira.plugin.... ] Cheng Fang reassigned WFLY-9749: -------------------------------- Assignee: James Perkins (was: Cheng Fang) > Drop old & legacy batch subsystem > --------------------------------- > > Key: WFLY-9749 > URL: https://issues.jboss.org/browse/WFLY-9749 > Project: WildFly > Issue Type: Task > Components: Batch > Reporter: Tomaz Cerar > Assignee: James Perkins > Priority: Critical > > Batch subsystem was added in WildFly 8 to support EE7, but was replaced by "batch-jberet" in 9. > By this time noone should be using it anymore and we can drop it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1468) IBM java, 403 instead of 401 sent, when kerberos mechanism is not supported

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1468?page=com.atlassian.jira.plugin.s... ] Martin Choma edited comment on ELY-1468 at 2/1/18 9:45 AM: ----------------------------------------------------------- As a side effect of JBEAP-14187 fix this seems be fixed for IBM, however popped up for Oracle/OpenJDK was (Author: mchoma): As a side effect of JBEAP-14187 fiz this seems be fixed for IBM, however popped up for Oracle/OpenJDK > IBM java, 403 instead of 401 sent, when kerberos mechanism is not supported > --------------------------------------------------------------------------- > > Key: ELY-1468 > URL: https://issues.jboss.org/browse/ELY-1468 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Affects Versions: 1.2.0.Beta10 > Reporter: Martin Choma > Priority: Minor > > When more mechanismTypes is provided but the Kerberos mechanism is not listed as the supported one then authentication should fail. And 401 should be returned, but 403 is on IBM java. > This issue was hidden by ELY-1340. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1468) IBM java, 403 instead of 401 sent, when kerberos mechanism is not supported

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1468?page=com.atlassian.jira.plugin.s... ] Martin Choma commented on ELY-1468: ----------------------------------- As a side effect of JBEAP-14187 fiz this seems be fixed for IBM, however popped up for Oracle/OpenJDK > IBM java, 403 instead of 401 sent, when kerberos mechanism is not supported > --------------------------------------------------------------------------- > > Key: ELY-1468 > URL: https://issues.jboss.org/browse/ELY-1468 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Affects Versions: 1.2.0.Beta10 > Reporter: Martin Choma > Priority: Minor > > When more mechanismTypes is provided but the Kerberos mechanism is not listed as the supported one then authentication should fail. And 401 should be returned, but 403 is on IBM java. > This issue was hidden by ELY-1340. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9749) Drop old & legacy batch subsystem

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-9749: --------------------------------- Summary: Drop old & legacy batch subsystem Key: WFLY-9749 URL: https://issues.jboss.org/browse/WFLY-9749 Project: WildFly Issue Type: Task Components: Batch Reporter: Tomaz Cerar Assignee: Cheng Fang Priority: Critical Batch subsystem was added in WildFly 8 to support EE7, but was replaced by "batch-jberet" in 9. By this time noone should be using it anymore and we can drop it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2018