March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1001) Stopping standalone JBC (with -Dcom.sun.management.jmxremote) throws javax.management.InstanceNotFoundException: jboss.system:service=ServiceController

by Galder Zamarreno (JIRA)

Stopping standalone JBC (with -Dcom.sun.management.jmxremote) throws javax.management.InstanceNotFoundException: jboss.system:service=ServiceController ------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBCACHE-1001 URL: http://jira.jboss.com/jira/browse/JBCACHE-1001 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP2 Reporter: Galder Zamarreno Assigned To: Manik Surtani Priority: Minor Start a new instance of JBossCache -Dcom.sun.management.jmxremote. It registers jboss.cache:service=TreeCache-Cluster but when you stop the cache, it throws this: 18:53:58,531 WARN TreeCache:195 - Error in stop jboss.cache:service=TreeCache-Cluster javax.management.InstanceNotFoundException: jboss.system:service=ServiceController at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1010) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:804) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at org.jboss.system.ServiceMBeanSupport.stop(ServiceMBeanSupport.java:189) at org.hibernate.cache.OptimisticTreeCacheProvider.stop(OptimisticTreeCacheProvider.java:103) at org.hibernate.impl.SessionFactoryImpl.close(SessionFactoryImpl.java:800) at com.acme.hbcache.events.EventManager.main(Unknown Source) I haven't got time to look at this right now, making a note of it so that I can come back to it later. I need to try 2.0. -- 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, 2 months

2
6
0 / 0

[JBoss JIRA] Commented: (JBPM-395) SwimlaneInstance PooledActor assignment bug (not re-assignment issue)

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-395?page=comments#action_12355518 ] Ronald van Kuijk commented on JBPM-395: --------------------------------------- can you update the affected versions with the one you tested with... then I'll work on this next week > SwimlaneInstance PooledActor assignment bug (not re-assignment issue) > --------------------------------------------------------------------- > > Key: JBPM-395 > URL: http://jira.jboss.com/jira/browse/JBPM-395 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.0.1 > Environment: JDK 1.5, Postgresql, JBoss 4.0.2 > Reporter: Britt Miner > Assigned To: Tom Baeyens > > Initializing swimlaneInstances at process creation (or perhaps any time prior to creation of an associated task) will persist any configured actorId to the database, but configured PooledActors are not persisted. The AssignmentHandler functionality seems to work fine--the newly initialized swimlaneInstance has both actorId and pooledActors set correctly; however, the pooledActors will not be persisted. Allowing the swimlaneInstance to be initialized at creation of a related task does result in both actorId and pooledActors being properly persisted. > This issue is similar, though not identical, to http://jira.jboss.com/jira/browse/JBPM-375 and http://jira.jboss.com/jira/browse/JBPM-378 which are both related to swimlane assignment issues. > Why initialize swimlaneInstances at process creation? So that swimlane assignments can be made based on the initiator of the process (responsibilities broken down by regional groups, etc.), and so that those assignments are available for reporting/forcasting purposes. > This is the code fragment used to initialize the swimlanes: > ... > Map swimlanes = processDefinition.getTaskMgmtDefinition().getSwimlanes(); > Iterator itr = swimlanes.keySet().iterator(); > while(itr.hasNext()) { > Swimlane swimlane = (Swimlane)swimlanes.get(itr.next()); > SwimlaneInstance swi = pi.getTaskMgmtInstance().getInitializedSwimlaneInstance(new Execution > Context(pi.getRootToken()), swimlane); > //at this point, swi contains both actors and PooledActors that were specified in configuration and > populated with an appropriate AssignmentHandler > } > graphSession.saveProcessInstance(pi); > jbpmSession.commitTransaction(); > Thanks, > Britt -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-353) Interoperability between micro versions

by Bela Ban (JIRA)

Interoperability between micro versions --------------------------------------- Key: JGRP-353 URL: http://jira.jboss.com/jira/browse/JGRP-353 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5 Micro versions and service packs, like 2.4.1 AND 2.4.2 should work together in the same cluster. SOLUTION: add isCompatible(short) to Version, so we can actually accept packets from a 2.4.2 node in a 2.4.1 node. Needs to be configurable though -- 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, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-844) We need a optimistic locking version of TreeCacheProviderHook

by Galder Zamarreno (JIRA)

We need a optimistic locking version of TreeCacheProviderHook ------------------------------------------------------------- Key: EJBTHREE-844 URL: http://jira.jboss.com/jira/browse/EJBTHREE-844 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: EJB 3.0 RC9 - Patch 1, EJB 3.0 RC9 - FD Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Attachments: OptimisticTreeCacheProviderHook.java Currently, EJB3/Hibernate cannot take advantage of using a second level cache based in optimistic locking in a EJB3 environment. We only have a TreeCacheProviderHook CacheProvider for pessimistic locking which means that if a customer wants to set up optimistic locking, it's forced to use OptimisticTreeCacheProvider. However, this class was not designed for managed environments and ends up creating another cache, so you end up with two caches for the same job in the same instance which is wrong. I have created a OptimisticTreeCacheProviderHook which creates an org.hibernate.cache.OptimisticTreeCache based on the TreeCacheMBean instance looked up. Please find attached. This could be improved by creating a accessor method for TreeCacheProviderHook.cache, so that I can directly extend it rather than reimplementing CacheProvider. But, I have gone followed the CacheProvider implementation path so that I can quickly pass a patched jar containing this class only to the customer for them to try. -- 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, 2 months

4
12
0 / 0

[JBoss JIRA] Created: (JBFORUMS-189) BackToTop link on TopicView doesn't work

