March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3105) Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-3105: ------------------------------------ And for verifying the fix as well! :) > Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-3105 > URL: https://issues.jboss.org/browse/WFLY-3105 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Affects Versions: 8.0.0.Final > Reporter: Christian Bauer > Assignee: Scott Marlow > Fix For: 8.0.1.Final > > > https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/s... > Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. > Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3105) Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-3105. ------------------------------ Thanks for reporting this Christian! > Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-3105 > URL: https://issues.jboss.org/browse/WFLY-3105 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Affects Versions: 8.0.0.Final > Reporter: Christian Bauer > Assignee: Scott Marlow > Fix For: 8.0.1.Final > > > https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/s... > Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. > Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1815) TP: sending a message to a non-existent physical address takes too much time

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1815?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1815. ---------------------------- Resolution: Done > TP: sending a message to a non-existent physical address takes too much time > ---------------------------------------------------------------------------- > > Key: JGRP-1815 > URL: https://issues.jboss.org/browse/JGRP-1815 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > When sending a message in the transport, e.g. a message batch, and one or more destinations have no physical addresses in {{logical_addr_cache}}, then we loop {{physical_addr_max_fetch_attempts}} (default: 3) times and also sleep a random number of ms (in range [1..500]). > This delays the sending of other messages in the same batch, or of other messages in general. Also, if TransferQueueBundler is used, the transfer queue might get filled, so other sender threads are blocked. > SOLUTION: > * Remove the loop when sending a message: if the physical address for a message is not found, simply send a discovery request and drop the message > * The discovery request needs to be sent on a separate thread, as calling {{up(Event)}} directly could also delay the sending of the message or message batch. > * JGRP-1814 will also help, as connections to left members are closed, and therefore not finding a physical address for a destination should be rare -- 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

12 years, 1 month

1
0
0 / 0

[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 resolved JGRP-1814. ---------------------------- Resolution: Done > 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3114) @Resource(lookup="java:...") causes an exception for URL resources

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-3114?page=com.atlassian.jira.plugin.... ] Eduardo Martins closed WFLY-3114. --------------------------------- Assignee: Eduardo Martins Resolution: Out of Date > @Resource(lookup="java:...") causes an exception for URL resources > ------------------------------------------------------------------- > > Key: WFLY-3114 > URL: https://issues.jboss.org/browse/WFLY-3114 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Thomas Kriechbaum > Assignee: Eduardo Martins > > When referencing an URL resource via @Resource the lookup-property only supports a valid URLs (e.g. http://www.jboss.org). A JNDI-Name causes an exception (e.g. java:global/url/Configuration or java:app/url/Configuration) > Issue has been discussed in the user form. > Note: > @Resource(name="java:global/url/Configuration") works. > From my point of view, the javadoc of @Resource is not very easy to understand. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3115) JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-3115?page=com.atlassian.jira.plugin.... ] Eduardo Martins closed WFLY-3115. --------------------------------- Assignee: Eduardo Martins Resolution: Out of Date > JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources > ----------------------------------------------------------------------------------------- > > Key: WFLY-3115 > URL: https://issues.jboss.org/browse/WFLY-3115 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Thomas Kriechbaum > Assignee: Eduardo Martins > > When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported. > When defining JNDI-names (e.g. java:jboss/url/Configuration) instead of concrete URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml). > see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952 -- 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

12 years, 1 month

1
0
0 / 0

[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

12 years, 1 month

1
0
0 / 0

[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

12 years, 1 month

1
0
0 / 0

[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

12 years, 1 month

1
0
0 / 0

[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

12 years, 1 month

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 March 2014