March 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4115) Improve imap/pop3 support in mail-ra.rar

by Peter Muir (JIRA)

Improve imap/pop3 support in mail-ra.rar ----------------------------------------- Key: JBAS-4115 URL: http://jira.jboss.com/jira/browse/JBAS-4115 Project: JBoss Application Server Issue Type: Patch Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.0.5.GA Reporter: Peter Muir Assigned To: Weston Price -- 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

16 years

3
9
0 / 0

[JBoss JIRA] Created: (JBAS-3594) Allow HAPartitionStateTransfer subscribers to get state after HAPartition start() is called.

by Brian Stansberry (JIRA)

Allow HAPartitionStateTransfer subscribers to get state after HAPartition start() is called. -------------------------------------------------------------------------------------------- Key: JBAS-3594 URL: http://jira.jboss.com/jira/browse/JBAS-3594 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.1.CR1 Use the JGroups partial state transfer API for this. Remove the need for dependent services to register as a subscriber before HAPartition.start() is called. Having services interact with HAPartition before start() is contrary to the intended lifecycle semantics. -- 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

16 years

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-692) Unable to recover from suspect/merge, with auto-reconnect

by Matt Magoffin (JIRA)

Unable to recover from suspect/merge, with auto-reconnect --------------------------------------------------------- Key: JGRP-692 URL: http://jira.jboss.com/jira/browse/JGRP-692 Project: JGroups Issue Type: Bug Affects Versions: 2.6.1 Environment: JBoss 4.2.2 on Linux 2.4.21-47.0.1.ELsmp i686 using Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode) Reporter: Matt Magoffin Assigned To: Bela Ban Attachments: jgroups-logs.tbz2 I'm having an issue with a 2-machine cluster using a TCP stack based on the tcp.xml from JGroups 2.6.1. On each machine I have 8 separate channels running, on different ports, with 4 groups in 2 JVM instances. After some period of time, one machine will fail to respond to a FD ping, and gets suspected. The machine that failed is not responding in time it seems from high CPU use, and many of the channels will fail FD around the same time. The channels are configured with auto-reconnect. My understanding was that the channel should "heal" itself and eventually re-form into a new view with the same 2 members in the cluster, which should apply to this situation because the machine that failed to respond eventually will respond. However, the group does not always seem to "heal" (sometimes it does, sometimes not). Once it stops healing, it never seems to ever do so again, and I get tons of NAKACK "message X not found in retransmission table" ERROR logs. The only way to get the channel working agin is to shut down the channel on both machines and then start them up again. I'm not using muxed channels... just normal channels. I have for now disabled shunning, and the channels seem to be able to re-connect after a shun situation occurs, but after time I'm still seeing something wrong with the channel in that the nodes are not able to send messages to each other successfully, and I have tons of 2008-02-21 21:01:53,572 WARN [org.jgroups.protocols.pbcast.NAKACK] 172.16.172.233:19182] discarded message from non-member 172.16.172.234:19182, my view is [172.16.172.233:19182|8] [172.16.172.233:19182] log entries, even while FD is receiving acks on that channel. this is a degradation problem for me while my servers are running, not just during deployment. After a while of running, the nodes get shunned/disconnected some how (often from a slow response from the other node) and then fail to ever merge back to form the original view of the 2 nodes again. Now even with shun set to false in both FD and pbcast.GMS on both nodes for all channels, eventually still the nodes reach the same state of never re-forming... and I have tons eventual 2008-02-21 21:28:24,857 WARN [org.jgroups.protocols.pbcast.NAKACK] 172.16.172.233:19182] discarded message from non-member 172.16.172.234:19182, my view is [172.16.172.233:19182|8] [172.16.172.233:19182] After a while in my application I'll force the channel to close wait a minute, and reopen, and sometimes this gets the channel working again, but doesn't always seem to. -- 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

16 years

4
24
0 / 0

[JBoss JIRA] Created: (JBAS-4808) MBean Service to bind DistributedTimeCachePolicy to JNDI under java:

