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