June 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBBUILD-682) http://repository.jboss.org/maven2/ serving HTTP 403 to hosts outside RedHat VPN

by Marek Schmidt (JIRA)

http://repository.jboss.org/maven2/ serving HTTP 403 to hosts outside RedHat VPN -------------------------------------------------------------------------------- Key: JBBUILD-682 URL: https://issues.jboss.org/browse/JBBUILD-682 Project: JBoss Build System Issue Type: Bug Reporter: Marek Schmidt Assignee: Paul Gier Priority: Critical The legacy maven repository http://repository.jboss.org/maven2/ is serving HTTP 403 to hosts outside RedHat VPN, causing lots of builds to fail. e.g. http://community.jboss.org/message/606819?tstart=0 with error: Access denied to: http://repository.jboss.org/maven2/trove/trove/2.1.1/trove-2.1.1.pom -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

11
23
0 / 0

[JBoss JIRA] Created: (JBBUILD-666) upload hsqldb 2.0.1-rc3 to our nexus

by Strong Liu (JIRA)

upload hsqldb 2.0.1-rc3 to our nexus ------------------------------------ Key: JBBUILD-666 URL: https://issues.jboss.org/browse/JBBUILD-666 Project: JBoss Build System Issue Type: Task Components: Sonatype Reporter: Strong Liu Assignee: Paul Gier since hsqldb 2.0.0 has some problems, we need 2.0.1-rc3 to run the test now, only 2.0.0 is available on the nexus (maven-central) so, would you please upload this one http://sourceforge.net/projects/hsqldb/files/alpha_beta/hsqldb-2.0.1-rc3.... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-8134) Common mechanism for all secure socket definitions

by Brian Stansberry (JIRA)

Common mechanism for all secure socket definitions -------------------------------------------------- Key: JBAS-8134 URL: https://jira.jboss.org/browse/JBAS-8134 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: Unscheduled 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 contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

6
12
0 / 0

[JBoss JIRA] Created: (JGRP-1326) Gossip Router dropping message for node that is in its routing table list

by vivek v (JIRA)

Gossip Router dropping message for node that is in its routing table list ------------------------------------------------------------------------- Key: JGRP-1326 URL: https://issues.jboss.org/browse/JGRP-1326 Project: JGroups Issue Type: Bug Affects Versions: 2.10 Environment: Linux, Windows Reporter: vivek v Assignee: Bela Ban We are using Tunnel protocol with two Gossip Routers. For some reason we start seeing lots of suspect messages in all the nodes - there are 7 nodes in the group. Six of the nodes (including the coordinator) was suspecting node A (manager_172.27.75.11) and node A was suspecting the coordinator, but no new view was being created. After turning on the trace on both gossip routers (GR1 and GR2) I see following for every message that's sent to Node A (manager_172.27.75.11), {noformat} 2011-05-20 15:56:21,186 TRACE [gossip-handlers-6] GossipRouter - cannot find manager_172.27.75.11:4576 in the routing table, routing table= 172.27.75.11_group: probe_172.27.75.13:4576, collector_172.27.75.12:4576, probe_172.27.75.15:4576, manager_172.27.75.11:4576, probe_172.27.75.16:4576, probe_172.27.75.14:4576 {noformat} Now, the issue is the routing table does indeed shows that there is "manager_172.27.75.11" - so why is the GR dropping messages for that node. I suspect that somehow the Gossip Router has got some old entry which has not been cleaned up - different UUID with same logical address. I tried going through the GossipRouter.java code, but couldn't find how would this be possible. As I understand a node randomly chooses a GR if there are multiple of them for its communication. Each GR would keep a separate list of physical addresses for each node - so is it possible somehow it uses physical address instead of UUID for cleaning/retrieving the node list? This seems to be creating big issue and the only work around is to restart the Gossip Routers. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
13
0 / 0

[JBoss JIRA] (AS7-5059) Deprecate no-arg OperationContext.completeStep() variant

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-5059: ------------------------------------- Summary: Deprecate no-arg OperationContext.completeStep() variant Key: AS7-5059 URL: https://issues.jboss.org/browse/AS7-5059 Project: Application Server 7 Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Deprecate OperationContext.completeStep() in favor of OperationContext.completeStep(RollbackHandler) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
5
0 / 0

[JBoss JIRA] Created: (JGRP-1165) Out-of-sync views in the cluster causes NAKACK issues and invalid node list at application layer

by vivek v (JIRA)

