[JBoss JIRA] (WFLY-8937) Management/security-realm/authentication/users integration with credential reference is not correct.
by Hynek Švábek (JIRA)
Hynek Švábek created WFLY-8937:
----------------------------------
Summary: Management/security-realm/authentication/users integration with credential reference is not correct.
Key: WFLY-8937
URL: https://issues.jboss.org/browse/WFLY-8937
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Priority: Blocker
Management/security-realm/authentication/users integration with credential reference is not correct.
When user set authentication/users instead of authentication/properties and add there user who has defined credential-reference then he is not able to log in to management console.
It must work, please check *Steps to Reproduce* section.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8929) Race condition if timers overlap due to long running execution and short schedules if database persistence is used
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-8929?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-8929:
-----------------------------------------------
wfink(a)redhat.com changed the Status of [bug 1461416|https://bugzilla.redhat.com/show_bug.cgi?id=1461416] from NEW to ASSIGNED
> Race condition if timers overlap due to long running execution and short schedules if database persistence is used
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8929
> URL: https://issues.jboss.org/browse/WFLY-8929
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: Configure DB persistence for timers as file-persistence will not have a persistence check for shouldRun to lock the timer execution.
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Attachments: server-extract.log, server1.log
>
>
> If timers (here calendar timer) are running longer than scheduled, or the schedule/processing get stuck do to thread or cpu bottleneck, it is possible that the updates for persistence overlap.
> The issue seems that the task(1) try to finish the timer and task(2) is about to start but see the concurrency.
> The DB is updated with the 'old' next timeout, but the internal Timer instance will be updated with the next possible schedule due to a race condition between the two threads updating the object.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-4790) Getting DirectBuffer OOM when sending fragmented binary message to websocket endpoint
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4790?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4790:
--------------------------------------
Did you update every Undertow jar? There are three of them.
> Getting DirectBuffer OOM when sending fragmented binary message to websocket endpoint
> -------------------------------------------------------------------------------------
>
> Key: WFLY-4790
> URL: https://issues.jboss.org/browse/WFLY-4790
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha3
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 10.0.0.Alpha6
>
>
> When sending fragmented binary message (message with message payload of length 4 * 2**20 (4M). Sent out in fragments of 64). The server throws {{java.lang.OutOfMemoryError: Direct buffer memory}} [1]
> The memory for direct buffer by default depends on the size set by -Xmx, which is in EAP 7.0.0.DR4 by default set to -Xmx512m. Increasing it just increases the time before the limit is hit (it is enough to send those messages multiple times to hit the limit again).
> I believe the issue is similar to the one for EAP 6.4: [https://bugzilla.redhat.com/show_bug.cgi?id=1223708]
> [1]
> {noformat}
> 15:10:55,463 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:658)
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:143)
> at io.undertow.websockets.core.BufferedBinaryMessage$1.handleEvent(BufferedBinaryMessage.java:106)
> at io.undertow.websockets.core.BufferedBinaryMessage$1.handleEvent(BufferedBinaryMessage.java:97)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSourceChannel$1.run(AbstractFramedStreamSourceChannel.java:264)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:560)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:462)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1511) NullPointerException when running sample projects
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1511?page=com.atlassian.jira.plugi... ]
Kris Verlaenen reassigned DROOLS-1511:
--------------------------------------
Assignee: Kris Verlaenen (was: Robert (Bob) Brodt)
> NullPointerException when running sample projects
> -------------------------------------------------
>
> Key: DROOLS-1511
> URL: https://issues.jboss.org/browse/DROOLS-1511
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Environment: DevStudio 10 + IS 10.3.0.CR2
> Eclipse Neon + Drools plugin 7.0.0.CR3
> Drools Runtime 7.x
> Reporter: Tomas David
> Assignee: Kris Verlaenen
> Priority: Blocker
> Labels: reported-by-qe
>
> NullPointerException is thrown when running sample project using Drools and Java Runtime classes because KieSession is not created.
> Eclipse log:
> !SESSION 2017-04-04 12:39:38.638 -----------------------------------------------
> eclipse.buildId=4.6.3.M20170301-0400
> java.version=1.8.0_121
> java.vendor=Oracle Corporation
> BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
> Framework arguments: -product org.eclipse.epp.package.jee.product
> Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.jee.product
> !ENTRY org.drools.eclipse 4 120 2017-04-04 12:41:31.737
> !MESSAGE Internal error in Drools Plugin:
> !STACK 1
> Java Model Exception: Java Model Status [Build path contains duplicate entry: 'DROOLS/Drools' for project 'TestProject']
> at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:786)
> at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath(JavaProject.java:3097)
> at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath(JavaProject.java:3059)
> at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath(JavaProject.java:3112)
> at org.drools.eclipse.util.DroolsRuntimeManager.addBuilder(DroolsRuntimeManager.java:122)
> at org.drools.eclipse.action.ConvertToDroolsProjectAction.run(ConvertToDroolsProjectAction.java:45)
> at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:247)
> at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:565)
> at org.eclipse.jface.action.ActionContributionItem.lambda$4(ActionContributionItem.java:397)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5227)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1340)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4561)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4151)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1121)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1022)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:150)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:693)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:610)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1519)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1492)
> !SUBENTRY 1 org.eclipse.jdt.core 4 977 2017-04-04 12:41:31.739
> !MESSAGE Build path contains duplicate entry: 'DROOLS/Drools' for project 'TestProject'
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2959) Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2959?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2959:
------------------------------------------
Going with 1 sounds fine to me. In the description I said "this bears some research/discussion" and that's happened now. :)
> Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf
> ----------------------------------------------------------------------
>
> Key: WFCORE-2959
> URL: https://issues.jboss.org/browse/WFCORE-2959
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
>
> This is a task that came out of research done by [~andy.miller] on WF/EAP memory use in cloud environments.
> Our launch scripts for *nix environments should set MALLOC_ARENA_MAX, e.g.
> {code}
> export MALLOC_ARENA_MAX=${MALLOC_ARENA_MAX:-1}
> {code}
> See http://info.prelert.com/blog/java-8-and-virtual-memory-on-linux for background.
> The default glibc settings of allowing up to 128 malloc arenas make very little sense for a java application, since the vm asks the os for a few large memory allocations and then manages those areas itself. Leaving that default setting in place will result in a very large virtual memory size for the VM. It's just virtual, not resident, memory, so controlling this to a large extent is just a matter of having a better image for people who don't understand the distinction. But as is mentioned in the linked blog post's discussion of mlockall() and Elasticsearch, there may be some more concrete implications as well.
> The initial recommendation on this was to set the value to 1, but this bears some research/discussion. For example hadoop uses 4 (https://issues.apache.org/jira/browse/HADOOP-7154), and a bit of googling of "MALLOC_ARENA_MAX java" leads to some entries mentioning using 2 or 3.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2959) Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2959?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2959:
-------------------------------------
Description:
This is a task that came out of research done by [~andy.miller] on WF/EAP memory use in cloud environments.
Our launch scripts for *nix environments should set MALLOC_ARENA_MAX, e.g.
{code}
export MALLOC_ARENA_MAX=${MALLOC_ARENA_MAX:-1}
{code}
See http://info.prelert.com/blog/java-8-and-virtual-memory-on-linux for background.
The default glibc settings of allowing up to 128 malloc arenas make very little sense for a java application, since the vm asks the os for a few large memory allocations and then manages those areas itself. Leaving that default setting in place will result in a very large virtual memory size for the VM. It's just virtual, not resident, memory, so controlling this to a large extent is just a matter of having a better image for people who don't understand the distinction. But as is mentioned in the linked blog post's discussion of mlockall() and Elasticsearch, there may be some more concrete implications as well.
The initial recommendation on this was to set the value to 1, but this bears some research/discussion. For example hadoop uses 4 (https://issues.apache.org/jira/browse/HADOOP-7154), and a bit of googling of "MALLOC_ARENA_MAX java" leads to some entries mentioning using 2 or 3.
was:
This is a task that came out of research done by [~andy.miller] on WF/EAP memory use in cloud environments.
Our launch scripts for *nix environments should set MALLOC_ARENA_MAX, e.g.
export MALLOC_ARENA_MAX=${MALLOC_ARENA_MAX:-1}
See http://info.prelert.com/blog/java-8-and-virtual-memory-on-linux for background.
The default glibc settings of allowing up to 128 malloc arenas make very little sense for a java application, since the vm asks the os for a few large memory allocations and then manages those areas itself. Leaving that default setting in place will result in a very large virtual memory size for the VM. It's just virtual, not resident, memory, so controlling this to a large extent is just a matter of having a better image for people who don't understand the distinction. But as is mentioned in the linked blog post's discussion of mlockall() and Elasticsearch, there may be some more concrete implications as well.
The initial recommendation on this was to set the value to 1, but this bears some research/discussion. For example hadoop uses 4 (https://issues.apache.org/jira/browse/HADOOP-7154), and a bit of googling of "MALLOC_ARENA_MAX java" leads to some entries mentioning using 2 or 3.
> Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf
> ----------------------------------------------------------------------
>
> Key: WFCORE-2959
> URL: https://issues.jboss.org/browse/WFCORE-2959
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
>
> This is a task that came out of research done by [~andy.miller] on WF/EAP memory use in cloud environments.
> Our launch scripts for *nix environments should set MALLOC_ARENA_MAX, e.g.
> {code}
> export MALLOC_ARENA_MAX=${MALLOC_ARENA_MAX:-1}
> {code}
> See http://info.prelert.com/blog/java-8-and-virtual-memory-on-linux for background.
> The default glibc settings of allowing up to 128 malloc arenas make very little sense for a java application, since the vm asks the os for a few large memory allocations and then manages those areas itself. Leaving that default setting in place will result in a very large virtual memory size for the VM. It's just virtual, not resident, memory, so controlling this to a large extent is just a matter of having a better image for people who don't understand the distinction. But as is mentioned in the linked blog post's discussion of mlockall() and Elasticsearch, there may be some more concrete implications as well.
> The initial recommendation on this was to set the value to 1, but this bears some research/discussion. For example hadoop uses 4 (https://issues.apache.org/jira/browse/HADOOP-7154), and a bit of googling of "MALLOC_ARENA_MAX java" leads to some entries mentioning using 2 or 3.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2959) Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2959?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-2959:
-------------------------------------
If there's no observable difference, then it sounds like there's no problem. I'd rather start with 1 (which has measurable benefits) and wait for evidence that it's a problem than do the gut-feeling thing.
> Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf
> ----------------------------------------------------------------------
>
> Key: WFCORE-2959
> URL: https://issues.jboss.org/browse/WFCORE-2959
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
>
> This is a task that came out of research done by [~andy.miller] on WF/EAP memory use in cloud environments.
> Our launch scripts for *nix environments should set MALLOC_ARENA_MAX, e.g.
> export MALLOC_ARENA_MAX=${MALLOC_ARENA_MAX:-1}
> See http://info.prelert.com/blog/java-8-and-virtual-memory-on-linux for background.
> The default glibc settings of allowing up to 128 malloc arenas make very little sense for a java application, since the vm asks the os for a few large memory allocations and then manages those areas itself. Leaving that default setting in place will result in a very large virtual memory size for the VM. It's just virtual, not resident, memory, so controlling this to a large extent is just a matter of having a better image for people who don't understand the distinction. But as is mentioned in the linked blog post's discussion of mlockall() and Elasticsearch, there may be some more concrete implications as well.
> The initial recommendation on this was to set the value to 1, but this bears some research/discussion. For example hadoop uses 4 (https://issues.apache.org/jira/browse/HADOOP-7154), and a bit of googling of "MALLOC_ARENA_MAX java" leads to some entries mentioning using 2 or 3.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months