[JBoss JIRA] Created: (JBESB-391) sometimes the parser is not found when doing a parameter reload.
by Kurt Stam (JIRA)
sometimes the parser is not found when doing a parameter reload.
----------------------------------------------------------------
Key: JBESB-391
URL: http://jira.jboss.com/jira/browse/JBESB-391
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Mark Little
Fix For: 4.0
When running the deployToSar task of the hello world quickstart on a running jboss, the timestamp on the jbossesb.xml changes and the parameters are reloaded. When this happens sometimes see the following stacktrace:
15:18:25,687 INFO [Server] JBoss (MX MicroKernel) [4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)] Started in 40s:875ms
15:18:47,296 ERROR [STDERR] Exception in thread "Thread-6"
15:18:47,296 ERROR [STDERR] org.apache.xerces.parsers.ObjectFactory$ConfigurationError: Provider org.apache.xerces.parsers.XIncludeAwareParserConfiguration could not be instantiated: java.lang.NullPointerException
15:18:47,296 ERROR [STDERR] at org.apache.xerces.parsers.ObjectFactory.newInstance(Unknown Source)
15:18:47,296 ERROR [STDERR] at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
15:18:47,296 ERROR [STDERR] at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
15:18:47,296 ERROR [STDERR] at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source)
15:18:47,296 ERROR [STDERR] at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source)
15:18:47,296 ERROR [STDERR] at org.apache.xerces.jaxp.DocumentBuilderImpl.<init>(Unknown Source)
15:18:47,296 ERROR [STDERR] at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source)
15:18:47,296 ERROR [STDERR] at org.jboss.soa.esb.listeners.config.XmlValidatorImpl.validate(XmlValidatorImpl.java:160)
15:18:47,296 ERROR [STDERR] at org.jboss.soa.esb.listeners.config.ConfigurationController.processConfiguration(ConfigurationController.java:176)
15:18:47,296 ERROR [STDERR] at org.jboss.soa.esb.listeners.config.ConfigurationController.run(ConfigurationController.java:113)
15:18:47,296 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595)
15:19:12,515 ERROR [STDERR] Exception in thread "Thread-15"
which is thrown from the line 160 in the XmlValidatorImpl:
parser = builderFactory.newDocumentBuilder();
The issue seems to fix it self, as it seems to be successful 5 seconds later.
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBAS-3546) Change log level on CachedConnectionManager.closeConnection() to warn
by Felipe Leme (JIRA)
Change log level on CachedConnectionManager.closeConnection() to warn
---------------------------------------------------------------------
Key: JBAS-3546
URL: http://jira.jboss.com/jira/browse/JBAS-3546
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.0.4.GA
Reporter: Felipe Leme
Assigned To: Weston Price
Priority: Trivial
The feature of the CachedConnectionManager automatically closing connections (and warning about the fact) is pretty useful; in fact, so useful that we would like to receive email notifications when it occurs. But, unfortunatelly, we are not receiving such notifications, as our log4j SMTP appender is set to the WARN threshold, while such warnings are being logged as info:
if (e != null)
log.info("Closing a connection for you. Please close them yourself: " + c, e);
else
log.info("Closing a connection for you. Please close them yourself: " + c);
m.invoke(c, new Object[]{});
}
catch (Throwable t)
{
log.info("Throwable trying to close a connection for you, please close it yourself", t);
}
}
catch (NoSuchMethodException nsme)
{
log.info("Could not find a close method on alleged connection objects. Please close your own connections.");
}
So, I'm proposing these loggings are changed from info() to warn() - I don't think such change will cause any 'logging havoc', as the messages are only logged when the CachedConnectionManager is set to debug them...
--
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
19 years, 3 months
[JBoss JIRA] Commented: (JBAS-3379) BigIntegerTimerIdGenerator may create dupplicate timer IDs after server crash
by Matt Kleiderman (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3379?page=comments#action_12351878 ]
Matt Kleiderman commented on JBAS-3379:
---------------------------------------
I'm getting failures to persist timers based on duplicate primary key entries even without a server shutdown. I'm running apps where a bean lives in a loop where it does something, and then schedules the next occurrence. The time between events is variable, so I can't schedule a recurring timer. But if I keep watching the database, I can see timers whose expiration date has past accumulate, and eventually a timer persistence failure. Is what I'm experiencing another manifestation of the same problem?
> BigIntegerTimerIdGenerator may create dupplicate timer IDs after server crash
> -----------------------------------------------------------------------------
>
> Key: JBAS-3379
> URL: http://jira.jboss.com/jira/browse/JBAS-3379
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB2, EJB3
> Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.4.CR2
> Reporter: Matthias Germann
> Assigned To: Scott M Stark
>
> The BigIntegerTimerIdGenerator may generate a already existing Timer ID after a server crash.
> The problem is that the Timer database may contain some Timers at server startup after a server crash (see JBAS-1091). The BigIntegerTimerIdGenerator does not know of these already existing timers. The first ID after a restart is always zero. Therefore, the BigIntegerTimerIdGenerator will create an already existing Timer ID as soon as the ID of a restored and not yet executed Timer is reached. This will lead to the following exception:
> 23:22:19,812 ERROR [TimerServiceImpl] Cannot create txtimer
> java.lang.IllegalStateException: Unable to persist timer
> at org.jboss.ejb.txtimer.DatabasePersistencePolicy.insertTimer(DatabasePersistencePolicy.java:126)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 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:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy22.insertTimer(Unknown Source)
> at org.jboss.ejb.txtimer.TimerServiceImpl.createTimer(TimerServiceImpl.java:256)
> at org.jboss.ejb.txtimer.TimerServiceImpl.createTimer(TimerServiceImpl.java:171)
> at ch.dvbern.bpm.test.ejb.service.scheduler.JbpmSchedulerBean.timeoutHandler(JbpmSchedulerBean.java:103)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
> at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
> at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:124)
> at org.jboss.ejb.txtimer.TimerImpl$TimerTaskImpl.run(TimerImpl.java:524)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> Caused by: java.sql.SQLException: Unique constraint violation: in statement [insert into TIMERS (TIMERID,TARGETID,INITIALDATE,TIMERINTERVAL,INSTANCEPK,INFO) values
> (?,?,?,?,?,?)]
> at org.hsqldb.jdbc.Util.throwError(Unknown Source)
> at org.hsqldb.jdbc.jdbcPreparedStatement.executeUpdate(Unknown Source)
> at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeUpdate(CachedPreparedStatement.java:95)
> at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251)
> at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.insertTimer(GeneralPurposeDatabasePersistencePlugin.java:186)
> at org.jboss.ejb.txtimer.DatabasePersistencePolicy.insertTimer(DatabasePersistencePolicy.java:122)
> ... 43 more
> IMHO, the BigIntegerTimerIdGenerator should be replaced by a GUID algorithm or read the maximum Timer ID from the Database at startup.
--
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
19 years, 3 months