by Ryszard Kozmik (JIRA)

BackToTop link on TopicView doesn't work ---------------------------------------- Key: JBFORUMS-189 URL: http://jira.jboss.com/jira/browse/JBFORUMS-189 Project: JBoss Forums Issue Type: Bug Components: Forum View Layer Reporter: Ryszard Kozmik Assigned To: Ryszard Kozmik Priority: Trivial Fix For: 1.0.0 GA BackToTop link on TopicView doesn't work. -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4186) 19:20:01, 017 INFO [STDOUT] throw exception While calling EJB :java.lang.ClassCastException: $Proxy67

by periyasamy A (JIRA)

19:20:01,017 INFO [STDOUT] throw exception While calling EJB :java.lang.ClassCastException: $Proxy67 ----------------------------------------------------------------------------------------------------- Key: JBAS-4186 URL: http://jira.jboss.com/jira/browse/JBAS-4186 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Naming Affects Versions: JBossAS-4.2.0.CR1 Environment: jdk 1.5.0 ,JBOSSAS-4.2.0.CR1 Reporter: periyasamy A Assigned To: Scott M Stark Hi all I am using the following code Properties properties = new Properties(); InitialContext ic = new InitialContext(properties); HelloServiceH home = (HelloServiceH)ic.lookup("HelloService"); HelloServiceIF objRemoteIF = home.create(); out.println("objRemoteIF:::"+objRemoteIF); but i got the following error anyone help me.. 19:20:01,017 INFO [STDOUT] throw exception While calling EJB :java.lang.ClassCastException: $Proxy67 19:20:01,017 ERROR [STDERR] java.lang.ClassCastException: $Proxy67 19:20:01,017 ERROR [STDERR] at org.apache.jsp.testEJB_jsp._jspService(testEJB_jsp.java:86) 19:20:01,017 ERROR [STDERR] at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 19:20:01,017 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) 19:20:01,017 ERROR [STDERR] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:384) 19:20:01,017 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) 19:20:01,017 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) 19:20:01,017 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) 19:20:01,017 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) 19:20:01,017 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 19:20:01,017 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 19:20:01,017 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 19:20:01,017 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 19:20:01,017 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) 19:20:01,017 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) 19:20:01,017 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) 19:20:01,033 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) 19:20:01,033 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) 19:20:01,033 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) 19:20:01,033 ERROR [STDERR] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) 19:20:01,033 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 19:20:01,033 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216) 19:20:01,033 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) 19:20:01,033 ERROR [STDERR] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624) 19:20:01,033 ERROR [STDERR] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) 19:20:01,033 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595) -- 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, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-730) tidy up field names to be generic (not rule specific) and clean

by Michael Neale (JIRA)

tidy up field names to be generic (not rule specific) and clean --------------------------------------------------------------- Key: JBRULES-730 URL: http://jira.jboss.com/jira/browse/JBRULES-730 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-386) RequestCorrelator thread safety issue

by Bela Ban (JIRA)

RequestCorrelator thread safety issue ------------------------------------- Key: JGRP-386 URL: http://jira.jboss.com/jira/browse/JGRP-386 Project: JGroups Issue Type: Bug Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4.1 [Dave Oxley] We have had a deadlock issue with JGroups. The same issue affects 2.2.8 and 2.4.0. The call_stack in blocks.RequestCorrelator is a class variable and is set when a message is processed in util.Scheduler with deadlock_detection set to true. However if multiple threads call sendRequest in blocks.RequestCorrelator then they pick up the call_stack that may not be relevant to that request. This is most evident when concurrent_processing is also set to true as the call_stack grows permanently. The attached patch (against the 2.4 branch) makes call_stack a ThreadLocal and is set by the util.ReusableThread used to process the request. I've also changed the setConcurrentProcessing methods so that they work after the various objects have already been constructed. -- 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, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-638) versionNumber to be numerical (as I sort by it, so its important for version order integrity)

by Michael Neale (JIRA)

versionNumber to be numerical (as I sort by it, so its important for version order integrity) --------------------------------------------------------------------------------------------- Key: JBRULES-638 URL: http://jira.jboss.com/jira/browse/JBRULES-638 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-425) Incorrect state transfer in high contention scenarios

by Bela Ban (JIRA)

Incorrect state transfer in high contention scenarios ----------------------------------------------------- Key: JGRP-425 URL: http://jira.jboss.com/jira/browse/JGRP-425 Project: JGroups Issue Type: Bug Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 State transfer (with digests) works as follows: - State is requested from a provider - Provider (1) gets the digest from NAKACK (below) and then (2) the application state from the channel (above) - Between (1) and (2), some multicast message received can alter the state, as follows: - Multicast message M is received - At the same time, a state request is received - To handle the state request, we ask NAKACK for the digest - The digest contains M - Now - before M is passed up - the digest is returned to STATE_TRANSFER and we fetch the state *WITHOUT* M ! When the state requester gets the state&digest, it will reject a resent M because it thinks it is in its state (because it is in its digest), however M is not part of the state ! Other issue: - M is received after the digest has been retrieved by STATE_TRANSFER, but then M passes the state transfer and is received by the channel and applied to the state *before* the state request can fetch the state. Now M is *not* part of the digest, but it *is* part of the state ! SOLUTION: - When getting the digest, set a flag (in NAKACK) such that all subsequent multicast up-messages are blocked (or add them into a bounded FIFO list) - Fetch the state from the channel (the application) - Unblock NAKACK (send down an UNBLOCK event) - Return the state&digest to the state requester -- 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, 2 months

1
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 2007