by Anil Saldhana (JIRA)

MBean Service to bind DistributedTimeCachePolicy to JNDI under java: -------------------------------------------------------------------- Key: JBAS-4808 URL: http://jira.jboss.com/jira/browse/JBAS-4808 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.2.1.GA Reporter: Anil Saldhana Assigned To: Stefan Guilhen Fix For: JBossAS-4.2.3.GA We have many requests for clustering of the authentication cache in the JBoss security managers. We need a MBean service that can be configured (on demand by user) which will bind the DistributedTimedCachePolicy in JNDI under java: context -- 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

16 years

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-4739) CachedConnectionBankStressTestCase fails with instance per transaction BMP

by Adrian Brock (JIRA)

CachedConnectionBankStressTestCase fails with instance per transaction BMP -------------------------------------------------------------------------- Key: JBAS-4739 URL: http://jira.jboss.com/jira/browse/JBAS-4739 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Adrian Brock Fix For: JBossAS-5.0.0.GA The org.jboss.test.jca.test.CachedConnectionBankStressTestCase fails when using the default instance per transaction BMP of jBoss5. For now, I've reverted it to pessimistic and commit option A like jboss-4.2 but this test needs investigating to understand whether the test is broken or there is a problem in the BMP 1.1 under instance per transaction. -- 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

16 years

4
7
0 / 0

[JBoss JIRA] Created: (JBAS-3982) HASingletonController emits a cluster-wide JMX Notification after starting/stopping singleton

by Brian Stansberry (JIRA)

HASingletonController emits a cluster-wide JMX Notification after starting/stopping singleton --------------------------------------------------------------------------------------------- Key: JBAS-3982 URL: http://jira.jboss.com/jira/browse/JBAS-3982 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.1.CR1 Provide a mechanism for cluster-wide notifications when singleton services are started and stopped. In conjunction with this, a special BarrierController variant could be developed that monitors the cluster-wide notifications, allowing service dependencies on remote singletons. -- 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

16 years

5
4
0 / 0

[JBoss JIRA] Created: (JBAS-4654) JacORB throwing spurious UNKNOWN NoSuchMethodException

by Adrian Brock (JIRA)

JacORB throwing spurious UNKNOWN NoSuchMethodException ------------------------------------------------------ Key: JBAS-4654 URL: http://jira.jboss.com/jira/browse/JBAS-4654 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: IIOP service Affects Versions: JBossAS-4.2.1.GA Reporter: Adrian Brock Assigned To: Francisco Reverbel Fix For: JBossAS-5.0.0.GA When a RemoteException contains an exception that isn't mapped to a CorbaException, JacORB is throwing a spurious NoSuchMethodException. e.g. the following error thrown by the server in the testsuite: 2007-08-31 11:42:48,113 TRACE [org.jboss.proxy.ejb.EjbObjectCorbaServant.bank-iiop/Account] Exception in EJBObject invocation javax.management.MBeanException at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:184) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.proxy.ejb.EjbObjectCorbaServant._invoke(EjbObjectCorbaServant.java:287) at org.jacorb.poa.RequestProcessor.invokeOperation(Unknown Source) at org.jacorb.poa.RequestProcessor.process(Unknown Source) at org.jacorb.poa.RequestProcessor.run(Unknown Source) Caused by: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Internal error getting results for field member owner at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:365) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:209) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138) at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:532) at org.jboss.ejb.Container.invoke(Container.java:989) at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) ... 8 more Caused by: javax.ejb.EJBException: Internal error getting results for field member owner at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:498) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:432) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstractCMPFieldBridge.java:393) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:88) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:646) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:628) at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:406) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:252) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:243) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158) at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:280) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:76) at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:238) at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:105) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) ... 15 more Caused by: java.sql.SQLException: Got a org.omg.stub.javax.ejb._EJBObject_Stub[cl=org.jboss.mx.loading.UnifiedClassLoader3@ff45de{ url=vfsfile:/home/ejort/jboss-head/b Results in the following on the client: "CORBA UNKNOWN 0 No; nested exception is: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No" type="java.rmi.RemoteException">java.rmi.RemoteExcept ion: CORBA UNKNOWN 0 No; nested exception is: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No at com.sun.corba.se.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:282) at javax.rmi.CORBA.Util.mapSystemException(Util.java:67) at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:148) at org.jboss.test.bankiiop.interfaces._Account_Stub.getPrimaryKey(Unknown Source) at org.jboss.test.bankiiop.test.BankStressTestCase.testTeller(BankStressTestCase.java:88) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) Caused by: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No at org.jacorb.orb.SystemExceptionHelper.read(Unknown Source) at org.jacorb.orb.ReplyReceiver.getReply(Unknown Source) at org.jacorb.orb.Delegate.invoke_internal(Unknown Source) at org.jacorb.orb.Delegate.invoke(Unknown Source) at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457) at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:123) ... 23 more Caused by: java.lang.NoSuchMethodException: org.omg.CORBA.portable.UnknownException.<init>(java.lang.String, int, org.omg.CORBA.CompletionStatus) at java.lang.Class.getConstructor0(Class.java:2678) at java.lang.Class.getConstructor(Class.java:1629) ... 29 more The NoSuchMethodException is obviously not the cause. It comes from jacorb assuming that all Corba SystemExceptions have a constructor of a certain signature (something that is not true for UnknownException). -- 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

