June 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1280) <max-pool-size> can be 0

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1280?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1280. ------------------------------------ Resolution: Done > <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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region

by Mark Morris (JIRA)

[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ] Mark Morris updated JGRP-1914: ------------------------------ Ok Thx Bela, I’ll adjust to 3.6.5. -Mark > 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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (JGRP-1938) VersionTest fails with snapshot version

by Bela Ban (JIRA)

Bela Ban created JGRP-1938: ------------------------------ Summary: VersionTest fails with snapshot version Key: JGRP-1938 URL: https://issues.jboss.org/browse/JGRP-1938 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.5 This fails e.g. with 3.6.5-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (JGRP-886) TCP_NIO: revive and support as additional transport

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-886?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-886: -------------------------- Fix Version/s: 3.6.5 (was: 4.0) Moved to 3.6.5, so people can still use Java 7. > TCP_NIO: revive and support as additional transport > --------------------------------------------------- > > Key: JGRP-886 > URL: https://issues.jboss.org/browse/JGRP-886 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.5 > > > Merge TCP and TCP_NIO into one protocol. Adapt it to use NIO2 (when available). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2015