[JBoss JIRA] (JGRP-1814) No physical address for X; dropping message
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1814?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1814:
--------------------------------
The MBR_LEFT event has not been implemented: instead, we close all connections to *members which left*, and the xmit-task will remove them after {{conn_close_timeout}} ms (default: 5s).
The sentence "members which left" means *current members which are not in the new view*, e.g. between views V1=\{A,B,C\} and V2=\{A,C,D\}, member B left. However, if we have a connection to P, P will not get closed as it is *not* in the current view V1.
> No physical address for X; dropping message
> -------------------------------------------
>
> Key: JGRP-1814
> URL: https://issues.jboss.org/browse/JGRP-1814
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When we have view \{A,B\} and B leaves, then the following happens in UNICAST3:
> * B sends a LEAVE-REQ to A
> * A sends a LEAVE-RSP to B
> * Because the LEAVE-RSP is reliable, A keeps sending the LEAVE-RSP to B until it receives an ACK for the LEAVE-RSP
> * However, when B receives the LEAVE-RSP, it marks its connection to be acked, which means that when the next retransmission kicks in, an ACK for the LEAVE-RSP will be sent back to A
> * Before this happens, B leaves: the ACK is never sent to A
> * A keeps resending the LEAVE-RSP until {{max_retransmit_time}} (default=60s) elapses and the connection is closed. However, the connection is only closed after another 60s (default for {{conn_close_timeout}}).
> * Because the reaper removes all entries of {{logical_addr_cache}} before that happens, we're seeing the above warnings
> SOLUTION:
> # Send LEAVE-RSP unreliable. This bypasses UNICAST3 altogether. The leaver won't block forever if the LEAVE-RSP message is dropped, but only for 3 x {{GMS.leave_timeout}} ms
> # Also add a MBR_LEFT event which is sent up and down the stack by GMS when a member left *gracefully*. This allows UNICAST3 to close the connection to a given member *immediately*, stopping unneeded retransmissions to members which left.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (SECURITY-811) NullPointerException in DeploymentRoleToRolesMappingProvider
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/SECURITY-811?page=com.atlassian.jira.plug... ]
Chao Wang updated SECURITY-811:
-------------------------------
Attachment: SECURITY-811-picketbox.patch
> NullPointerException in DeploymentRoleToRolesMappingProvider
> ------------------------------------------------------------
>
> Key: SECURITY-811
> URL: https://issues.jboss.org/browse/SECURITY-811
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Affects Versions: JBossSecurity_2.0.8.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
> Attachments: SECURITY-811-picketbox.patch, SECURITY-811.patch
>
>
> {code:title=DeploymentRoleToRolesMappingProvider.java|borderStyle=solid}
> RoleGroup assignedRoles = (SimpleRoleGroup)contextMap.get(SecurityConstants.ROLES_IDENTIFIER);
> for (Role r: assignedRoles.getRoles()) {
> {code}
> A null value of assignedRoles causes NullPointerException on server if user have not input username / passoword yet
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (WFLY-3087) Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reopened WFLY-3087:
-------------------------------
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3087
> URL: https://issues.jboss.org/browse/WFLY-3087
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: windows server 2008
> Reporter: Admin FlirtyMob
> Assignee: Stuart Douglas
> Fix For: 8.0.1.Final
>
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (SECURITY-811) NullPointerException in DeploymentRoleToRolesMappingProvider
by Chao Wang (JIRA)
Chao Wang created SECURITY-811:
----------------------------------
Summary: NullPointerException in DeploymentRoleToRolesMappingProvider
Key: SECURITY-811
URL: https://issues.jboss.org/browse/SECURITY-811
Project: PicketBox
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JBossSX
Affects Versions: JBossSecurity_2.0.8.Final
Reporter: Chao Wang
Assignee: Chao Wang
Priority: Minor
{code:title=DeploymentRoleToRolesMappingProvider.java|borderStyle=solid}
RoleGroup assignedRoles = (SimpleRoleGroup)contextMap.get(SecurityConstants.ROLES_IDENTIFIER);
for (Role r: assignedRoles.getRoles()) {
{code}
A null value of assignedRoles causes NullPointerException on server if user have not input username / passoword yet
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (WFLY-3109) CloseReason always null for WebSocket onClose methods
by Frank Hempel (JIRA)
[ https://issues.jboss.org/browse/WFLY-3109?page=com.atlassian.jira.plugin.... ]
Frank Hempel commented on WFLY-3109:
------------------------------------
I would just like to confirm this fact. I also see this "reason-always-null"-behaviour on WildFly 8.0.0.Final as well as the lates Snapshot (build #1043 (26.03.2014 18:41:28)).
> CloseReason always null for WebSocket onClose methods
> -----------------------------------------------------
>
> Key: WFLY-3109
> URL: https://issues.jboss.org/browse/WFLY-3109
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final
> Environment: WildFly 8.0.0.Final on Windows 7 Pro (64 bits) with JDK 7.0u51 (64 bits)
> Reporter: Tom Tom
>
> The onClose method of the websocket endpoints does not receive valid CloseReason, it is always null.
> With GlassFish 4.0, the CloseReason is not null and correctly reflects the code and message used to close the wensocket from the client side.
> Simplified code sample of the endpoint:
> @ServerEndpoint(value = "/test", configurator = MyConfigurator.class)
> public class MyEndpoint {
> // onOpen, onMessage and onError, LOGGER are omitted
> @OnClose
> public void onClose(Session session, CloseReason reason) {
> LOGGER.debug("onClose(sessionId={}, reason={})", session.getId(), reason);
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (WFLY-3109) CloseReason always null for WebSocket onClose methods
by Frank Hempel (JIRA)
[ https://issues.jboss.org/browse/WFLY-3109?page=com.atlassian.jira.plugin.... ]
Frank Hempel edited comment on WFLY-3109 at 3/27/14 6:07 AM:
-------------------------------------------------------------
I would just like to confirm this fact. I also see this "reason-always-null"-behaviour on WildFly 8.0.0.Final as well as the latest Snapshot (build #1043 (26.03.2014 18:41:28)).
was (Author: struppimoppi):
I would just like to confirm this fact. I also see this "reason-always-null"-behaviour on WildFly 8.0.0.Final as well as the lates Snapshot (build #1043 (26.03.2014 18:41:28)).
> CloseReason always null for WebSocket onClose methods
> -----------------------------------------------------
>
> Key: WFLY-3109
> URL: https://issues.jboss.org/browse/WFLY-3109
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final
> Environment: WildFly 8.0.0.Final on Windows 7 Pro (64 bits) with JDK 7.0u51 (64 bits)
> Reporter: Tom Tom
>
> The onClose method of the websocket endpoints does not receive valid CloseReason, it is always null.
> With GlassFish 4.0, the CloseReason is not null and correctly reflects the code and message used to close the wensocket from the client side.
> Simplified code sample of the endpoint:
> @ServerEndpoint(value = "/test", configurator = MyConfigurator.class)
> public class MyEndpoint {
> // onOpen, onMessage and onError, LOGGER are omitted
> @OnClose
> public void onClose(Session session, CloseReason reason) {
> LOGGER.debug("onClose(sessionId={}, reason={})", session.getId(), reason);
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (WFLY-3087) Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
by Frank Hempel (JIRA)
[ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.... ]
Frank Hempel commented on WFLY-3087:
------------------------------------
It still bails out with the same traceback. I used the last snapshot, which is build #1043 (26.03.2014 18:41:28). Undertow is there included in version 1.0.3.
But that is no suprise, current master of undertow shows that the code is still the same (https://github.com/undertow-io/undertow/blob/master/websockets-jsr/src/ma...). It probably should better be reported in the undertow tracker. I'm not sure whether you could just move this ticket to the undertow's jira instance or whether it should be opened there separately.
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3087
> URL: https://issues.jboss.org/browse/WFLY-3087
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: windows server 2008
> Reporter: Admin FlirtyMob
> Assignee: Stuart Douglas
> Fix For: 8.0.1.Final
>
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (JGRP-1729) Implement a SASL AuthToken
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1729?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1729.
----------------------------
Resolution: Done
> Implement a SASL AuthToken
> --------------------------
>
> Key: JGRP-1729
> URL: https://issues.jboss.org/browse/JGRP-1729
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Labels: 630, security
> Fix For: 3.5
>
>
> Implementing a SASL AuthToken will give us the ability to use whatever SASL mechs are offered by the underlying platform without introducing new dependencies. It would also replace many of the currently provided AuthToken implementations (MD5, X509, Krb5) with a more secure, flexible implementation (e.g. safe from replay attacks)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months