March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1136) Common mechanism for all secure socket definitions

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1136?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-1136: ----------------------------------- Brain dump article collecting together the related pieces: - https://community.jboss.org/docs/DOC-52501 > Common mechanism for all secure socket definitions > -------------------------------------------------- > > Key: WFLY-1136 > URL: https://issues.jboss.org/browse/WFLY-1136 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Brian Stansberry > Assignee: Darran Lofthouse > Fix For: 9.0.0.CR1 > > > This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010: > >> The JAASSecurityDomain in my opinion should > >> handle all secure socket definitions. Mod-cluster currently does > >> not support JAASSecurityDomains. > I won't comment either way on whether JAASSecurityDomain is how we'll do this, but I definitely agree that a common mechanism should be used for all secure socket definitions. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1809) New discovery protocol to be used in conjunction with SHARED_LOOPBACK

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1809?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1809. ---------------------------- Resolution: Done > New discovery protocol to be used in conjunction with SHARED_LOOPBACK > --------------------------------------------------------------------- > > Key: JGRP-1809 > URL: https://issues.jboss.org/browse/JGRP-1809 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > Sometimes tests in the testsuite fail because the nodes run over SHARED_LOOPBACK fail to discover each other and therefore don't form a cluster. This can happen because discovery requests sent via PING are discarded on a full thread pool. > Because the default test stack doesn't have a MERGE protocol, members won't get merged back. > h5. GOAL > * Create a discovery protocol which always discovers other members registered with the same cluster > h5. SOLUTION > * Instead of using SHARED_LOOPBACK to send and receive discovery requests, query SHARED_LOOPBACK directly for discovery information. E.g. if we have members A,B,C registered with cluster "demo" in SHARED_LOOPBACK, then a node D joining can fetch (via SHARED_LOOPBACK_PING) the PingData of A, B and C directly from SHARED_LOOPBACK. > * This way, we won't have any failed test cases (run over SHARED_LOOPBACK) which fail because no other members were discovered. Also, discovery (even for the first node started in a cluster) is very fast, and we don't need the timeout at all. > * Also, we don't need to add a MERGE protocol to the stack as merging is not needed -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1812) ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1812?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1812: ------------------------------------------- By the way, this is what I see on a passing run: {noformat} ------------- testSharedTransport ----------- 43652 [WARN] UDP: - JGRP000014: the receive buffer of socket MulticastSocket was set to 500KB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux) ------------------------------------------------------------------- GMS: address=A, cluster=cluster-one, physical address=10.3.239.189:56487 ------------------------------------------------------------------- 47050 [TRACE] GMS: - A: no initial members discovered: creating group as first member 47051 [DEBUG] GMS: - A: installing view [A|0] [A] 47052 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl ------------------------------------------------------------------- GMS: address=B, cluster=cluster-two, physical address=10.3.239.189:56487 ------------------------------------------------------------------- 50326 [TRACE] GMS: - B: no initial members discovered: creating group as first member 50327 [DEBUG] GMS: - B: installing view [B|0] [B] 50328 [DEBUG] GMS: - created group (first member). My view is [B|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl [A]<< hello-0 [B]<< hello-0 [A]<< hello-1 [B]<< hello-1 [A]<< hello-2 [B]<< hello-2 [A]<< hello-3 [B]<< hello-3 [A]<< hello-4 [B]<< hello-4 [A]<< hello-5 [A]<< hello-6 [A]<< hello-7 [A]<< hello-8 [A]<< hello-9 50832 [TRACE] GMS: - view [B|1] [] is empty: will not multicast it (last view) 50833 [TRACE] GMS: - view [A|1] [] is empty: will not multicast it (last view) {noformat} > ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages > ----------------------------------------------------------------------------------- > > Key: JGRP-1812 > URL: https://issues.jboss.org/browse/JGRP-1812 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.14 > Environment: RHEL, Solaris > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.14 > > > ProgrammaticApiTest tests the use of the API for creating and configuring channels. One such test testSharedTransport tests the creation and use of a stack with a shared transport. This test does the following: > - creates two channels A and B > - creates a UDP-based shared transport stack > - assigns the same stack to both channels > - channel A connects to group cluster-one; channel B connects to group cluster-two > - channel A multicasts 10 messages to its group; channel B multicasts 5 messages to its group > - the test then waits for the correct number of multicast messages to arrive > Problem:the test is failing because the receiver on channel A is receiving 20 messages instead of 10 messages. > This test fails intermittently, but fairly regularly. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1812) ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1812?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1812: ------------------------------------------- One example of output from a failed instance of the test: {noformat} ------------- testSharedTransport ----------- ------------------------------------------------------------------- GMS: address=A, cluster=cluster-one, physical address=10.16.92.26:49627 ------------------------------------------------------------------- 111009 [TRACE] GMS: - A: no initial members discovered: creating group as first member 111009 [DEBUG] GMS: - A: installing view [A|0] [A] 111010 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl ------------------------------------------------------------------- GMS: address=B, cluster=cluster-two, physical address=10.16.92.26:49627 ------------------------------------------------------------------- 112579 [TRACE] GMS: - A: new members=[A], suspected=[], leaving=[], new view: [A|1] [A, A] 112579 [TRACE] GMS: - A: mcasting view [A|1] [A, A] (2 mbrs) 112580 [DEBUG] GMS: - A: installing view [A|1] [A, A] 112581 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1] 112611 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1] 114019 [TRACE] GMS: - B: initial_mbrs are B 114019 [DEBUG] GMS: - election results: {} 114019 [TRACE] GMS: - could not determine coordinator from responses [B, view_id=, is_server=false, is_coord=false, logical_name=B, physical_addrs=10.16.92.90:53759] 114019 [TRACE] GMS: - clients to choose new coord from are: [B, B] 114019 [TRACE] GMS: - I (B) am not the first of the clients, waiting for another client to become coordinator [A]<< hello-0 [A]<< hello-1 [A]<< hello-2 [A]<< hello-3 [A]<< hello-4 [A]<< hello-5 [A]<< hello-6 [A]<< hello-7 [A]<< hello-8 [A]<< hello-9 116116 [TRACE] GMS: - A: new members=[], suspected=[], leaving=[A], new view: [A|2] [A] 116116 [TRACE] GMS: - A: mcasting view [A|2] [A] (1 mbrs) 116116 [DEBUG] GMS: - A: installing view [A|2] [A] 116118 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2] 117529 [TRACE] GMS: - B: initial_mbrs are B 117529 [DEBUG] GMS: - election results: {} 117529 [TRACE] GMS: - could not determine coordinator from responses [B, view_id=, is_server=false, is_coord=false, logical_name=B, physical_addrs=10.16.92.90:53759] 117529 [TRACE] GMS: - clients to choose new coord from are: [B, B] 117529 [TRACE] GMS: - I (B) am not the first of the clients, waiting for another client to become coordinator 121039 [TRACE] GMS: - B: no initial members discovered: creating group as first member 121039 [DEBUG] GMS: - B: installing view [B|0] [B] 121039 [DEBUG] GMS: - created group (first member). My view is [B|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl [A]<< hello-0 [A]<< hello-1 [A]<< hello-2 [A]<< hello-3 [A]<< hello-4 [A]<< hello-5 [A]<< hello-6 [A]<< hello-7 [A]<< hello-8 121040 [WARN] NAKACK2: - JGRP000011: B: dropped message 1 from non-member B (view=[B|0] [B]) (received 5 identical messages from B in the last 0 ms) [A]<< hello-9 [B]<< hello-0 [B]<< hello-1 [B]<< hello-2 [B]<< hello-3 [B]<< hello-4 131043 [TRACE] GMS: - view [B|1] [] is empty: will not multicast it (last view) 131043 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view) {noformat} I'm not quite sure what the discovery arrangements are for shared transport nor the mapping of channel names to memberships. It's a little hard to follow :-) > ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages > ----------------------------------------------------------------------------------- > > Key: JGRP-1812 > URL: https://issues.jboss.org/browse/JGRP-1812 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.14 > Environment: RHEL, Solaris > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.14 > > > ProgrammaticApiTest tests the use of the API for creating and configuring channels. One such test testSharedTransport tests the creation and use of a stack with a shared transport. This test does the following: > - creates two channels A and B > - creates a UDP-based shared transport stack > - assigns the same stack to both channels > - channel A connects to group cluster-one; channel B connects to group cluster-two > - channel A multicasts 10 messages to its group; channel B multicasts 5 messages to its group > - the test then waits for the correct number of multicast messages to arrive > Problem:the test is failing because the receiver on channel A is receiving 20 messages instead of 10 messages. > This test fails intermittently, but fairly regularly. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1812) ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages

by Richard Achmatowicz (JIRA)

Richard Achmatowicz created JGRP-1812: ----------------------------------------- Summary: ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages Key: JGRP-1812 URL: https://issues.jboss.org/browse/JGRP-1812 Project: JGroups Issue Type: Bug Affects Versions: 3.2.14 Environment: RHEL, Solaris Reporter: Richard Achmatowicz Assignee: Bela Ban Fix For: 3.2.14 ProgrammaticApiTest tests the use of the API for creating and configuring channels. One such test testSharedTransport tests the creation and use of a stack with a shared transport. This test does the following: - creates two channels A and B - creates a UDP-based shared transport stack - assigns the same stack to both channels - channel A connects to group cluster-one; channel B connects to group cluster-two - channel A multicasts 10 messages to its group; channel B multicasts 5 messages to its group - the test then waits for the correct number of multicast messages to arrive Problem:the test is failing because the receiver on channel A is receiving 20 messages instead of 10 messages. This test fails intermittently, but fairly regularly. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3067) Webservices DUP is not scanning all visible classes for @WebService annotation

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.... ] Alessio Soldano resolved WFLY-3067. ----------------------------------- Resolution: Done AFAICS this is solved by https://github.com/wildfly/wildfly/pull/6027 > Webservices DUP is not scanning all visible classes for @WebService annotation > ------------------------------------------------------------------------------ > > Key: WFLY-3067 > URL: https://issues.jboss.org/browse/WFLY-3067 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 8.0.0.Final > Reporter: Kyle Lape > Assignee: Jim Ma > Fix For: 8.0.1.Final > > > Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this: > {noformat} > UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet > {noformat} -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3067) Webservices DUP is not scanning all visible classes for @WebService annotation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3067: ----------------------------------------------- Alessio Soldano <asoldano(a)redhat.com> changed the Status of [bug 1079084|https://bugzilla.redhat.com/show_bug.cgi?id=1079084] from NEW to ASSIGNED > Webservices DUP is not scanning all visible classes for @WebService annotation > ------------------------------------------------------------------------------ > > Key: WFLY-3067 > URL: https://issues.jboss.org/browse/WFLY-3067 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 8.0.0.Final > Reporter: Kyle Lape > Assignee: Jim Ma > Fix For: 8.0.1.Final > > > Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this: > {noformat} > UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet > {noformat} -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3067) Webservices DUP is not scanning all visible classes for @WebService annotation

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-3067: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/5992, https://github.com/wildfly/wildfly/pull/6027 (was: https://github.com/wildfly/wildfly/pull/5992) > Webservices DUP is not scanning all visible classes for @WebService annotation > ------------------------------------------------------------------------------ > > Key: WFLY-3067 > URL: https://issues.jboss.org/browse/WFLY-3067 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 8.0.0.Final > Reporter: Kyle Lape > Assignee: Jim Ma > Fix For: 8.0.1.Final > > > Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this: > {noformat} > UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet > {noformat} -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1019) Validate composite operation steps just before executing them

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-1019?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-1019: ----------------------------------- Labels: EAP (was: ) > Validate composite operation steps just before executing them > ------------------------------------------------------------- > > Key: WFLY-1019 > URL: https://issues.jboss.org/browse/WFLY-1019 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Labels: EAP > > Say we have a composite operation with 2 steps: > 1) /extension=org.jboss.as.messaging:add > 2) /subsystem=messaging:add > This will fail: > Failed to execute batch: JBAS014739: No handler for add at address > [("subsystem" => "messaging")] > This fails because at the time of validation the /subsystem=messaging:add is not valid. > To illustrate, the execution order is > Validate 1-2 > 1 > 2 > A possible solution is to convert this to the following: > V1 > 1 > V2 (works now because 1 has registered the subsystem API) > 2 > I think that should work but it's a very complex area, particularly in a managed domain, so it's not at all certain this would prove feasible. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-850) @TransactionTimeout ignored if method ist not public

by Tomek Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-850?page=com.atlassian.jira.plugin.s... ] Tomek Adamski reassigned WFLY-850: ---------------------------------- Assignee: Tomek Adamski (was: David Lloyd) > @TransactionTimeout ignored if method ist not public > ---------------------------------------------------- > > Key: WFLY-850 > URL: https://issues.jboss.org/browse/WFLY-850 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Reporter: Frank Langelage > Assignee: Tomek Adamski > Priority: Minor > > The annotation @TransactionTimeout is not honored, when the method has other than public access. > @Timeout methods invoked by the container are allowed to have "public, private, protected, or package level access". > So the annotation should work also if method is not public. -- 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, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2014