January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-641) Explore data center failover for clusters at the JGroups level

by Jimmy Wilson (JIRA)

Explore data center failover for clusters at the JGroups level -------------------------------------------------------------- Key: JGRP-641 URL: http://jira.jboss.com/jira/browse/JGRP-641 Project: JGroups Issue Type: Task Affects Versions: 2.x Reporter: Jimmy Wilson Assigned To: Bela Ban Priority: Minor Explore the possibility of using a JGroups protocol (or other mechanism) to provide data center fail over. Possible use cases: * Primary/Backup * Loadbalancing w/ sticky sessions * Rolling updates * Shared data Wiki generated from this discussion (was JBossCache-specific): http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheAcrossDataCentres The forum discussion has been associated with this JIRA as well. -- 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, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-1020) CLOUD_PING: investigate discovery protocol (similar to FILE_PING) on S3 etc

by Bela Ban (JIRA)

CLOUD_PING: investigate discovery protocol (similar to FILE_PING) on S3 etc --------------------------------------------------------------------------- Key: JGRP-1020 URL: https://jira.jboss.org/jira/browse/JGRP-1020 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.x -- 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, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-973) DistributedLockManager: lock() should block for timeout ms until it can acquire lock

by Bela Ban (JIRA)

DistributedLockManager: lock() should block for timeout ms until it can acquire lock ------------------------------------------------------------------------------------ Key: JGRP-973 URL: https://jira.jboss.org/jira/browse/JGRP-973 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 2.8 Currently, lock() throw an exception *immediately* if the lock is held by someone else. It doesn't respect the timeout parameter, change this. This might be possible by picking a different VotingAdapter, have to investigate. -- 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, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-1272) FC: all threads are blocked at credits_available.await

by Victor N (JIRA)

FC: all threads are blocked at credits_available.await ------------------------------------------------------ Key: JGRP-1272 URL: https://issues.jboss.org/browse/JGRP-1272 Project: JGroups Issue Type: Bug Affects Versions: 2.11 Environment: ubuntu 10.04.1 Reporter: Victor N Assignee: Bela Ban Attachments: jgroups-tcp.xml After several days of working one node can not rejoin because of FC protocol issue. The situation is reproduced once or several times per week. The problematic node is called "gate9", its view is outdated: [gate10.mydomain|1175] [gate10.mydomain, gate7.mydomain, gate8.mydomain, gate9.mydomain, gate11.mydomain, gate14.mydomain, gate5.mydomain, gate12.mydomain, gate2.mydomain, gate4.mydomain, gate3.mydomain, gate6.mydomain] Actual view (seen by all other nodes) is: [gate10.mydomain|1176] [gate10.mydomain, gate7.mydomain, gate8.mydomain, gate11.mydomain, gate14.mydomain, gate5.mydomain, gate12.mydomain, gate2.mydomain, gate4.mydomain, gate3.mydomain, gate6.mydomain] In log file at gate9 I can see that it sends CREDIT_REQUEST constantly: 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate10.mydomain, src=gate9.mydomain, headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=4308, conn_id=14, TCP: [channel_name=GateCluster] 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.BasicTCP.sendUnicast(): dest=192.168.1.10:40001 (94 bytes) 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.UNICAST.retransmit(): gate9.mydomain --> XMIT(gate10.mydomain: #2014) 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate10.mydomain, src=gate9.mydomain, headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=2014, conn_id=14, TCP: [channel_name=GateCluster] 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.BasicTCP.sendUnicast(): dest=192.168.1.10:40001 (94 bytes) 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.UNICAST.retransmit(): gate9.mydomain --> XMIT(gate10.mydomain: #1124) ... At gate10 (the coordinator) I see that it receives the requests and responds: 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.passMessageUp(): received [dst: gate10.mydomain, src: gate9.mydomain (3 headers), size=9 bytes], headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=2397, conn_id=14, TCP: [channel_name=GateCluster] 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.handleDataReceived(): gate10.mydomain <-- DATA(gate9.mydomain: #2397, conn_id=14) 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.sendRequestForFirstSeqno(): gate10.mydomain --> SEND_FIRST_SEQNO(gate9.mydomain) 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate9.mydomain, src=gate10.mydomain, headers are UNICAST: SEND_FIRST_SEQNO, seqno=0, TCP: [channel_name=GateCluster] 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.passMessageUp(): received [dst: gate10.mydomain, src: gate9.mydomain (3 headers), size=9 bytes], headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=1202, conn_id=14, TCP: [channel_name=GateCluster] 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.handleDataReceived(): gate10.mydomain <-- DATA(gate9.mydomain: #1202, conn_id=14) 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.sendRequestForFirstSeqno(): gate10.mydomain --> SEND_FIRST_SEQNO(gate9.mydomain) 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate9.mydomain, src=gate10.mydomain, headers are UNICAST: SEND_FIRST_SEQNO, seqno=0, TCP: [channel_name=GateCluster] ... but I do not see any answer to this at gate9. My config and stack traces are attached below. I do not know how to reproduce the problem in tests. But it occurs, so I can provide you with any details, just let me know. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
7
0 / 0

