[JBoss JIRA] Created: (JBAS-4283) JBoss application server appears to be matching on *ra.xml inside the .rar file when deploying
by Marie Rizzo (JIRA)
JBoss application server appears to be matching on *ra.xml inside the .rar file when deploying
----------------------------------------------------------------------------------------------
Key: JBAS-4283
URL: http://jira.jboss.com/jira/browse/JBAS-4283
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services
Affects Versions: JBossAS-4.0.5.GA
Environment: Windows XP, JDK 5, Mule 1.3.3/ 1.4 SNAPSHOT
Reporter: Marie Rizzo
Assigned To: Dimitris Andreadis
In attempting to deploy Mule on JBoss using the rar deployment, I noticed that although a proper ra-xml file exists for JBoss deployment inside the rar file, JBoss rejects anything that contains any other file which matches the pattern but does not pertain to JBoss deployment. In my case this occurs in the resource adapter jar file which has a file called oc4j-ra.xml file inside it. It seems to me that JBoss is matching on *ra.xml which may be the cause of the problem. Below is the relevant extract from the log file.
2007-03-30 16:16:48,734 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/Downloads/jboss-4.0.5.GAR/server/default/tmp/deploy/tmp37913mule-jca-1.4-SNAPSHOT.rar-contents/mule-module-jca-1.4-SNAPSHOT.jar
2007-03-30 16:16:48,734 DEBUG [org.jboss.deployment.JARDeployer] Found entry: 'META-INF/oc4j-ra.xml', matching: 'ra.xml', rejecting jar
2007-03-30 16:16:48,734 DEBUG [org.jboss.deployment.MainDeployer] No deployer found for url: file:/C:/Downloads/jboss-4.0.5.GAR/server/default/tmp/deploy/tmp37913mule-jca-1.4-SNAPSHOT.rar-contents/mule-module-jca-1.4-SNAPSHOT.jar
2007-03-30 16:16:48,734 DEBUG [org.jboss.deployment.MainDeployer] deployment waiting for deployer: file:/C:/Downloads/jboss-4.0.5.GAR/server/default/tmp/deploy/tmp37913mule-jca-1.4-SNAPSHOT.rar-contents/mule-module-jca-1.4-SNAPSHOT.jar
Consequently, a ClassLoaderNotFound exception is thrown because the resource adapter was never deployed.
11:57:17,203 WARN [ServiceController] Problem starting service jboss.jca:service=RARDeployment,name='mule-jca-1.3.3.rar'
java.lang.ClassNotFoundException: No ClassLoaders found for: org.mule.ra.MuleResourceAdapter
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:306)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:511)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.jboss.resource.deployment.ResourceAdapterFactory.createResourceAdapter(ResourceAdapterFactory.java:66)
at org.jboss.resource.deployment.RARDeployment.startService(RARDeployment.java:108)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
Please could you check up on this? If JBoss is indeed matching on the *ra.xml, it would be very restrictive with regards to naming conventions.
--
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
18 years, 7 months
[JBoss JIRA] Created: (JBXB-99) marshalDate appends timezone
by Thomas Diesler (JIRA)
marshalDate appends timezone
----------------------------
Key: JBXB-99
URL: http://jira.jboss.com/jira/browse/JBXB-99
Project: JBoss XML Binding (JBossXB)
Issue Type: Bug
Affects Versions: JBossXB-1.0.0.CR9
Reporter: Thomas Diesler
/**
* [-]yyyy-mm-dd
*
* @param value string date value
* @return equivalent date as an instance of java.util.Calendar.
*/
public static String marshalDate(Calendar value)
{
String result = String.valueOf(value.get(Calendar.YEAR));
result += '-';
result += marshalInt(value.get(Calendar.MONTH) + 1, 2);
result += '-';
result += marshalInt(value.get(Calendar.DAY_OF_MONTH), 2);
result += marshalTimeZone(value);
return result;
}
Given these CTS calendars
public final static GregorianCalendar GregorianCalendar_data[] = {
new GregorianCalendar(6,5,1,10,0,0),
new GregorianCalendar(9,10,25,1,30,0),
new GregorianCalendar(96,5,1,2,0,30),
new GregorianCalendar(99,10,25,3,15,15),
new GregorianCalendar(996,5,1,6,6,6),
new GregorianCalendar(999,10,25,7,7,7),
new GregorianCalendar(1996,5,1,8,8,8),
new GregorianCalendar(1999,10,25,9,9,9),
null
};
jbossxb generates a string that cannot be parsed on the server side
12:12:36,027 ERROR [SOAPFaultHelperJAXRPC] SOAP request exception
org.jboss.xb.binding.JBossXBValueFormatException: Date value does not follow the format '-'? yyyy '-' mm '-' dd: 6-06-01-05:00
at org.jboss.xb.binding.SimpleTypeBindings.parseDate(SimpleTypeBindings.java:2088)
at org.jboss.xb.binding.SimpleTypeBindings.unmarshalDate(SimpleTypeBindings.java:1701)
at org.jboss.ws.core.jaxrpc.binding.CalendarDeserializer.deserialize(CalendarDeserializer.java:61)
at org.jboss.ws.core.jaxrpc.binding.CalendarDeserializer.deserialize(CalendarDeserializer.java:47)
at org.jboss.ws.core.soap.XMLContent.unmarshallObjectContents(XMLContent.java:175)
--
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
18 years, 7 months
[JBoss JIRA] Created: (JBAS-3757) Support for PostgreSQL 8.2beta1
by Juergen Zimmermann (JIRA)
Support for PostgreSQL 8.2beta1
-------------------------------
Key: JBAS-3757
URL: http://jira.jboss.com/jira/browse/JBAS-3757
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Environment: PostgreSQL 8.2beta1, JDK 5.0_09, JDBC driver 8.2dev-503.jdbc3, JBoss 4.0.5cr1
Reporter: Juergen Zimmermann
Fix For: JBossAS-4.0.5.GA
Starting JBoss with PostgreSQL 8.2beta1 fails (no problem with 8.1.4).
Here is the log message:
09:11:48,067 INFO [WrapperDataSourceService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
09:11:48,778 WARN [ServiceController] Problem starting service jboss.mq:service=PersistenceManager
org.jboss.mq.SpyJMSException: Could not resolve uncommited transactions. Message recovery may not be accurate; - nested throwable: (org.postgresql.util.PSQLException: Eingabe/Ausgabe-Fehler {0} beim Senden an das Backend.)
at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:489)
at org.jboss.mq.pm.jdbc2.PersistenceManager.startService(PersistenceManager.java:1807)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.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: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.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at sun.reflect.GeneratedMethodAccessor10.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: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 $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
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.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
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:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy39.start(Unknown Source)
at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor18.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:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
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:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.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: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.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor10.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: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 $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
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:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:464)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.postgresql.util.PSQLException: Eingabe/Ausgabe-Fehler {0} beim Senden an das Backend.
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:216)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:354)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:308)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251)
at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:441)
... 111 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:256)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1164)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:190)
... 116 more
--
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
18 years, 7 months
[JBoss JIRA] Created: (JGRP-341) Extend FLUSH to fully support virtual synchrony
by Bela Ban (JIRA)
Extend FLUSH to fully support virtual synchrony
-----------------------------------------------
Key: JGRP-341
URL: http://jira.jboss.com/jira/browse/JGRP-341
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.5
Currently, FLUSH makes sure that all members 'flush' their pending messages and then stop sending new ones until the join or state transfer is over. However, FLUSH does *not* (unlike the old version) make sure that - on JOIN - all members have seen the same set of messages before installing a new view. Example: P sends M, but immediately after sending M crashes. If another member Q received M, but R didn't see M, then - with the current FLUSH - R will *not* see M.
We need to run a messages exchange phase, as part of FLUSH, which makes sure that all member have seen the same set of messages in the same view, before installing a new view. Whether to run this or not could be made configurable. If enabled, we could piggyback the message exchange on START_FLUSH/FLUSH_OK etc.
A simple (but costly) solution would be to simply multicast all messages received from other members before multicasting the FLUSH_OK. A better solution would be to exchange digests with highest sequence numbers seen for all members, and then only multicast the missing messages. This *might* require an additional phase 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
18 years, 7 months
[JBoss JIRA] Commented: (JBCACHE-97) ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock
by Bela Ban (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-97?page=comments#action_12358167 ]
Bela Ban commented on JBCACHE-97:
---------------------------------
See my question and the suggested answer at http://www.nabble.com/Upgrading-a-RL-to-WL-in-ReentrantReadWriteLock-tf27...
> ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock
> -------------------------------------------------------------------------------------------------
>
> Key: JBCACHE-97
> URL: http://jira.jboss.com/jira/browse/JBCACHE-97
> Project: JBoss Cache
> Issue Type: Bug
> Reporter: Bela Ban
> Assigned To: Jason T. Greene
> Fix For: 2.1.0.GA
>
>
> TxDeadlockUnitTestCase has 2 methods that show the following stack traces:
> testMoreThanOneUpgrader:
> Upgrader#0: get(/a/b/c)
> Upgrader#1: get(/a/b/c)
> main: locks:
> /a (read owners=[<null>:2, <null>:1])
> /b (read owners=[<null>:2, <null>:1])
> /c (read owners=[<null>:2, <null>:1])
> Upgrader#0: put(/a/b/c)
> Upgrader#1: put(/a/b/c)
> Upgrader#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:2); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock)
> Upgrader#0: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2]
> Write lock owner: null
> (caller=<null>:1)
> org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2]
> Write lock owner: null
> (caller=<null>:1)
> at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155)
> at org.jboss.cache.Node.acquireWriteLock(Node.java:448)
> at org.jboss.cache.Node.acquire(Node.java:417)
> at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199)
> at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35)
> at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998)
> at org.jboss.cache.TreeCache.put(TreeCache.java:1657)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyUpgrader._run(TxDeadlockUnitTestCase.java:346)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
> and
> testConcurrentUpgrade():
> MyThread#1: get(/a/b/c)
> MyThread#2: get(/a/b/c)
> MyThread#2: done, locks:
> /a (read owners=[<null>:2])
> /b (read owners=[<null>:2])
> /c (read owners=[<null>:2])
> MyThread#1: done, locks:
> /a (read owners=[<null>:2, <null>:1])
> /b (read owners=[<null>:2, <null>:1])
> /c (read owners=[<null>:2, <null>:1])
> MyThread#2: put(/a/b/c)
> MyThread#1: put(/a/b/c)
> MyThread#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:1); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock)
> MyThread#2: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1]
> Write lock owner: null
> (caller=<null>:2)
> org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1]
> Write lock owner: null
> (caller=<null>:2)
> at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155)
> at org.jboss.cache.Node.acquireWriteLock(Node.java:448)
> at org.jboss.cache.Node.acquire(Node.java:417)
> at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199)
> at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35)
> at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998)
> at org.jboss.cache.TreeCache.put(TreeCache.java:1657)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyThread._run(TxDeadlockUnitTestCase.java:317)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
--
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
18 years, 7 months
[JBoss JIRA] Created: (JBCACHE-876) Region marker in region-based marshalling message should be region fqn
by Brian Stansberry (JIRA)
Region marker in region-based marshalling message should be region fqn
----------------------------------------------------------------------
Key: JBCACHE-876
URL: http://jira.jboss.com/jira/browse/JBCACHE-876
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 1.4.1.GA
When region based marshalling is used, the replication message first has a serialized Fqn to identify the region, followed by a separately serialized method call. Receiver deserializes the identifier fqn and uses it to find the classloader to use to deserialize the main message.
Problem is the region identifier Fqn is the full Fqn of a node. This prevents the use in Fqns of classes that require the custom classloader to deserialize.
This can be mitigated by changing the marker Fqn to simply identify the Region, not some subnode. Now the restriction on use of custom classes is limited to the region Fqn; portions of Fqns below the region level can be of any serializable class.
This is needed to solve JBCLUSTER-150.
Downside is the node marshalling the message now needs to do a Region lookup to get the region Fqn.
Upsides are a reduced message size, since the shorter region fqn is marshalled, as well as a possibly faster region lookup time on the recipient nodes, since extraneous data can be ignored.
--
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
18 years, 7 months