October 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBASMP-6) Align current versions to all start at 0.1.0-SNAPSHOT

by Andrew Lee Rubinger (JIRA)

Align current versions to all start at 0.1.0-SNAPSHOT ----------------------------------------------------- Key: JBASMP-6 URL: http://jira.jboss.com/jira/browse/JBASMP-6 Project: JBoss AS Maven Plugins Issue Type: Task Components: build, common, control-example, control-plugin Reporter: Andrew Lee Rubinger Assigned To: Andrew Lee Rubinger Fix For: 0.1.0 POMs should be set to same version, 0.1.0-SNAPSHOT, including the Aggregator POM -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
2
0 / 0

[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, 7 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, 7 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, 7 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, 7 months

4
13
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, 7 months

4
23
0 / 0

[JBoss JIRA] Created: (AS7-1928) Allow deployments to get access to the META-INF folder of their dependency module

by Marius Bogoevici (JIRA)

Allow deployments to get access to the META-INF folder of their dependency module --------------------------------------------------------------------------------- Key: AS7-1928 URL: https://issues.jboss.org/browse/AS7-1928 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.1.0.Alpha1 Reporter: Marius Bogoevici Priority: Critical Currently there is absolutely no mechanism (outside of manipulating dependencies programmatically through a subsystem) for deployments to get access to some META-INF/xyz files from a module that they declare as a dependency, except are in META-INF/services. This is a serious impediment when considering the installation of third party libraries as shared libraries (modules) in JBoss AS. Some frameworks may rely upon locating internal descriptors in META-INF, and if the libraries are installed as modules, the descriptors are not accessible to the framework. Essentially, there is no way of accessing resources under META-INF unless they are either services, or the library is packaged in the deployment. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

8
21
0 / 0

[JBoss JIRA] Created: (AS7-1044) Add ability to launch H2 console from AS7 console for standalone mode

by Pete Muir (JIRA)

Add ability to launch H2 console from AS7 console for standalone mode --------------------------------------------------------------------- Key: AS7-1044 URL: https://issues.jboss.org/browse/AS7-1044 Project: Application Server 7 Issue Type: Feature Request Reporter: Pete Muir See http://www.h2database.com/html/tutorial.html#tutorial_starting_h2_console for the console. Add ability to easily access this for the H2 datasources. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

10
10
0 / 0

[JBoss JIRA] Created: (AS7-974) Re-enable Embedded Arquillian Container

by Andrew Rubinger (JIRA)

Re-enable Embedded Arquillian Container --------------------------------------- Key: AS7-974 URL: https://issues.jboss.org/browse/AS7-974 Project: Application Server 7 Issue Type: Task Components: Test Suite Reporter: Andrew Rubinger Assignee: Andrew Rubinger Priority: Critical Fix For: 7.0.0.CR1 Get the Embedded container back up. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

4
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2794) Running More Than 100 Threads Results in ArrayIndexOutOfBoundsException from Drools AbstractHashTable

by Anatoly Polinsky (JIRA)

Running More Than 100 Threads Results in ArrayIndexOutOfBoundsException from Drools AbstractHashTable ----------------------------------------------------------------------------------------------------- Key: JBRULES-2794 URL: https://jira.jboss.org/browse/JBRULES-2794 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.1.1.FINAL, FUTURE Environment: Ubuntu, Intellij / Windows XP, Eclipse Reporter: Anatoly Polinsky Assignee: Mark Proctor Unfortunately it is not a consistent behaviour, but happens quite often. This is not observed at all when running with e.g. 50 threads. java.util.concurrent.ExecutionException: org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction@1102fab at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at com.jpmc.tss.admincenter.framework.workflow.stress.test.WorkflowStressTest.shouldRunFlow(WorkflowStressTest.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74) at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82) at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180) at org.junit.runner.JUnitCore.run(JUnitCore.java:157) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:94) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:192) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:115) Caused by: org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction@1102fab at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1473) at org.drools.common.AbstractWorkingMemory.startProcess(AbstractWorkingMemory.java:1631) at org.drools.impl.StatefulKnowledgeSessionImpl.startProcess(StatefulKnowledgeSessionImpl.java:318) at org.drools.command.runtime.process.StartProcessCommand.execute(StartProcessCommand.java:99) at org.drools.command.runtime.process.StartProcessCommand.execute(StartProcessCommand.java:38) at org.drools.persistence.session.SingleSessionCommandService.execute(SingleSessionCommandService.java:285) at org.drools.command.impl.CommandBasedStatefulKnowledgeSession.startProcess(CommandBasedStatefulKnowledgeSession.java:193) at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191) at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:692) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625) at org.custom.workflow.stress.test.WorkflowRunner.call(WorkflowRunner.java:18) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.ArrayIndexOutOfBoundsException: -1 at org.drools.core.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:317) at org.drools.reteoo.EntryPointNode.updateSink(EntryPointNode.java:323) at org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:303) at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:257) at org.drools.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:92) at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:68) at org.drools.reteoo.Rete.assertObject(Rete.java:111) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:280) at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:360) at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1471) ... 24 more -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
9
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 October 2011