[JBoss JIRA] Created: (JGRP-1238) STABLE: determine best value for max_bytes

by Bela Ban (JIRA)

STABLE: determine best value for max_bytes ------------------------------------------ Key: JGRP-1238 URL: https://jira.jboss.org/browse/JGRP-1238 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.11 max_bytes should be determined as a function of the available memory, a max value that cannot be exceeded and the number of nodes in the cluster. If we have more cluster nodes, and everyone sends messages, then *not* changing max_value would lead to too many STABLE messages being sent ! An example could be: max_bytes="1m" cap="0.25" // 25% of the available heap If we have 5 nodes in the cluster, max_bytes would be set to 5m. With a heap of 100MiB, if we have 30 nodes, max_bytes would be set to max(30Mib, 0.25 * 100 Mib) == 25 MiB. -- 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, 11 months

1
6
0 / 0

[JBoss JIRA] Created: (LOGTOOL-8) Exception create methods fail to compile if the exception type appears in source code (as opposed to being on the class path)

by David Lloyd (JIRA)

Exception create methods fail to compile if the exception type appears in source code (as opposed to being on the class path) ----------------------------------------------------------------------------------------------------------------------------- Key: LOGTOOL-8 URL: https://issues.jboss.org/browse/LOGTOOL-8 Project: Log Tool Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David Lloyd For methods which construct an exception, if the returned exception type is part of the module being compiled (as opposed to being on the compiled class path), processing fails with this exception: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project invocation-api: Compilation failure [ERROR] /home/david/src/java/rws/invokable-container/api/src/main/java/org/jboss/invocation/InvocationLogger.java:[38,24] Return type org.jboss.invocation.InvocationException for method invocationException(java.lang.Throwable) is not in the classpath -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
6
0 / 0

[JBoss JIRA] Created: (JBRULES-2868) NullPointerException in KnowledgeSessionDefinitionParser

by bodi bajk (JIRA)

NullPointerException in KnowledgeSessionDefinitionParser -------------------------------------------------------- Key: JBRULES-2868 URL: https://issues.jboss.org/browse/JBRULES-2868 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-spring Affects Versions: 5.2.0.M1 Reporter: bodi bajk Assignee: Mark Proctor Fix For: FUTURE Stack trace: Caused by: java.lang.NullPointerException at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:321) at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1335) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1325) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390) For example, my applicationContext.xml: ..... <bean id="config" factory-method="getConfiguration" factory-bean="configFactory" /> ..... solution: class: org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser method: parseInternal line : if ( def.getBeanClassName().equals( KnowledgeAgentBeanFactory.class.getName() ) ) { should be replaced with somethig like this: if ( KnowledgeAgentBeanFactory.class.getName().equals( def.getBeanClassName() ) ) { -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2689) [drools-spring] KnowledgeSessionDefinitionParser generates nullpointerexception on parsing spring xml file due to missing class attribute on bean

by David Coleman (JIRA)

[drools-spring] KnowledgeSessionDefinitionParser generates nullpointerexception on parsing spring xml file due to missing class attribute on bean ------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-2689 URL: https://jira.jboss.org/browse/JBRULES-2689 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.1.0.FINAL Reporter: David Coleman Assignee: Mark Proctor Priority: Minor The error below is generated on application load when a spring bean does not specify the class attribute. Spring beans do not need to specify the class attribute as it can use the attribute parent to inherit other spring beans. Caused by: java.lang.NullPointerException at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:287) at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1335) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1325) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:136) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390) The equals comparison on 287 should be reversed to avoidthe null pointer exception but it should also take the class of the parent into account if it has been defined. -- 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, 11 months

