May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-550) Update the FORM authentication mechanism so it can be configured to redirect to specific location after authentication.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-550: ------------------------------------ Summary: Update the FORM authentication mechanism so it can be configured to redirect to specific location after authentication. Key: ELY-550 URL: https://issues.jboss.org/browse/ELY-550 Project: WildFly Elytron Issue Type: Feature Request Components: HTTP Reporter: Darran Lofthouse Fix For: 2.0.0.Alpha1 The current implementation caches the intercepted location that the user was attempting to access and after authentication sends them back to that location - this feature request is to support additional configuration to send them to a pre-defined location i.e. some form of welcome page. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1125) Google App Engine support: ClassLoader.getSystemClassLoader() throws exception

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1125?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1125: ------------------------------------------------- Xiong Zhi Ming <zxiong(a)redhat.com> changed the Status of [bug 1329093|https://bugzilla-qe-05.host.stage.eng.rdu2.redhat.com/show_bug.cg...] from MODIFIED to ON_QA > Google App Engine support: ClassLoader.getSystemClassLoader() throws exception > ------------------------------------------------------------------------------ > > Key: DROOLS-1125 > URL: https://issues.jboss.org/browse/DROOLS-1125 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Fix For: 7.0.0.Beta1 > > > Class org.kie.internal.utils.ChainedProperties > Every call to get the System Class Loader > confClassLoader = ClassLoader.getSystemClassLoader(); (i.e. lines 133, 169) > raises an exception. > Todo: figure out which particular exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1127) Google App Engine support: Do not call new Thread() by allowing to plug in a custom ThreadFactory

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1127?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1127: ------------------------------------------------- Xiong Zhi Ming <zxiong(a)redhat.com> changed the Status of [bug 1329093|https://bugzilla-qe-05.host.stage.eng.rdu2.redhat.com/show_bug.cg...] from MODIFIED to ON_QA > Google App Engine support: Do not call new Thread() by allowing to plug in a custom ThreadFactory > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-1127 > URL: https://issues.jboss.org/browse/DROOLS-1127 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Fix For: 7.0.0.Beta1 > > > Any code that does `new Thread()` on GAE throws an exception, because you can't create new threads yourself. > Other future cloud platforms might have a similar restriction. It should be possible to plug in a custom way of creating threads. > *Proposal A)* Add a kieBase configuration property to change the ThreadFactory > {code} > drools.threadFactory = com.user.project.GoogleAppEngineThreadFactory > {code} > *Proposal B)* Add a kieBase configuration property to change the ExecutorServiceFactory > {code} > drools.executorServiceFactory = com.user.project.ExecutorServiceFactory > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-549) HTTP GSSAPI / SPNEGO Authentication

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-549: ------------------------------------ Summary: HTTP GSSAPI / SPNEGO Authentication Key: ELY-549 URL: https://issues.jboss.org/browse/ELY-549 Project: WildFly Elytron Issue Type: Sub-task Components: HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta6 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2040) Seeing a OOM in JGroup 3.4

by Kshitiz Saxena (JIRA)

[ https://issues.jboss.org/browse/JGRP-2040?page=com.atlassian.jira.plugin.... ] Kshitiz Saxena commented on JGRP-2040: -------------------------------------- Just by setting port_range=0 we are not seeing the issue. We are still continuing our tests. Can you please help us understand the port_range property and what impact will it cause by changing to port_range=0 from port_range=1? > Seeing a OOM in JGroup 3.4 > -------------------------- > > Key: JGRP-2040 > URL: https://issues.jboss.org/browse/JGRP-2040 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4 > Environment: Linux Operating System > Reporter: Kshitiz Saxena > Assignee: Bela Ban > > We are seeing an OOM in our application where thread dump points to JGroup. > We see the below in thread dumps, > 3XEHSTTYPE 07:33:24:346241000 GMT j9vm.294 - >setCurrentException index=11 constructorIndex=0 detailMessage=0000000000F61678 > 3XEHSTTYPE 07:33:24:346183000 GMT j9mm.126 - at 0000000050F8CD60 java/lang/Thread.run()V, jit 00007FCF323EA580, pc 00007FCF489E0A36 > 3XEHSTTYPE 07:33:24:346179000 GMT j9mm.126 - at 0000000053644748 *org/jgroups/blocks/TCPConnectionMap$TCPConnection$Receiver.run()*V, jit 0000000000000000, pc 00007FCF3354D334 > 3XEHSTTYPE 07:33:24:346175000 GMT j9mm.101 - J9AllocateIndexableObject() returning NULL! *1650814064 bytes* requested for object of class 0000000050F79700 from memory space 'Generational' id=00007FCF440427C0 > In the thread dump we also see > WARNING : OutOfMemoryError possibly caused by 1650814064 bytes requested for object of class 0000000050F79700 from memory space 'Generational' id=00007FCF440427C0 > Java Heap Information > -Xmx (Maximum Java heap size) : 1280m > -Xms (Initial Java heap size) : 640m > -Xss (Maximum stack size for Java threads) : 256k > Total Java heap size: 1.25 GB > Used Java heap size: 174.27 MB > Free Java heap size: 1.08 GB -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1127) Google App Engine support: Do not call new Thread() by allowing to plug in a custom ThreadFactory

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1127?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1127: ------------------------------------------------- Xiong Zhi Ming <zxiong(a)redhat.com> changed the Status of [bug 1329093|https://bugzilla-qe-05.host.stage.eng.rdu2.redhat.com/show_bug.cg...] from POST to MODIFIED > Google App Engine support: Do not call new Thread() by allowing to plug in a custom ThreadFactory > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-1127 > URL: https://issues.jboss.org/browse/DROOLS-1127 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Fix For: 7.0.0.Beta1 > > > Any code that does `new Thread()` on GAE throws an exception, because you can't create new threads yourself. > Other future cloud platforms might have a similar restriction. It should be possible to plug in a custom way of creating threads. > *Proposal A)* Add a kieBase configuration property to change the ThreadFactory > {code} > drools.threadFactory = com.user.project.GoogleAppEngineThreadFactory > {code} > *Proposal B)* Add a kieBase configuration property to change the ExecutorServiceFactory > {code} > drools.executorServiceFactory = com.user.project.ExecutorServiceFactory > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1125) Google App Engine support: ClassLoader.getSystemClassLoader() throws exception

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1125?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1125: ------------------------------------------------- Xiong Zhi Ming <zxiong(a)redhat.com> changed the Status of [bug 1329093|https://bugzilla-qe-05.host.stage.eng.rdu2.redhat.com/show_bug.cg...] from POST to MODIFIED > Google App Engine support: ClassLoader.getSystemClassLoader() throws exception > ------------------------------------------------------------------------------ > > Key: DROOLS-1125 > URL: https://issues.jboss.org/browse/DROOLS-1125 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Fix For: 7.0.0.Beta1 > > > Class org.kie.internal.utils.ChainedProperties > Every call to get the System Class Loader > confClassLoader = ClassLoader.getSystemClassLoader(); (i.e. lines 133, 169) > raises an exception. > Todo: figure out which particular exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6651) Deprecate servlet 'check-interval' attribute

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6651?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-6651. ----------------------------- Fix Version/s: (was: 10.1.0.Final) Resolution: Won't Fix Attribute still has use in cases filesystem notifications do not work. like certain network filesystems > Deprecate servlet 'check-interval' attribute > -------------------------------------------- > > Key: WFLY-6651 > URL: https://issues.jboss.org/browse/WFLY-6651 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Ingo Weiss > Assignee: Tomaz Cerar > > This attribute is no longer used in WildFly so should be deprecated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6626) Add log message indicating disabled <distributable/> flag from web-fragments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6626?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6626: ----------------------------------------------- Panagiotis Sotiropoulos <psotirop(a)redhat.com> changed the Status of [bug 1337858|https://bugzilla.redhat.com/show_bug.cgi?id=1337858] from NEW to ASSIGNED > Add log message indicating disabled <distributable/> flag from web-fragments > ---------------------------------------------------------------------------- > > Key: WFLY-6626 > URL: https://issues.jboss.org/browse/WFLY-6626 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Aaron Ogburn > Assignee: Stuart Douglas > Attachments: undistributable.war > > > If a web-fragment doesn't have distributable set, then replication is not enabled. This happens silently so it may be confusing to some users that are expecting replication to be enabled when they have set <distributable/> in their WEB-INF/web.xml. > Other third party libraries they included may have web-fragments without distributable set so it'd be nice to log a notification when this happens so that users are easily informed why replication was not enabled as they may have expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2065: --------------------------- Comment: was deleted (was: OneWayTcp shows a latency of ~2 us! Increasing the payload from 9 bytes to (e.g.) 2000 reduces the latency even further to below 1 us! This is weird as in {{RoundTripTcp}} (the round trip version of {{OneWayTcp}}), round trip times are ~50 us; I'd expect ~2-4 us (2x latency)...) > RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer > ------------------------------------------------------------------- > > Key: JGRP-2065 > URL: https://issues.jboss.org/browse/JGRP-2065 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message. > The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later). > {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}. > {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication. > {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used. > Round trip times (both processes on the same box, a Mac mini): > * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us* > * {{RoundTripTcp}}: *46 us* > * {{RoundTripServer}}: *49 us* > Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}. > {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later. > The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2. > Tasks: > * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again > * Try various bundlers (e.g. NoBundler) > * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor) > * The default is 1 sender thread, but try with multiple threads > * Measure perf between sending a message (in the bundler) and receiving it -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 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 May 2016