Out-of-sync views in the cluster causes NAKACK issues and invalid node list at application layer ------------------------------------------------------------------------------------------------- Key: JGRP-1165 URL: https://jira.jboss.org/jira/browse/JGRP-1165 Project: JGroups Issue Type: Bug Affects Versions: 2.9, 2.8 Reporter: vivek v Assignee: Bela Ban There is a logic in GMS (in the installView(..) method) where it checks whether the node itself is in the view or not, if not then just discard the view, if(checkSelfInclusion(mbrs) == false) { if(log.isWarnEnabled()) log.warn(local_addr + ": not member of view " + new_view + "; discarding it"); return; } Now, the problem /w this logic is that the node will remain /w the old view and when trying to send message to the members in the old view the messages would be discarded /w NAKACK as this node won't be there in their new view. So here is an example, 1) 3 nodes all with same view - V1 {n1, n2, n3} 2) n1 (coordinator) suspects (due to missing heartbeat) n2 and publishes new view - V2 {n1, n3} - n2 discards the suspect message from n1 as FD_SOCK is still connected 3) n2 receives this view, but discards it due to the logic in GMS 4) n2 still keeps the old view V1 and continue to send messages to n1 and n3. n1 and n3 will discard messages from n2 /w NAKACK as it's not in their view (V2). 5) After few minutes (could be 10-15 minutes or more) n1 will publish a merge view V3(n1, n2,n3} - joining V1 and V2. Now all nodes got the same view The problem is on n2 the application layer will never know that it can't talk to n1 and n3 - thus, the RPC calls will fail during the time the nodes had different views. I would assume if a node gets a view, which doesn't have itself in it - it should drop all the nodes that are in that new view. So, basically we will create two new subgroups. This way we won't discard messages from each other. The application layer needs to know at all times what nodes can it talk to. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
23
0 / 0

[JBoss JIRA] (JBRULES-3562) Drools cannot resolve functions when argument is a fact type

by Nedo Nedic (JIRA)

Nedo Nedic created JBRULES-3562: ----------------------------------- Summary: Drools cannot resolve functions when argument is a fact type Key: JBRULES-3562 URL: https://issues.jboss.org/browse/JBRULES-3562 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.3.0.Final Environment: Linux Ubuntu, JBoss 5.1.0 Reporter: Nedo Nedic Assignee: Mark Proctor Note that this only fails when MVEL dialect is used using non-primitive argument types (for an instance using fact types arguments). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

3
31
0 / 0

[JBoss JIRA] (AS7-5050) Expose javax.annotation.processing in system module

by Julien Viet (JIRA)

Julien Viet created AS7-5050: -------------------------------- Summary: Expose javax.annotation.processing in system module Key: AS7-5050 URL: https://issues.jboss.org/browse/AS7-5050 Project: Application Server 7 Issue Type: Bug Components: Class Loading Affects Versions: 7.1.1.Final Reporter: Julien Viet Assignee: David Lloyd Priority: Minor The path javax.annotation.processing is not exposed and break applications that needs it. Adding <path name="javax/annotation/processing"/> to api/main/modules.xml solves the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

3
5
0 / 0

[JBoss JIRA] (AS7-4970) Upgrade JBoss Logging

by Juergen Zimmermann (JIRA)

Juergen Zimmermann created AS7-4970: --------------------------------------- Summary: Upgrade JBoss Logging Key: AS7-4970 URL: https://issues.jboss.org/browse/AS7-4970 Project: Application Server 7 Issue Type: Feature Request Components: Remoting Affects Versions: 7.1.2.Final (EAP) Reporter: Juergen Zimmermann Assignee: David Lloyd jboss-remoting 3.2.7 is using these versions in pom.xml which are not up-to-date: * logging.version: 3.1.0.GA -> 3.1.1.GA * logging-tools.version: 1.0.0.GA -> 1.0.2.GA * logmanager.version: 1.2.0.GA -> 1.3.1.GA -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
2
0 / 0

[JBoss JIRA] (AS7-4460) Speed up clustering test suite using ARQ custom containers

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-4460: ----------------------------------- Summary: Speed up clustering test suite using ARQ custom containers Key: AS7-4460 URL: https://issues.jboss.org/browse/AS7-4460 Project: Application Server 7 Issue Type: Feature Request Components: Clustering, Test Suite Affects Versions: 7.1.1.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 7.1.2.Final-redhat1 Leveraging ARQ-850. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
2
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 2012