[JBoss JIRA] (SECURITY-897) Unable to authenticate in SPNEGO Login Module with NullPointerException
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-897?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated SECURITY-897:
--------------------------------------
Fix Version/s: Negotiation_2_3_11_CR1
> Unable to authenticate in SPNEGO Login Module with NullPointerException
> -----------------------------------------------------------------------
>
> Key: SECURITY-897
> URL: https://issues.jboss.org/browse/SECURITY-897
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_2_3_6_Final
> Environment: Red Hat JBoss EAP 6.3.2
> Reporter: Kunjan Rathod
> Assignee: Chao Wang
> Labels: jboss, jboss-as
> Fix For: Negotiation_3_0_0_Final, Negotiation_2_3_11_CR1
>
>
> Description of problem:
> The configuration with SPNEGO works fine, however from time to time the authentication fails with the following error:
> ERROR (HTTP-341) [org.jboss.security.auth.spi.AbstractServerLoginModule] Unable to authenticate: java.lang.NullPointerException
> at org.jboss.security.negotiation.spnego.SPNEGOLoginModule$AcceptSecContext.run(SPNEGOLoginModule.java:420)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
> Version-Release number of selected component (if applicable):
> JBoss Security Negotiation 2.3.3.Final
> How reproducible:
> This happens very rarely (20 times in a day on a system where about 50 users are working) and it is extremely hard to reproduce.
> Additional info:
> At line 420 in [1], the GSSToken is null
> ~~~~
> if (respToken != null)
> {
> NegotiationMessage response;
> if (requestMessage instanceof KerberosMessage)
> {
> response = new KerberosMessage(Constants.KERBEROS_V5, respToken);
> }
> else
> {
> NegTokenTarg negTokenTarg = new NegTokenTarg();
> negTokenTarg.setResponseToken(respToken);
> response = negTokenTarg;
> }
> ~~~~
> It looks like a GSSToken can be or is null, check the line#344 as follows:-
> ~~~~~~~~~
> public Object run()
> {
> try
> {
> // The message type will have already been checked before this point so we know it is
> // a SPNEGO message.
> NegotiationMessage requestMessage = negotiationContext.getRequestMessage();
> // TODO - Ensure no way to fall through with gssToken still null.
> byte[] gssToken = null;
> if (requestMessage instanceof NegTokenInit)
> {
> ...
> ~~~~~~~~~
> [1] : https://github.com/wildfly-security/jboss-negotiation/blob/2.3.3.Final/jb...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2016) oob min/max thread doesn't work when oob_thread_pool_queue_enabled = true
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2016?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2016 at 2/17/16 10:55 AM:
----------------------------------------------------------
This is default behavior of the underlying {{j.u.c.ThreadPoolExecutor}}. If you disable the queue (or set it to a very small size), you'll get more than the 10 min threads. See [1] for details.
Closing this issue now.
[1] http://www.jgroups.org/manual/index.html#_overview_2
was (Author: belaban):
This is default behavior of the underlying {{j.u.c.ThreadPoolExecutor}}. If you disable the queue (or set it to a very small size), you'll get more than the 10 min threads.
Closing this issue now.
> oob min/max thread doesn't work when oob_thread_pool_queue_enabled = true
> --------------------------------------------------------------------------
>
> Key: JGRP-2016
> URL: https://issues.jboss.org/browse/JGRP-2016
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.6.7
> Environment: Linux 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Reporter: rama rama
> Assignee: Bela Ban
> Priority: Critical
>
> hello,
> i have noticed that setting
> oob_thread_pool_min_threads = 10
> oob_thread_pool_max_threads = 100
> oob_thread_pool_queue_enabled = true
> doesn't create new thread (up to 100) but keep thread number at 10 and queue
> items before spawning new threads.
> i think that the same behavioud apply to
> thread_pool_queue_enabled = true
> What is going to block me, it's that if i set 100 threads, i expect to get higher concurrency
> rather than using queue, and use queue AFTER having finished the max_thread.
> in that way the concurrency seem to get limited, am i wrong?
> as a workaround i can set 100 as min thread, but seems to waste quite a lot of resource and ctx switch if my working scenario is just to handle spikes of load every time to time (and on the same server i was thinking of running more application that use the same idea, having all of them create 100 threads sound unhealty)
> forgive my terrible english, any feedback is appreciated
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2016) oob min/max thread doesn't work when oob_thread_pool_queue_enabled = true
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2016?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-2016.
--------------------------
Resolution: Rejected
> oob min/max thread doesn't work when oob_thread_pool_queue_enabled = true
> --------------------------------------------------------------------------
>
> Key: JGRP-2016
> URL: https://issues.jboss.org/browse/JGRP-2016
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.6.7
> Environment: Linux 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Reporter: rama rama
> Assignee: Bela Ban
> Priority: Critical
>
> hello,
> i have noticed that setting
> oob_thread_pool_min_threads = 10
> oob_thread_pool_max_threads = 100
> oob_thread_pool_queue_enabled = true
> doesn't create new thread (up to 100) but keep thread number at 10 and queue
> items before spawning new threads.
> i think that the same behavioud apply to
> thread_pool_queue_enabled = true
> What is going to block me, it's that if i set 100 threads, i expect to get higher concurrency
> rather than using queue, and use queue AFTER having finished the max_thread.
> in that way the concurrency seem to get limited, am i wrong?
> as a workaround i can set 100 as min thread, but seems to waste quite a lot of resource and ctx switch if my working scenario is just to handle spikes of load every time to time (and on the same server i was thinking of running more application that use the same idea, having all of them create 100 threads sound unhealty)
> forgive my terrible english, any feedback is appreciated
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2016) oob min/max thread doesn't work when oob_thread_pool_queue_enabled = true
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2016?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2016:
---------------------------
This is default behavior of the underlying {{j.u.c.ThreadPoolExecutor}}. If you disable the queue (or set it to a very small size), you'll get more than the 10 min threads.
Closing this issue now.
> oob min/max thread doesn't work when oob_thread_pool_queue_enabled = true
> --------------------------------------------------------------------------
>
> Key: JGRP-2016
> URL: https://issues.jboss.org/browse/JGRP-2016
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.6.7
> Environment: Linux 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Reporter: rama rama
> Assignee: Bela Ban
> Priority: Critical
>
> hello,
> i have noticed that setting
> oob_thread_pool_min_threads = 10
> oob_thread_pool_max_threads = 100
> oob_thread_pool_queue_enabled = true
> doesn't create new thread (up to 100) but keep thread number at 10 and queue
> items before spawning new threads.
> i think that the same behavioud apply to
> thread_pool_queue_enabled = true
> What is going to block me, it's that if i set 100 threads, i expect to get higher concurrency
> rather than using queue, and use queue AFTER having finished the max_thread.
> in that way the concurrency seem to get limited, am i wrong?
> as a workaround i can set 100 as min thread, but seems to waste quite a lot of resource and ctx switch if my working scenario is just to handle spikes of load every time to time (and on the same server i was thinking of running more application that use the same idea, having all of them create 100 threads sound unhealty)
> forgive my terrible english, any feedback is appreciated
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2016) oob min/max thread doesn't work when oob_thread_pool_queue_enabled = true
by rama rama (JIRA)
rama rama created JGRP-2016:
-------------------------------
Summary: oob min/max thread doesn't work when oob_thread_pool_queue_enabled = true
Key: JGRP-2016
URL: https://issues.jboss.org/browse/JGRP-2016
Project: JGroups
Issue Type: Enhancement
Affects Versions: 3.6.7
Environment: Linux 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
Reporter: rama rama
Assignee: Bela Ban
Priority: Critical
hello,
i have noticed that setting
oob_thread_pool_min_threads = 10
oob_thread_pool_max_threads = 100
oob_thread_pool_queue_enabled = true
doesn't create new thread (up to 100) but keep thread number at 10 and queue
items before spawning new threads.
i think that the same behavioud apply to
thread_pool_queue_enabled = true
What is going to block me, it's that if i set 100 threads, i expect to get higher concurrency
rather than using queue, and use queue AFTER having finished the max_thread.
in that way the concurrency seem to get limited, am i wrong?
as a workaround i can set 100 as min thread, but seems to waste quite a lot of resource and ctx switch if my working scenario is just to handle spikes of load every time to time (and on the same server i was thinking of running more application that use the same idea, having all of them create 100 threads sound unhealty)
forgive my terrible english, any feedback is appreciated
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6240) Using OPTIMISTIC locking results in "ISPN000112: exception while committing: javax.transaction.xa.XAException" on responseDone()
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-6240:
------------------------------------
Summary: Using OPTIMISTIC locking results in "ISPN000112: exception while committing: javax.transaction.xa.XAException" on responseDone()
Key: WFLY-6240
URL: https://issues.jboss.org/browse/WFLY-6240
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
{noformat}
15:34:39,087 WARN [org.infinispan.transaction.tm.DummyTransaction] (default task-1) ISPN000112: exception while committing: javax.transaction.xa.XAException
at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidateImpl(TransactionXaAdapter.java:242)
at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidate(TransactionXaAdapter.java:235)
at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:103)
at org.infinispan.transaction.tm.DummyTransaction.finishResource(DummyTransaction.java:389)
at org.infinispan.transaction.tm.DummyTransaction.commitResources(DummyTransaction.java:435)
at org.infinispan.transaction.tm.DummyTransaction.runCommit(DummyTransaction.java:314)
at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:105)
at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:73)
at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.close(ActiveTransactionBatch.java:48)
at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:77)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:768)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:557)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6239) CLI: adding a JNDI entry with defualt value containing a '$' at the end
by Valentin Maechler (JIRA)
[ https://issues.jboss.org/browse/WFLY-6239?page=com.atlassian.jira.plugin.... ]
Valentin Maechler updated WFLY-6239:
------------------------------------
Description:
Can not add a JNDI / naming entry which contains a "$" sign at the end of its default value.
e.g. {code}
value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}"
{code}
was:
Can not add a JNDI / naming entry which contains a "$" sign at the end of it's default value.
e.g. {code}
value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}"
{code}
> CLI: adding a JNDI entry with defualt value containing a '$' at the end
> -----------------------------------------------------------------------
>
> Key: WFLY-6239
> URL: https://issues.jboss.org/browse/WFLY-6239
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 10.0.0.Final
> Reporter: Valentin Maechler
> Assignee: Alexey Loubyansky
>
> Can not add a JNDI / naming entry which contains a "$" sign at the end of its default value.
> e.g. {code}
> value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}"
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6239) CLI: adding a JNDI entry with defualt value containing a '$' at the end
by Valentin Maechler (JIRA)
[ https://issues.jboss.org/browse/WFLY-6239?page=com.atlassian.jira.plugin.... ]
Valentin Maechler updated WFLY-6239:
------------------------------------
Description:
Can not add a JNDI / naming entry which contains a "$" sign at the end of it's default value.
e.g. {code}
value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}"
{code}
was:
Can not add a JNDI / naming entry which contains a "$" sign at the end of it's default value.
e.g.
value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}"
> CLI: adding a JNDI entry with defualt value containing a '$' at the end
> -----------------------------------------------------------------------
>
> Key: WFLY-6239
> URL: https://issues.jboss.org/browse/WFLY-6239
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 10.0.0.Final
> Reporter: Valentin Maechler
> Assignee: Alexey Loubyansky
>
> Can not add a JNDI / naming entry which contains a "$" sign at the end of it's default value.
> e.g. {code}
> value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}"
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6239) CLI: adding a JNDI entry with defualt value containing a '$' at the end
by Valentin Maechler (JIRA)
[ https://issues.jboss.org/browse/WFLY-6239?page=com.atlassian.jira.plugin.... ]
Valentin Maechler updated WFLY-6239:
------------------------------------
Steps to Reproduce:
The following commands fail in Wildfly 10 CLI (worked with Wildfly 8):
{code}
$JBOSS_HOME/bin/jboss-cli.sh
[disconnected /] connect
#### preparation
[standalone@localhost:9990 /] /system-property=my.sample.property1:add(value=sample-value-1)
{"outcome" => "success"}
[standalone@localhost:9990 /] /system-property=my.sample.property1:read-resource
{
"outcome" => "success",
"result" => {"value" => "sample-value-1"}
}
#####
[standalone@localhost:9990 /] /subsystem=naming/binding=java\:global\/my\/sample\/entry:add(binding-type=simple, type=java.lang.String, value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}")
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0370: Incomplete expression: ${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}",
"rolled-back" => true
}
{code}
was:
The following commands fail in Wildfly 10 CLI (worked with Wildfly 8):
$JBOSS_HOME/bin/jboss-cli.sh
[disconnected /] connect
#### preparation
[standalone@localhost:9990 /] /system-property=my.sample.property1:add(value=sample-value-1)
{"outcome" => "success"}
[standalone@localhost:9990 /] /system-property=my.sample.property1:read-resource
{
"outcome" => "success",
"result" => {"value" => "sample-value-1"}
}
#####
[standalone@localhost:9990 /] /subsystem=naming/binding=java\:global\/my\/sample\/entry:add(binding-type=simple, type=java.lang.String, value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}")
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0370: Incomplete expression: ${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}",
"rolled-back" => true
}
> CLI: adding a JNDI entry with defualt value containing a '$' at the end
> -----------------------------------------------------------------------
>
> Key: WFLY-6239
> URL: https://issues.jboss.org/browse/WFLY-6239
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 10.0.0.Final
> Reporter: Valentin Maechler
> Assignee: Alexey Loubyansky
>
> Can not add a JNDI / naming entry which contains a "$" sign at the end of it's default value.
> e.g.
> value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months