[JBoss Cache Users] - Buddy replication - initial state transfer after node restar
by RichardTaylor
We are seeing an issue that I'd like to confirm with others before I write it up as a jira issue.
JBoss 5.1.0.
JBoss Cache 3.2.1
Buddy Replication (two nodes, separate machines)
We're currently using Total Replication for HTTP Session replication but we're increasing our node count (to three for now) and we'd like to change from total, to buddy replication. After a significant amount of testing, buddy replication works very well, except in one case for us.
The problem:
Two servers, A and B.
- Start server A
- Log into web app, creating an HTTP Session, S1, on server A
- Start server B. When B starts (this first time), the session S1 is perfectly replicated from A to B into B's "_BUDDY_BACKUP_" for server A
- Now restart server B, upon starting the second time, the session S1 from server A is only partially replicated to the "_BUDDY_BACKUP_" tree on server B. In particular it appears that (at least) the "DistributableSessionMetadata" was not replicated (should have a key of "2" in the replicated cache entry)
- Shut down server A, when the user hits server B, JBoss will try to unserialize and use S1, however it will fail because some data is not present in S1, such as the session metadata.
Example session S1 that successfully replicated after the initial startup of server B
--- Cache1 ---
| / {}
| /_BUDDY_BACKUP_ {}
| /192.168.71.60_7600 {}
| /JSESSION {}
| /ROOT_localhost {}
| /TYqa9j30si-QlGaVL9OVvQ__ {0=16, 1=1255098672537, org.jboss.seam.security.rememberMe=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}, 2=org.jboss.web.tomcat.service.session.distributedcache.spi.DistributableSessionMetadata@c1e908b, org.jboss.seam.CONVERSATION#1$org.jboss.seam.persistence.persistenceContexts=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}, org.jboss.seam.core.conversationEntries=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}, org.jboss.seam.international.localeSelector=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}, org.jboss.seam.CONVERSATION#1$org.jboss.seam.core.conversation=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}, org.jboss.seam.CONVERSATION#1$org.jboss.seam.international.statusMessages=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}, org.jboss.seam.security.identity=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}, javax.faces.request.charset=UTF-8, org.jboss.seam.CONVERSATION#1$org.jboss.seam.faces.redirect=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}, org.jboss.seam.security.credentials=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}, pier=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}, org.jboss.seam.web.session=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}}
| ------------
|
Example session S1 that failed to replicate fully to B after restart (notice the missing "2=..." among many other things)
--- Cache1 ---
| / {}
| /_BUDDY_BACKUP_ {}
| /192.168.71.60_7600 {}
| /JSESSION {}
| /ROOT_localhost {}
| /TYqa9j30si-QlGaVL9OVvQ__ {0=153, 1=1255097288878, foo=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}}
| ------------
What appears to be happening is that during the initial startup of the secondary server, server A properly calls the "AssignToBuddyGroupCommand" on server B, passing the initial state. However on subsequent restarts of server B, that command is never executed from server A.
I believe the problem is that server A fails to recognize the server B was shutdown, and the BuddyManager never removes him as a buddy (at least not in the timespan of server B restarting). When I look at the BuddyManager on server A in the jmx-console, I can see that his buddy group is never updated when server B restarts. I believe the data that does make it to B after a restart is just from the standard "replicate commands" that occur when something changes in the session S1 on server A.
For example, if server B was restarted at 6:50am, server A's buddy information in JMX looks like this (last updated 6:40am, which implies he never processed B leaving)
BuddyGroup: (dataOwner: 192.168.71.60:7600, groupName: 192.168.71.60_7600, buddies: [192.168.71.62:7600],lastModified: Fri Oct 09 06:40:27 PDT 2009)
In conjunction with that, in the log output from server A, I see this when server B is restarting:
2009-10-09 06:50:52,477 DEBUG [org.jboss.cache.buddyreplication.BuddyManager] Nothing has changed; new buddy list is identical to the old one.
|
Here are my relevant configurations (let me know if I missed sections):
jboss-web.xml
| <replication-config>
| <replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger>
| <replication-granularity>ATTRIBUTE</replication-granularity>
| </replication-config>
|
<bean name="StandardSessionCacheConfig" class="org.jboss.cache.config.Configuration">
|
| <!-- Provides batching functionality for caches that don't want to interact with regular JTA Transactions -->
| <property name="transactionManagerLookupClass">org.jboss.cache.transaction.BatchModeTransactionManagerLookup</property>
|
| <!-- Name of cluster. Needs to be the same for all members -->
| <property name="clusterName">${jboss.partition.name:DefaultPartition}-SessionCache</property>
| <!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)
| because we are using asynchronous replication. -->
| <property name="multiplexerStack">${jboss.default.jgroups.stack:tcp}</property>
| <property name="fetchInMemoryState">true</property>
|
| <property name="nodeLockingScheme">PESSIMISTIC</property>
| <property name="isolationLevel">REPEATABLE_READ</property>
| <property name="useLockStriping">false</property>
| <property name="cacheMode">REPL_ASYNC</property>
|
| <!-- Number of milliseconds to wait until all responses for a
| synchronous call have been received. Make this longer
| than lockAcquisitionTimeout.-->
| <property name="syncReplTimeout">17500</property>
| <!-- Max number of milliseconds to wait for a lock acquisition -->
| <property name="lockAcquisitionTimeout">15000</property>
| <!-- The max amount of time (in milliseconds) we wait until the
| state (ie. the contents of the cache) are retrieved from
| existing members at startup. -->
| <property name="stateRetrievalTimeout">60000</property>
|
| <!-- Not needed for a web session cache that doesn't use FIELD -->
| <property name="useRegionBasedMarshalling">false</property>
| <!-- Must match the value of "useRegionBasedMarshalling" -->
| <property name="inactiveOnStartup">false</property>
|
| <!-- Disable asynchronous RPC marshalling/sending -->
| <property name="serializationExecutorPoolSize">0</property>
| <!-- We have no asynchronous notification listeners -->
| <property name="listenerAsyncPoolSize">0</property>
|
| <property name="exposeManagementStatistics">true</property>
|
| <property name="buddyReplicationConfig">
| <bean class="org.jboss.cache.config.BuddyReplicationConfig">
|
| <!-- Just set to true to turn on buddy replication -->
| <property name="enabled">true</property>
|
| <!-- A way to specify a preferred replication group. We try
| and pick a buddy who shares the same pool name (falling
| back to other buddies if not available). -->
| <property name="buddyPoolName">default</property>
|
| <property name="buddyCommunicationTimeout">17500</property>
|
| <!-- Do not change these -->
| <property name="autoDataGravitation">false</property>
| <property name="dataGravitationRemoveOnFind">true</property>
| <property name="dataGravitationSearchBackupTrees">true</property>
|
| <property name="buddyLocatorConfig">
| <bean class="org.jboss.cache.buddyreplication.NextMemberBuddyLocatorConfig">
| <!-- The number of backup copies we maintain -->
| <property name="numBuddies">1</property>
| <!-- Means that each node will *try* to select a buddy on
| a different physical host. If not able to do so
| though, it will fall back to colocated nodes. -->
| <property name="ignoreColocatedBuddies">true</property>
| </bean>
| </property>
| </bean>
| </property>
| <property name="cacheLoaderConfig">
| <bean class="org.jboss.cache.config.CacheLoaderConfig">
| <!-- Do not change these -->
| <property name="passivation">true</property>
| <property name="shared">false</property>
|
| <property name="individualCacheLoaderConfigs">
| <list>
| <bean class="org.jboss.cache.loader.FileCacheLoaderConfig">
| <!-- Where passivated sessions are stored -->
| <property name="location">${jboss.server.data.dir}${/}session</property>
| <!-- Do not change these -->
| <property name="async">false</property>
| <property name="fetchPersistentState">true</property>
| <property name="purgeOnStartup">true</property>
| <property name="ignoreModifications">false</property>
| <property name="checkCharacterPortability">false</property>
| </bean>
| </list>
| </property>
| </bean>
| </property>
| </bean>
I have tried UDP / TCP, passivation / no passivation, and confirmed that things again work fine when using "total", not "buddy" replication.
Has anyone else seen this? Let me know if more information is needed.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259659#4259659
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259659
16 years, 8 months
[Security] - Re: Caller unauthorized on using a ejb3 statetlesssessionbea
by praenti
Ok, I have some new errors using a servlet, but this is also not working.
After I had a deeper look into the Web based authentication, I've seen that this is not usable for my usecase, because the service must be also usable over a Public-Key-Infrastructure. The Web based authentication does not support that.
What I've seen the JAASLoginModule is called ervery time I access an EJB. The strange thing is that the login works, but on accessing an EJB I get an Invalid user error and a message "Bad password for username=null" from JAAS, so it looks that the JAAS module forgets my username and password I logged in before successfully. I suppose, this is the problem of the previous error.
The question now is how I can solve that issue.
This is the complete error until the call of the EJB method:
| 16:12:42,099 INFO [SpiiderLoginModule] trying dn: uid=extern.michael.obster, ou=External,ou=People,ou=Access
| 16:12:42,099 INFO [SpiiderLoginModule] Logging into LDAP server, env={java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, dsJndiName=cancardviewerDS, rolesQuery=SELECT u.userid, r."role" FROM "security".application_user u, "security".application_role r, "security".user_role ur WHERE u.userid = ? AND u.userid = ur.user_id AND ur.role_id = r."role", java.naming.security.principal=uid=extern.michael.obster, ou=External,ou=People,ou=Access, jboss.security.security_domain=cancardDomain, java.naming.provider.url=ldap://ldaphost, java.naming.security.authentication=simple, java.naming.security.credentials=***, principal.dn.groups=ou=Corporate,ou=People,ou=Access:ou=External,ou=People,ou=Access}
| 16:12:42,130 INFO [SpiiderLoginModule] Logged into LDAP server, javax.naming.ldap.InitialLdapContext@9e50cd
| 16:12:42,130 INFO [SpiiderLoginModule] getRoleSets using rolesQuery: SELECT u.userid, r."role" FROM "security".application_user u, "security".application_role r, "security".user_role ur WHERE u.userid = ? AND u.userid = ur.user_id AND ur.role_id = r."role", gid: 12A44E672EA8C49B
| 16:12:42,146 INFO [LoginServlet] User extern.michael.obster: login successfull!
|
| 16:12:42,146 DEBUG [LoginServlet] init JAASInterceptor: loginDomain:cancardDomain clientLoginDomain:client-login
| 16:12:42,193 INFO [SpiiderLoginModule] LdapLoginModule, dsJndiName=cancardviewerDS
| 16:12:42,193 INFO [SpiiderLoginModule] rolesQuery=SELECT u.userid, r."role" FROM "security".application_user u, "security".application_role r, "security".user_role ur WHERE u.userid = ? AND u.userid = ur.user_id AND ur.role_id = r."role"
| 16:12:42,193 INFO [SpiiderLoginModule] defaultRole=RegularUser
| 16:12:42,193 DEBUG [SpiiderLoginModule] Bad password for username=null
| 16:12:42,193 ERROR [[LoginServlet]] Servlet.service() for servlet LoginServlet threw exception
| javax.ejb.EJBAccessException: Invalid User
| at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3Au
| thenticationInterceptorv2.java:165)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
| java:102)
| at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterce
| ptor.java:41)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
| java:102)
| at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContaine
| rShutdownInterceptor.java:67)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
| java:102)
| at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invo
| ke(CurrentInvocationInterceptor.java:67)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
| java:102)
| at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessCo
| ntainer.java:421)
| at org.jboss.ejb3.remoting.IsLocalInterceptor.invokeLocal(IsLocalInterce
| ptor.java:85)
| at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.
| java:72)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
| java:102)
| at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
| at $Proxy488.invoke(Unknown Source)
| at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandl
| erBase.invoke(SessionProxyInvocationHandlerBase.java:207)
| at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandl
| erBase.invoke(SessionProxyInvocationHandlerBase.java:164)
| at $Proxy561.updateUser(Unknown Source)
|
And the class LoginServlet.java:
| package vwg.audi.cancard.webservlet;
|
| import java.io.IOException;
|
| import javax.ejb.EJBAccessException;
| import javax.servlet.ServletException;
| import javax.servlet.http.HttpServlet;
| import javax.servlet.http.HttpServletRequest;
| import javax.servlet.http.HttpServletResponse;
|
| import org.apache.log4j.Logger;
| import org.jboss.web.tomcat.security.login.WebAuthentication;
|
| import com.arjuna.ats.arjuna.recovery.Service;
|
| public class LoginServlet extends HttpServlet
| {
| private Logger log = Logger.getLogger(LoginServlet.class);
|
| /**
| *
| */
| private static final long serialVersionUID = -5539909157863711284L;
|
| /**
| * Process the HTTP Get request
| */
| public void doGet(HttpServletRequest request, HttpServletResponse response)
| throws ServletException, IOException
| {
| serveRequest(request, response);
| }
|
| /**
| * Process the HTTP Post request
| */
| public void doPost(HttpServletRequest request, HttpServletResponse response)
| throws ServletException, IOException
| {
| serveRequest(request, response);
| } // doPost
|
| /**
| * In dieser Methode findet die eigentliche Verarbeitung des
| * HTTPServletRequests statt. Sie wird von den beiden public Methoden doPost
| * und doGet aufgerufen.
| */
| public void serveRequest(HttpServletRequest request,
| HttpServletResponse response) throws ServletException, IOException
| {
| String username = "extern.michael.obster";
| String pass = "mypassword";
| // login first
| try {
| login(username, pass);
| }
| catch (Exception e) {
| log.error("Fehler:", e);
| }
|
| String loginDomain = "cancardDomain";
| String clientLoginDomain = "client-login";
| if (log.isDebugEnabled()) {
| log.debug("init JAASInterceptor: loginDomain:" + loginDomain + " clientLoginDomain:" + clientLoginDomain);
| }
|
| // lets try to access ejb3
| try {
| ServiceLocator.getInstance().getUserService().updateUser();
| }
| catch (ServiceLocatorException e) {
| log.error("ServiceLocator error:", e);
| }
| }
|
| /**
| * Helper method for logging in
| * @param username
| * @param strPassword
| * @return
| * @throws Exception
| */
| private String login(String username, String strPassword) throws Exception {
| String loginDomain = "cancardDomain";
| String clientLoginDomain = "client-login";
|
| log.debug("LoginAction: loginDomain:" + loginDomain + " clientLoginDomain:" + clientLoginDomain);
| try {
| LoginFacade loginFacade = new LoginFacade(loginDomain, clientLoginDomain);
| loginFacade.login(username, strPassword);
| } catch (JAASLoginException jaasEx) {
| log.info("User " + username + ": login NOT successfull! " + jaasEx.getErrorKey(), jaasEx);
| return jaasEx.getErrorKey();
| } catch (EJBAccessException ejbEx) {
| //No permission for application
| log.warn(ejbEx);
| Exception ex = ejbEx.getCausedByException();
| log.info("User " + username + ": login NOT successfull! " + ejbEx.getMessage(), ejbEx);
|
| if (ex instanceof SecurityException) {
| return JAASConstants.NO_RIGHTS;
| } else {
| return JAASConstants.USER_NOT_AUTHENTICATED;
| }
| }
| catch (Exception ex) {
| log.info("User " + username + ": login NOT successfull! " + ex.getMessage(), ex);
| throw ex;
| // return JAASConstants.NO_RIGHTS;
| }
| log.info("User " + username + ": login successfull!");
| return JAASConstants.USER_IS_VALID;
| }
|
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259657#4259657
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259657
16 years, 8 months
[jBPM Users] - QuerySyntaxException in HistoryService
by jjp
=== Environment ==============================
- jBPM Version : 4.1
- Database : HSQLDB
- JDK : 1.6
- Container : JBoss 4.2.3
=== Process ==================================
Start - Task - End
=== API ===================================
HistoryProcessInstanceQuery historyProcessInstanceQuery= historyService.createHistoryProcessInstanceQuery();
|
| historyProcessInstanceQuery.processInstanceId( myProcessInstanceId );
|
| HistoryProcessInstance historyProcessInstance= historyProcessInstanceQuery.uniqueResult();
|
| HistoryDetailQuery query= historyService.createHistoryDetailQuery();
|
| query.activityInstanceId( historyProcessInstance.getProcessInstanceId() );
| query.orderDesc( "time" );
|
| List<HistoryDetail> list= query.list();
=== Stacktrace ==============================
org.hibernate.hql.ast.QuerySyntaxException: unexpected token: .1 near line 1, column 130 [select hd from org.jbpm.pvm.internal.history.model.HistoryDetailImpl as hd where hd.historyActivityInstance.dbid = StateWorkflow.1 ]
| at org.hibernate.hql.ast.QuerySyntaxException.convert(QuerySyntaxException.java:54)
| at org.hibernate.hql.ast.QuerySyntaxException.convert(QuerySyntaxException.java:47)
| at org.hibernate.hql.ast.ErrorCounter.throwQueryException(ErrorCounter.java:82)
| at org.hibernate.hql.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:281)
| at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:180)
| at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:134)
| at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:101)
| at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
| at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:94)
| at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:156)
| at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:135)
| at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1650)
| at org.jbpm.pvm.internal.query.AbstractQuery.execute(AbstractQuery.java:86)
| at org.jbpm.pvm.internal.query.AbstractQuery.execute(AbstractQuery.java:81)
| at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
| at org.jbpm.pvm.internal.tx.jta.JtaTransactionInterceptor.executeInExistingTx(JtaTransactionInterceptor.java:65)
| at org.jbpm.pvm.internal.tx.jta.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:51)
| at org.jbpm.pvm.internal.tx.jta.JtaRetryInterceptor.executeWithoutRetry(JtaRetryInterceptor.java:56)
| at org.jbpm.pvm.internal.tx.jta.JtaRetryInterceptor.execute(JtaRetryInterceptor.java:48)
| at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:46)
| at org.jbpm.pvm.internal.query.AbstractQuery.untypedList(AbstractQuery.java:62)
| at org.jbpm.pvm.internal.query.HistoryDetailQueryImpl.list(HistoryDetailQueryImpl.java:89)
| at com.feltengroup.session.WorkflowHandler.listComments(WorkflowHandler.java:299)
| 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:597)
| at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
| at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
| at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
| at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
| at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
| at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185)
| at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103)
| at com.feltengroup.session.WorkflowHandler_$$_javassist_seam_17.listComments(WorkflowHandler_$$_javassist_seam_17.java)
| 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:597)
| at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:335)
| at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:280)
| at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
| at org.jboss.el.parser.AstValue.getValue(AstValue.java:67)
| at org.jboss.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
| at com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:71)
| at com.sun.facelets.tag.jstl.core.ForEachHandler.apply(ForEachHandler.java:121)
| at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
| at com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314)
| at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169)
| at com.sun.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:64)
| at com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:131)
| at com.sun.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:337)
| at com.sun.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:307)
| at com.sun.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:68)
| at com.sun.facelets.tag.ui.DecorateHandler.apply(DecorateHandler.java:122)
| at com.sun.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:337)
| at com.sun.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:307)
| at com.sun.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:68)
| at com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314)
| at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169)
| at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
| at com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314)
| at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169)
| at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
| at com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:119)
| at com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
| at com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
| at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:248)
| at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:294)
| at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:273)
| at com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:140)
| at com.sun.facelets.tag.ui.DecorateHandler.apply(DecorateHandler.java:105)
| at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
| at com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
| at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
| at com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
| at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:248)
| at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:294)
| at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:273)
| at com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:140)
| at com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:113)
| at com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
| at com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
| at com.sun.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:95)
| at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:524)
| at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:567)
| at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:100)
| at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:176)
| at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:109)
| at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
| at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
| at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
| at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
| at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
| at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
| at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:42)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
| at java.lang.Thread.run(Thread.java:619)
=== Problem description =========================
It seems as if the HistoryDetailQuery.processInstanceId(java.lang.String processInstanceId) needs the database id instead of the ProcessInstance ID.
With this code fragment it works:
HistoryDetailQuery query= historyService.createHistoryDetailQuery();
|
| long dbid= ((HistoryProcessInstanceImpl)historyProcessInstance).getDbid();
|
| query.activityInstanceId( String.valueOf( String.valueOf( dbid ) ) );
| query.orderDesc( "time" );
|
| List<HistoryDetail> list= query.list();
|
Regards,
Joerg
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259652#4259652
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259652
16 years, 8 months
[Installation, Configuration & Deployment] - Re: Jboss 4.2.3 GA upgrade
by jaikiran
"rasa" wrote :
| Now i have changed my jar to application.ear
|
Why? :)
"rasa" wrote :
| Any idea ???
|
|
|
We have been telling you that the real problem is in the code of the application that is deployed. The code is not following the spec. The WARN message tell you the exact issues with the app. The code needs to be fixed.
anonymous wrote : But the same warning is there in 3.2.5 version of jboss
Again, we have told you that earlier versions of JBoss were lenient if the application violated the spec. In AS-4.x you can workaround this by setting the "StrictVerifier" to false in JBOSS_HOME/server/< servername>/deploy/ejb-deployer.xml:
<!-- Setting this to 'true' will cause all deployments
| to fail when the Verifier detected a problem with the contained
| Beans. If false, warnings/errors will be logged but the deployment
| will not fail.
| -->
| <attribute name="StrictVerifier">false</attribute>
|
But again this is just a workaround and you never know if this will be supported in later versions. The best way is to fix the application.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259650#4259650
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259650
16 years, 8 months
[Clustering] - Sending JMX notifications to all nodes in a cluster
by himanshuIg
Hi All,
I am using JBoss 4.2.3
I am trying to get JMX notifications working on a cluster. I have created two different classes
The class that sends a notification
import javax.management.*;
| import org.jboss.ha.jmx.HAServiceMBean;
| import org.jboss.ha.jmx.HAServiceMBeanSupport;
|
| public class LayoutMBean
| extends HAServiceMBeanSupport implements HAServiceMBean {
|
| private long sequenceNumber = 1;
|
| private Layout layout;
|
| public void setLayout(Layout layout) {
| this.layout = layout;
| }
|
| public Layout getLayout() {
| return this.layout;
| }
|
| public void syncLayouts() throws Exception {
| System.out.println("Sending Notification");
|
| Notification n =
| new Notification(
| Layout.TYPE,
| this,
| sequenceNumber++,
| System.currentTimeMillis(),
| "All Layouts have been synced");
| sendNotification(n);
| System.out.println("Notification Sent.......");
| }
|
| }
A NotificationListener
import javax.management.*;
|
| public class LayoutNotificationListener implements NotificationListener {
| public void handleNotification (Notification notification, Object handback) {
| System.out.println("Notifictaion Recieved...........");
| System.out.println(notification.getMessage());
| }
|
I have a spring configuration to define object of both the NotificationSender and NotificationListener(layoutMBean and layoutNotificationListener respectively)
On Application start-up, I add a listener by the following code
LayoutMBean layoutMBean = ctx.getBean("layoutMBean")
| LayoutNotifictionListener layoutNotifictionListener = ctx.getBean("layoutNotifictionListener")
| layoutMBean.addNotificationListener(layoutNotifictionListener, null, null)
|
When I deploy this application on the cluster, notifications are not being received by other nodes in the cluster, i.e., just the node that generated the notification receives it
I expected that the notification send by one of the nodes will be received by all other listeners in the cluster. What am I missing here?
Thanks in advance
~~Himanshu Seth~~
http://www.IntelliGrape.com
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259649#4259649
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259649
16 years, 8 months
[EJB 3.0 Users] - Re: Timer not available
by komet_1978
"jaikiran" wrote : In addition to what Dimitris asked for - is this EJB3 or EJB 2.x? And please post the entire exception stacktrace.
This is EJB 3. As you can see, the cancel method gets a TimerHandle which has been created before the restart. The id of the corresponding timer is 1255092103925.
I checked the timers table after the restart and there was no timer with this id. Although no timer had a timeout event and no timer has been canceled. And as already mentioned this exception never comes up without a restart.
Here is the main part of the exception stacktrace:
ENTER cancelTimer([id=1255092103925,target=[target=....jar,name=EETimerService,service=EJB3],first=12-Okt-2009 02:45:49.031,periode=0])
| 15:01:44,687 ERROR [EETimerService,19] javax.ejb.NoSuchObjectLocalException: Timer not available: [target=jboss.j2ee:ear=jabcee-server-SNAPSHOT.ear,jar=jabcee-server-ejb-SNAPSHOT.jar,name=EETimerService,service=EJB3]
| at ...EETimerService.cancelTimer(EETimerService.java:147)
| 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.invokeTarget(MethodInvocation.java:122)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
| at org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
| at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
| at ....EJBMethodDebugLogger.logMethod(EJBMethodDebugLogger.java:16)
| at sun.reflect.GeneratedMethodAccessor330.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
| at org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
| at org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:59)
| at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
| at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
| at sun.reflect.GeneratedMethodAccessor319.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
| at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_18733404.invoke(InvocationContextInterceptor_z_fillMethod_18733404.java)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
| at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_18733404.invoke(InvocationContextInterceptor_z_setup_18733404.java)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
| at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:261)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.session.SessionSpecContainer.invoke(SessionSpecContainer.java:176)
| at org.jboss.ejb3.session.SessionSpecContainer.invoke(SessionSpecContainer.java:216)
| at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
| at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
| at $Proxy457.cancelTimer(Unknown Source)
| ...
| Caused by: javax.ejb.NoSuchObjectLocalException: Timer not available: [target=...,name=EETimerService,service=EJB3]
| at org.jboss.ejb.txtimer.TimerHandleImpl.getTimer(TimerHandleImpl.java:203)
| at
| ...EETimerService.cancelTimer(EETimerService.java:143)
| ... 322 more
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259632#4259632
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259632
16 years, 8 months
[EJB 3.0 Users] - Re: Timer not available
by komet_1978
"dimitris(a)jboss.org" wrote : JBAS-4598 is an old report against 4.0.5 and many things changed in timers in 4.2.2+
|
| Thinking more about this, maybe the moment you ask for the timers, those are not created yet? i.e. the target container where the timers belong has not fully started for it's timers to be there. Can you verify this is not the case, i.e. check for the timers after the deployment is complete, or see if you can configure a dependency.
My EJB doesn't access the timers during the start up phase but always after the deplyoment is complete. So therefore there is no need to configure a dependency.
A look into the defaultDB.log (in jboss.home\server\default\data) reveales the following disadvantageous behaviour on start up, 3 timers are deleted from table timers and recreated, but get different ids:
DELETE FROM TIMERS WHERE TIMERID='1255087193422' AND TARGETID='[target=...,name=EETimerService,service=EJB3]'
| DELETE FROM TIMERS WHERE TIMERID='1255087193423' AND TARGETID='[target=...,name=EETimerService,service=EJB3]'
| DELETE FROM TIMERS WHERE TIMERID='1255087193424' AND TARGETID='[target=...,name=EETimerService,service=EJB3]'
| INSERT INTO TIMERS VALUES('1255092103922','[target=...,name=EETimerService,service=EJB3]','2009-10-12 01:18:23.437000000',0,NULL,'aced00057372002464652e6d6574616672616d652e6a6162632e65652e74696d65722e54696d6572496e666f50fe499a85be42e10200045a00096578656354696d65724c00066272616e63687400124c6a6176612f6c616e672f537472696e673b4c000970726f6365737349647400104c6a6176612f6c616e672f4c6f6e673b4c000573696249647400134c6a6176612f6c616e672f496e74656765723b78700074000774696d656f75747372000e6a6176612e6c616e672e4c6f6e673b8be490cc8f23df0200014a000576616c7565787200106a6176612e6c616e672e4e756d62657286ac951d0b94e08b02000078700000000000450002737200116a6176612e6c616e672e496e746567657212e2a0a4f781873802000149000576616c75657871007e000700000000')
| INSERT INTO TIMERS VALUES('1255092103923','[target=...]','2009-10-12 01:18:27.296000000',0,NULL,'aced00057372002464652e6d6574616672616d652e6a6162632e65652e74696d65722e54696d6572496e666f50fe499a85be42e10200045a00096578656354696d65724c00066272616e63687400124c6a6176612f6c616e672f537472696e673b4c000970726f6365737349647400104c6a6176612f6c616e672f4c6f6e673b4c000573696249647400134c6a6176612f6c616e672f496e74656765723b78700074000774696d656f75747372000e6a6176612e6c616e672e4c6f6e673b8be490cc8f23df0200014a000576616c7565787200106a6176612e6c616e672e4e756d62657286ac951d0b94e08b02000078700000000000450004737200116a6176612e6c616e672e496e746567657212e2a0a4f781873802000149000576616c75657871007e000700000000')
| INSERT INTO TIMERS VALUES('1255092103924','[target=...]','2009-10-12 01:18:32.656000000',0,NULL,'aced00057372002464652e6d6574616672616d652e6a6162632e65652e74696d65722e54696d6572496e666f50fe499a85be42e10200045a00096578656354696d65724c00066272616e63687400124c6a6176612f6c616e672f537472696e673b4c000970726f6365737349647400104c6a6176612f6c616e672f4c6f6e673b4c000573696249647400134c6a6176612f6c616e672f496e74656765723b78700074000774696d656f75747372000e6a6176612e6c616e672e4c6f6e673b8be490cc8f23df0200014a000576616c7565787200106a6176612e6c616e672e4e756d62657286ac951d0b94e08b02000078700000000000450006737200116a6176612e6c616e672e496e746567657212e2a0a4f781873802000149000576616c75657871007e000700000000')
|
This explaines why new timers can be accessed by handles when jboss keeps running, and can not after a restart.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259626#4259626
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259626
16 years, 8 months