16 years

4
10
0 / 0

[JBoss JIRA] Created: (JBAS-4193) Validation requirement should come from the model factory

by Scott M Stark (JIRA)

Validation requirement should come from the model factory --------------------------------------------------------- Key: JBAS-4193 URL: http://jira.jboss.com/jira/browse/JBAS-4193 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services, XML services Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossAS-5.0.0.Beta2 A regression relative to how we parse application.xml without validation jbossas4.2 and earlier is showing up in placeholder application.xml deployments like: <!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd"> <application> <display-name>Resource Loading Ear</display-name> </application> This fails because this dtd requires at least one module as well: Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: vfsfil e:/C:/home/svn/JBossHead/jboss-head/testsuite/output/lib/unpacked/loadingresourc e2.ear/META-INF/application.xml@7,15 at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBPars er.java:173) at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java :180) at org.jboss.deployers.plugins.deployers.helpers.ObjectModelFactoryDeplo yer.parse(ObjectModelFactoryDeployer.java:83) ... 70 more Caused by: org.xml.sax.SAXException: The content of element type "application" i s incomplete, it must match "(icon?,display-name,description?,module+,security-r ole*)". @ vfsfile:/C:/home/svn/JBossHead/jboss-head/testsuite/output/lib/unpacke d/loadingresource2.ear/META-INF/application.xml[7,15] at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$MetaDataErrorHandler .error(SaxJBossXBParser.java:406) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(Unknown S To allow for similar behavior, we need to allow the ObjectModelFactory used by the deployer to indicate whether validation is needed. -- 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

16 years

4
13
0 / 0

[JBoss JIRA] Created: (JBAS-4335) Verify whether -Djava.net.preferIPv4Stack=true should be disabled on Linux/jdk6+

by Dimitris Andreadis (JIRA)

Verify whether -Djava.net.preferIPv4Stack=true should be disabled on Linux/jdk6+ -------------------------------------------------------------------------------- Key: JBAS-4335 URL: http://jira.jboss.com/jira/browse/JBAS-4335 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: System service Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-5.0.1.CR1 -- 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

16 years

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4197) Allow more control over hot deployment triggers

by Scott M Stark (JIRA)

Allow more control over hot deployment triggers ----------------------------------------------- Key: JBAS-4197 URL: http://jira.jboss.com/jira/browse/JBAS-4197 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Deployment services Reporter: Scott M Stark Assigned To: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta3 We need finer grained control over how hot deployment events are triggered. Two examples are: 1. Enable/disable the current hot deployment scanning based on time stamp for individual deployments 2. Allow a trigger hot deployment on next request mode. -- 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

16 years

3
3
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 2008