January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AG-47) Failure to get results out of ResultSetWrapper

by Luis Barreiro (JIRA)

Luis Barreiro created AG-47: ------------------------------- Summary: Failure to get results out of ResultSetWrapper Key: AG-47 URL: https://issues.jboss.org/browse/AG-47 Project: Agroal Issue Type: Bug Components: pool Affects Versions: 0.3 Reporter: Luis Barreiro Assignee: Luis Barreiro Priority: Critical Fix For: 0.4 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9728) Upgrade jgroups-azure to 1.2.0.Final

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-9728: ------------------------------------ Summary: Upgrade jgroups-azure to 1.2.0.Final Key: WFLY-9728 URL: https://issues.jboss.org/browse/WFLY-9728 Project: WildFly Issue Type: Component Upgrade Components: Clustering Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 12.0.0.Alpha1 Upgrade for jgroups 4.0.x and upgrade azure storage client to 6.1.0. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

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

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9727?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-9727: ----------------------------------- I don't know why the whole server would terminate if Eclipse wasn't terminating it. As for the exception though, that happens when the NIO selector "goes bad", as it does in some JDKs. To confirm this problem, you could start the server with the flag {{-Dxnio.nio.selector.provider=sun.nio.ch.PollSelectorProvider}} to see if that solves the issue. > 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)

8 years, 3 months

1
0
0 / 0

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

by Daniel Wiseman (JIRA)

Daniel Wiseman created WFLY-9727: ------------------------------------ Summary: 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 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)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1495) Stack overflow in WildFlySecurityManager#checkPermission(Permission, AccessControlContext)

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1495?page=com.atlassian.jira.plugin.s... ] David Lloyd resolved ELY-1495. ------------------------------ Resolution: Done > Stack overflow in WildFlySecurityManager#checkPermission(Permission, AccessControlContext) > ------------------------------------------------------------------------------------------ > > Key: ELY-1495 > URL: https://issues.jboss.org/browse/ELY-1495 > Project: WildFly Elytron > Issue Type: Bug > Components: Security Manager > Affects Versions: 1.2.0.Beta11 > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > Fix For: 1.2.0.Beta12 > > > Maybe use Unsafe instead. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugi... ] David Lloyd commented on LOGTOOL-132: ------------------------------------- Re-reading the analysis, I guess that the vtable/itable savings would only occur if we actually rewrote the interface itself into a final class so that there is no inheritance going on at all. We could retain basic compatibility with older {{jboss-logging}} just by providing a constructor which accepts only a Logger and assumes Locale.ROOT. It would defeat I18n in this case but I think that's OK: when running with an older {{jboss-logging}} than what the project was compiled for, one must expect problems. > Support low-metaspace bundles/classes > ------------------------------------- > > Key: LOGTOOL-132 > URL: https://issues.jboss.org/browse/LOGTOOL-132 > Project: Log Tool > Issue Type: Enhancement > Reporter: David Lloyd > Priority: Critical > > Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes. > Introduce a leaner variation on generated classes with the following requirements: > * The generated class must be {{final}} > * The generated class must contain no message strings > * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information > * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this > Here are some implementation ideas: > * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message > ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string > ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated > ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale) > * Option 2: The resource files contain key-value pairs, with the key being equal to the method name > ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales > ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugi... ] James Perkins commented on LOGTOOL-132: --------------------------------------- Taking a second look I was still generating the generating the {{*$str()}} methods in the implementation. Removing those did significantly reduce the metaspace size of the loggers by about 50%. Marking the implementation as final didn't really change the size that much. Only by about 8 bytes per implementation. One side question is should we maintain compatibility with older versions of {{jboss-logging}}? If we want to do this I think it would be possible and we could slightly decrease the metaspace size by just removing the static strings. > Support low-metaspace bundles/classes > ------------------------------------- > > Key: LOGTOOL-132 > URL: https://issues.jboss.org/browse/LOGTOOL-132 > Project: Log Tool > Issue Type: Enhancement > Reporter: David Lloyd > Priority: Critical > > Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes. > Introduce a leaner variation on generated classes with the following requirements: > * The generated class must be {{final}} > * The generated class must contain no message strings > * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information > * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this > Here are some implementation ideas: > * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message > ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string > ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated > ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale) > * Option 2: The resource files contain key-value pairs, with the key being equal to the method name > ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales > ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3544) Upgrade Elytron Web to 1.1.0.Beta1

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-3544: ---------------------------------------- Summary: Upgrade Elytron Web to 1.1.0.Beta1 Key: WFCORE-3544 URL: https://issues.jboss.org/browse/WFCORE-3544 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 4.0.0.Alpha7 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3496) Upgrade WildFly Elytron to 1.2.0.Beta13

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3496?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-3496: ------------------------------------- Summary: Upgrade WildFly Elytron to 1.2.0.Beta13 (was: Upgrade WildFly Elytron to 1.2.0.Beta12) > Upgrade WildFly Elytron to 1.2.0.Beta13 > --------------------------------------- > > Key: WFCORE-3496 > URL: https://issues.jboss.org/browse/WFCORE-3496 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Ivo Studensky > Assignee: Darran Lofthouse > Labels: downstream_dependency > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3543) Upgrade WildFly Elytron to 1.2.0.Beta12

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-3543: ---------------------------------------- Summary: Upgrade WildFly Elytron to 1.2.0.Beta12 Key: WFCORE-3543 URL: https://issues.jboss.org/browse/WFCORE-3543 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 4.0.0.Alpha7 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 2018