February 2018 - jboss-jira - Jboss List Archives

[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)

6 years, 2 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)

6 years, 2 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)

6 years, 2 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)

6 years, 2 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)

6 years, 2 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)

6 years, 2 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)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9727) WildFly Randomly Terminates after 5-10 minutes

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9727?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-9727: ----------------------------------- What is the exact version of JDK you are using? > WildFly Randomly Terminates after 5-10 minutes > ---------------------------------------------- > > Key: WFLY-9727 > URL: https://issues.jboss.org/browse/WFLY-9727 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 10.0.0.Final > Environment: Running WildFly 10.x from within Eclipse Oxygen (4.7.2) on 2015 MacBook Pro running OS X El Capitan (10.11.6) > Reporter: Daniel Wiseman > Assignee: Jason Greene > Priority: Blocker > Original Estimate: 1 week > Remaining Estimate: 1 week > > I've been experiencing an odd intermittent issue on my WildFly server that has been running on my local system. Every other day or so my server will shutdown, without warning, after running for five to ten minutes from launch. The WildFly server logs contain no errors but the Eclipse logs output these two stack identical stack traces every time: > {{Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating > at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588) > at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354) > at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233) > at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291) > at org.xnio.FutureResult.setCancelled(FutureResult.java:98) > at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:492) > Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating > at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588) > at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354) > at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233) > at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291) > at org.xnio.FutureResult.setCancelled(FutureResult.java:98) > at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)}} > This issue will occur on every server start for an entire day and then the next day it won't happen at all. However, when it happens it makes debugging the software I write that runs of the server near impossible. Does anyone have any ideas what could be causing this issue? Let me know if you need more details, thanks! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3571) Improve CLI error handling in ListCommand

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3571?page=com.atlassian.jira.plugi... ] Marek Kopecký updated WFCORE-3571: ---------------------------------- Affects Version/s: 4.0.0.Alpha8 > Improve CLI error handling in ListCommand > ----------------------------------------- > > Key: WFCORE-3571 > URL: https://issues.jboss.org/browse/WFCORE-3571 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Alpha8 > Reporter: Marek Kopecký > Assignee: Marek Kopecký > Priority: Minor > > Improve CLI error handling in ListCommand class. If management operation doesn't return correct results, CLI should throw correct error message. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3571) Improve CLI error handling in ListCommand

by Marek Kopecký (JIRA)

Marek Kopecký created WFCORE-3571: ------------------------------------- Summary: Improve CLI error handling in ListCommand Key: WFCORE-3571 URL: https://issues.jboss.org/browse/WFCORE-3571 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Marek Kopecký Assignee: Marek Kopecký Priority: Minor Improve CLI error handling in ListCommand class. If management operation doesn't return correct results, CLI should throw correct error message. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2018