[JBoss JIRA] (WFLY-4308) Proxies created via ContextService.createContextualProxy(...) are not Serializable
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4308?page=com.atlassian.jira.plugin.... ]
Eduardo Martins reassigned WFLY-4308:
-------------------------------------
Assignee: Eduardo Martins (was: David Lloyd)
> Proxies created via ContextService.createContextualProxy(...) are not Serializable
> ----------------------------------------------------------------------------------
>
> Key: WFLY-4308
> URL: https://issues.jboss.org/browse/WFLY-4308
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 9.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Eduardo Martins
> Priority: Critical
>
> Setting priority to critical since, I believe, this is a matter of compliance with the concurrency utilities specification.
> Section 3.3.4 of the specification states that:
> "All invocation handlers for the contextual proxy implementation must implement java.io.Serializable."
> While the invocation handler of the generated proxy does indeed implement Serializable, it contains a reference to org.jboss.as.server.moduleservice.ServiceModuleLoader (among others), which is not serializable, thus attempts to serialize the proxies generated via ContextService.createContextualProxy(...) via JBoss Marshalling throw a org.infinispan.commons.marshall.NotSerializableException: org.jboss.as.server.moduleservice.ServiceModuleLoader
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBJCA-1280) <max-pool-size> can be 0
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1280:
--------------------------------------
Summary: <max-pool-size> can be 0
Key: JBJCA-1280
URL: https://issues.jboss.org/browse/JBJCA-1280
Project: IronJacamar
Issue Type: Bug
Components: Common
Affects Versions: 1.2.4.Final
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.2.5.Final
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 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 resolved WFLY-4790.
----------------------------------
Fix Version/s: 10.0.0.Alpha5
Resolution: Done
This should be fixed now
> 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.Alpha5
>
>
> 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
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1914:
---------------------------
Fix Version/s: 3.6.5
(was: 3.6.4)
Mark, I need to start the 3.6.4 release, moved this to 3.6.5.
> S3_PING doesn't work with S3 buckets created in Frankfurt region
> -----------------------------------------------------------------
>
> Key: JGRP-1914
> URL: https://issues.jboss.org/browse/JGRP-1914
> Project: JGroups
> Issue Type: Bug
> Reporter: Gleb Leonov
> Assignee: Bela Ban
> Fix For: 3.6.5
>
>
> I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (SECURITY-897) Unable to authenticate in SPNEGO Login Module with NullPointerException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-897?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration updated SECURITY-897:
---------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1236606
> 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, Negotiation_2_3_3_Final
> Environment: Red Hat JBoss EAP 6.3.2
> Reporter: Kunjan Rathod
> Assignee: Darran Lofthouse
> Labels: jboss, jboss-as
>
> 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.3.15#6346)
10 years, 10 months
[JBoss JIRA] (SECURITY-897) Unable to authenticate in SPNEGO Login Module with NullPointerException
by Kunjan Rathod (JIRA)
Kunjan Rathod created SECURITY-897:
--------------------------------------
Summary: 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_3_Final, Negotiation_2_3_6_Final
Environment: Red Hat JBoss EAP 6.3.2
Reporter: Kunjan Rathod
Assignee: Darran Lofthouse
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.3.15#6346)
10 years, 10 months