3
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2727) NullPointerException due to abstract Spring beans in KnowledgeSessionDefinitionParser

by Silvio Wangler (JIRA)

NullPointerException due to abstract Spring beans in KnowledgeSessionDefinitionParser ------------------------------------------------------------------------------------- Key: JBRULES-2727 URL: https://jira.jboss.org/browse/JBRULES-2727 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.1.1.FINAL Environment: Ubuntu 10.10, Windows XP, Java 6 Reporter: Silvio Wangler Assignee: Mark Proctor Priority: Blocker Fix For: 5.2.0.M1 This bug is located in the drools-spring component in class _org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.java_ The class compares each Spring bean with a non NullPointer safe equals call. {code} // find any kagent's for the current kbase and assign for ( String beanName : parserContext.getRegistry().getBeanDefinitionNames() ) { BeanDefinition def = parserContext.getRegistry().getBeanDefinition(beanName); // is null if the Spring bean is abstract if ( def.getBeanClassName().equals( KnowledgeAgentBeanFactory.class.getName() ) ) { // NullPointerException comes here due to the abstract bean that does not have a bean definition PropertyValue pvalue = def.getPropertyValues().getPropertyValue( "kbase" ); RuntimeBeanReference tbf = ( RuntimeBeanReference ) pvalue.getValue(); if ( kbase.equals( tbf.getBeanName() ) ) { factory.addPropertyValue( "knowledgeAgent", new RuntimeBeanReference( beanName ) ); } } } {code} We use abstract beans in our Spring project and it seems that an abstract bean does not have a _BeanDefinition_ {code} <bean id="i18NServiceConfig" abstract="true"> <property name="xxx"> <ref local="yyy" /> </property> </bean> <bean class="de.corag.bpm.cone.service.i18n.I18NServiceImpl" parent="i18NServiceConfig"> <property name="messageDao"><ref bean="messageDao"/></property> </bean> {code} if you change the equals statement like this no NullPointerException would be thrown {code} // find any kagent's for the current kbase and assign for ( String beanName : parserContext.getRegistry().getBeanDefinitionNames() ) { BeanDefinition def = parserContext.getRegistry().getBeanDefinition(beanName); if ( KnowledgeAgentBeanFactory.class.getName().equals( def.getBeanClassName() ) ) { // NullPointerException comes here due to the abstract bean that does not have a bean definition PropertyValue pvalue = def.getPropertyValues().getPropertyValue( "kbase" ); RuntimeBeanReference tbf = ( RuntimeBeanReference ) pvalue.getValue(); if ( kbase.equals( tbf.getBeanName() ) ) { factory.addPropertyValue( "knowledgeAgent", new RuntimeBeanReference( beanName ) ); } } } {code} -- 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, 11 months

4
6
0 / 0

[JBoss JIRA] Created: (JBJPA-34) CLONE - Hibernate logs warning for PersistenceUnitInfo.newTempClassLoader() == null, which it always is in EJB3

by Brad Maxwell (JIRA)

CLONE - Hibernate logs warning for PersistenceUnitInfo.newTempClassLoader() == null, which it always is in EJB3 --------------------------------------------------------------------------------------------------------------- Key: JBJPA-34 URL: https://issues.jboss.org/browse/JBJPA-34 Project: JBoss JPA Issue Type: Bug Components: mcint Affects Versions: 1.0.0 Environment: JBoss Enterprise Application Platform 5.0.1 Reporter: Brad Maxwell Assignee: Brad Maxwell Fix For: 1.0.1 Looks like https://jira.jboss.org/browse/EJBTHREE-982 did not make it into JBoss 5 WARN [Ejb3Configuration] Persistence provider caller does not implements the EJB3 spec correctly. PersistenceUnitInfo.getN ewTempClassLoader() is null. Coming from org.hibernate.ejb.Ejb3Configuration private void addXMLEntities(List<String> xmlFiles, PersistenceUnitInfo info, List<String> entities) { //TODO handle inputstream related hbm files ClassLoader newTempClassLoader = info.getNewTempClassLoader(); if (newTempClassLoader == null) { log.warn( "Persistence provider caller does not implements the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null." ); return; } However, implementation of org.jboss.ejb3.entity.PersistenceUnitInfoImpl has: public ClassLoader getNewTempClassLoader() { return null; } -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2011