[CDV-1572] ConcurrentHashMapKeySetWrapper does not implement equals() Created: 19/Apr/11  Updated: 27/Jul/12  Resolved: 20/Apr/11

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Kangsik Jung Assignee: Issue Review Board
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates CDV-1558 ConcurrentHashMapKeySetWrapper should... Closed
Severity: 2 Feature failure (but system usable), no workaround available
Fix In Branch:
trunk
Terracotta Target:
Unknown

 Description   

ConcurrentHashMapKeySetWrapper does not implement equals(), violating the contract of java.util.Set.

As a result, following codes will fail when instrumented with a dso bootjar.

Map map1 = ...
Map map2 = New ConcurrentHashMap(map1);

assertTrue(map2.equals(map1)); <-- OK

Set keySet1 = map1.ketSet();
Set keySet2 = map2.ketSet();

assertTrue(keySet2.equals(keySet1)); <-- FAIL!



 Comments   
Comment by Kangsik Jung [ 20/Apr/11 ]

Oops! It looks like this is a duplicate of CDV-1558.





[CDV-1568] ClusteredMap NPE and/or null values while iterating Created: 07/Apr/11  Updated: 02/Oct/12  Resolved: 22/Aug/12

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 3.5.0
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: J Robert Ray Assignee: Nishant Bangarwa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Terracotta Target:
Vicente
Terracotta Project:
Toolkit 2.0

 Description   

java.util.concurrent.ConcurrentHashMap specifies that entrySet() and values() return an iterator that is "weakly consistent" and are not expected to return null or throw NullPointerException. org.terracotta.collections.ClusteredMap and its implementors do not specify one way or the other what kind of behavior to be expected, so please excuse me if this bug report is reporting expected behavior.

When using the Toolkit via a connected client, requesting a ClusteredMap via getMap(), iterating over the map has two different failure modes in the face of concurrent modification.

Using entrySet().iterator(), iterator.next() will sometimes return null.
Using values().iterator(), iterator.next() will sometimes raise NullPointerException.

My test code creates a map and in 8 threads repeatedly calls put() and remove() with random integer keys from 0 to 100. The main thread attempts to iterate over the map and reports errors.

With entrySet().iterator(), the nulls are returned after a random number of calls to next():
{{entry null after 145
entry null after 8
entry null after 243
entry null after 180}}

With values.iterator(), the exception is similarly random:
{{NPE after 202
NPE after 26
NPE after 112
NPE after 86}}

Here is the stack for the NPE:
{{java.lang.NullPointerException
at java.util.AbstractMap$2$1.next(AbstractMap.java:360)
at com.terracotta.toolkit.util.AggregateMapIterator.next(AggregateMapIterator.java:49)
at com.imageworks.st.config.AppConfig.iterator_demo(AppConfig.scala:172)}}

As a workaround, using getAllEntriesSnapshot() survives the test with no nulls or NPEs.

Here's my test code (scala):
{{
def iterator_demo(t: org.terracotta.api.ClusteringToolkit) = {
import scala.actors.Actor

val m: org.terracotta.collections.ClusteredMap[Int, String] = t.getMap("iterator.test2")

val actors = for (i <- 1 to 8) yield {
val a = new Actor {
def act = {
val rand = new java.util.Random
while (true)

{ m.put(rand.nextInt(100), "1") m.remove(rand.nextInt(100)) }

}
}
a.start
a
}

var count = 0
while (true) {
try {
var i = m.values.iterator
while ((i ne null) && i.hasNext) {
val entry = i.next
if (entry eq null)

{ logger.debug("entry null after " + count) count = 0 i = null }

/*
else if (entry.getValue eq null)

{ logger.debug("entry.getValue null after " + count) count = 0 i = null }

*/
else

{ count += 1 }

}
}
catch

{ case e: NullPointerException => logger.debug("NPE after " + count, e) count = 0 }

}
}
}}



 Comments   
Comment by Tim Eck [ 08/Apr/11 ]

Thanks. That is pretty clearly a bug. The values() view is expressed via the entrySet() so I think there is probably only one bug here at least.

The problem is easy to reproduce as you've shown

Comment by J Robert Ray [ 14/Apr/11 ]

My workaround of using getAllEntriesSnapshot is having a problem, raising "java.lang.ClassCastException: com.tc.object.ObjectID cannot be cast to [B" on some calls to getValue() while iterating. This only happens shortly after bringing up a new L1 client. My real values are byte[].

Is this worthy of a separate bug report? I don't have a small standalone repro example for this one, unfortunately.

Comment by Nishant Bangarwa [ 22/Aug/12 ]

Already Fixed in Trunk.





[CDV-1539] pre-create methods are only called on the root object of an incoming object graph Created: 11/Jan/11  Updated: 24/Mar/11  Resolved: 17/Jan/11

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.5.0

Type: Bug Priority: 3 Minor
Reporter: Chris Dennis Assignee: Chris Dennis
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Terracotta Target:
Fremantle
Fixed In Revision: trunk:16974

 Description   

Pre-commit methods are intended to be called on all configured objects before they are added to the clustered heap. The current implementation only calls the pre-create method of the root object when a graph of objects is added. For example if I add an ArrayList of objects to the clustered heap only the pre-commit hook of the list would be called, and not the pre-commit method of any of the objects in the list.






[CDV-1529] getCanonicalName cause java.lang.IncompatibleClassChangeError Created: 23/Nov/10  Updated: 24/Mar/11  Resolved: 15/Dec/10

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 3.3.0
Fix Version/s: 3.5.0

Type: Bug Priority: 2 Major
Reporter: Nikolai Ivanov Assignee: Chris Dennis
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 1 Down/unusable, workaround available
Fix In Branch:
trunk
Terracotta Target:
Fremantle
Fixed In Revision: tim-api/trunk:16801 tc/trunk:16847
Bug Type:
Implementation Error

 Description   

Caused by: java.lang.IncompatibleClassChangeError: java.util.concurrent.locks.ReentrantReadWriteLock and java.util.concurrent.locks.ReentrantReadWriteLock$DsoLock disagree on InnerClasses attribute
at java.lang.Class.getDeclaringClass(Native Method) [na:1.6.0_07]
at java.lang.Class.getEnclosingClass(Class.java:1085) [na:1.6.0_07]
at java.lang.Class.getCanonicalName(Class.java:1169) [na:1.6.0_07]



 Comments   
Comment by Chris Dennis [ 09/Dec/10 ]

You're quite correct, the InnerClasses attributes were not being updated correctly during TC class instrumentation. I've just checked in a fix for this in the trunk of tim-api (http://svn.terracotta.org/fisheye/changelog/Terracotta/tim-api/trunk?cs=16801). I'm also going to code a separate fix that will go out with the next release of the TC core (3.5.0) - tim-api is not being released with this, so this has to be done independently. I'll close this JIRA when that is complete.

Comment by Chris Dennis [ 15/Dec/10 ]

I have now applied a temporary fix for this in trunk (this will go out with TC core 3.5.0). The test for this asserts that it is still running against the broken tim-api version, so that we remember to remove the temporary fix when a new version of tim-api is released.





[CDV-1518] Not synchronized access to WeakHashMap in JavaClassInfoRepository cause infinite loop Created: 30/Sep/10  Updated: 27/Jul/12  Resolved: 22/Oct/10

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 3.2.1
Fix Version/s: 3.4.0

Type: Bug Priority: 2 Major
Reporter: Nikolai Ivanov Assignee: Tim Eck
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Terracotta Target:
Magnum

 Description   

Infinite loop

"http-9081-17" daemon prio=10 tid=0x0000000059468800 nid=0x11d7 runnable [0x000000004c00d000]
java.lang.Thread.State: RUNNABLE
at java.util.WeakHashMap.getEntry(WeakHashMap.java:383)
at java.util.WeakHashMap.containsKey(WeakHashMap.java:369)
at com.tc.aspectwerkz.reflect.impl.java.JavaClassInfoRepository.hasClassInfo(JavaClassInfoRepository.java:108)
at com.tc.aspectwerkz.reflect.impl.java.JavaFieldInfo.getType(JavaFieldInfo.java:89)

  • locked <0x00002aaacb121218> (a com.tc.aspectwerkz.reflect.impl.java.JavaFieldInfo)
    at com.tc.aspectwerkz.expression.ExpressionVisitor.visit(ExpressionVisitor.java:488)
    at com.tc.aspectwerkz.expression.ast.ASTFieldPattern.jjtAccept(ASTFieldPattern.java:28)
    at com.tc.aspectwerkz.expression.ExpressionVisitor.visitAnnotatedNode(ExpressionVisitor.java:1016)
    at com.tc.aspectwerkz.expression.ExpressionVisitor.visit(ExpressionVisitor.java:171)
    at com.tc.aspectwerkz.expression.ast.ASTGet.jjtAccept(ASTGet.java:22)
    at com.tc.aspectwerkz.expression.ExpressionVisitor.visit(ExpressionVisitor.java:100)
    at com.tc.aspectwerkz.expression.ast.ASTExpression.jjtAccept(ASTExpression.java:22)
    at com.tc.aspectwerkz.expression.ExpressionVisitor.visit(ExpressionVisitor.java:88)
    at com.tc.aspectwerkz.expression.ExpressionVisitor.match(ExpressionVisitor.java:74)
    at com.tc.object.config.Root.matches(Root.java:94)
    at com.tc.object.config.StandardDSOClientConfigHelperImpl.findMatchingRootDefinition(StandardDSOClientConfigHelperImpl.java:1011)
    at com.tc.object.config.StandardDSOClientConfigHelperImpl.isRoot(StandardDSOClientConfigHelperImpl.java:999)
    at com.tc.object.bytecode.ManagerImpl.isRoot(ManagerImpl.java:532)
    at com.tc.object.bytecode.ManagerUtil.isRoot(ManagerUtil.java:475)
    at com.tc.util.FieldUtils.set(FieldUtils.java:159)
    at java.lang.reflect.Field.set(Field.java)
    at org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:102)
    at org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:352)
    at org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:232)
    at org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:3580)
    at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:152)
    at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:877)
    at org.hibernate.loader.Loader.doQuery(Loader.java:752)
    at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
    at org.hibernate.loader.Loader.doList(Loader.java:2232)
    at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2129)
    at org.hibernate.loader.Loader.list(Loader.java:2124)
    at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:118)
    at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1597)
    at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
    at org.hibernate.impl.CriteriaImpl.uniqueResult(CriteriaImpl.java:328)


 Comments   
Comment by Tim Eck [ 22/Oct/10 ]

added the necessary synchronization to avoid concurrent access/mutation





[CDV-1452] Inconsistent references to products and versions Created: 17/Feb/10  Updated: 12/Feb/13  Resolved: 24/Mar/10

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.2.1_2

Type: Bug Priority: 2 Major
Reporter: Ari Zilka Assignee: QA Team
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Terracotta Target:
Dubbo
Bug Found In Detail: seems to me like Hibernate error reporting detects mixed express / custom modes but the errors we output call them identity and stand-alone modes. Docs and errors do not align.

 Description   

See this thread. http://forums.terracotta.org/forums/posts/list/0/3136.page#17886

--Ari



 Comments   
Comment by Fiona OShea [ 24/Mar/10 ]

confirm that this is no longer an issue in 3.2.1





[CDV-1451] Give names to anonymous timers Created: 17/Feb/10  Updated: 12/Feb/13  Resolved: 06/May/10

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1, DSO:L2, Management (JMX)
Affects Version/s: None
Fix Version/s: 3.3.0

Type: Bug Priority: 2 Major
Reporter: Geert Bevin Assignee: Kalai Kannaiyan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Terracotta Target:
Taraval
Fixed In Revision: 15143

 Description   

There are a few anonymous timers in the DSO code base, they should be named:
TCGroupManagerImpl: private final Timer handshakeTimer = new Timer(true);
TCServerInfo.shutdown(): final Timer timer = new Timer();



 Comments   
Comment by Kalai Kannaiyan [ 05/Jul/10 ]

Fixed with rev 15143, Timer is named as "ServerConnectionManager Connect Monitor Timer"





[CDV-1436] Clients are not recieving operations enabled event properly Created: 08/Dec/09  Updated: 12/Feb/13  Resolved: 03/Jan/10

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1, DSO:L2
Affects Version/s: None
Fix Version/s: 3.2.1

Type: Bug Priority: 2 Major
Reporter: Raghvendra Singh Assignee: Kalai Kannaiyan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive client-server-logs.zip     Zip Archive postOfficeApp.zip    
Severity: 0 Down/unusable, no workaround available
Fix In Branch:
trunk, 3.2
Fixed In Revision: 14254
Bug Found In Detail: Clients don't get the operations enabled event in certein scenario and instead the cluster gets frozen

 Description   

Attached is the app which reproduces this problem

Steps to reproduce

1. Start an active and passive server.
2. Start 5 clients C0-C4 using the attached app on the same machine.
3. Kill active
4. Kill C4 and start a new client C5 while passive is taking over
5. When passive takes over all the clients should get operations enabled event and the connected clients should resume there work but instead the cluster gets frozen



 Comments   
Comment by Raghvendra Singh [ 08/Dec/09 ]

More discussion of this issue is at http://forums.terracotta.org/forums/posts/list/2775.page

Comment by Raghvendra Singh [ 08/Dec/09 ]

Seems like the servers are indeed firing the events but somehow clients are stuck here

"WorkerThread(client_coordination_stage, 0)" daemon prio=10 tid=0x00002aab32814400 nid=0x925 in Object.wait() [0x0000000042951000..0x0000000042951aa0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)

  • waiting on <0x00002aab0b51adc0> (a com.tc.object.ClusterMetaDataManagerImpl)
    at java.lang.Object.wait(Object.java:485)
    at com.tc.object.ClusterMetaDataManagerImpl.waitUntilRunning(ClusterMetaDataManagerImpl.java:297)
  • locked <0x00002aab0b51adc0> (a com.tc.object.ClusterMetaDataManagerImpl)
    at com.tc.object.ClusterMetaDataManagerImpl.retrieveMetaDataForDsoNode(ClusterMetaDataManagerImpl.java:139)
    at com.tc.cluster.DsoClusterImpl.retrieveMetaDataForDsoNode(DsoClusterImpl.java:247)
    at com.tc.cluster.DsoClusterImpl.fireNodeJoinedInternal(DsoClusterImpl.java:328)
    at com.tc.cluster.DsoClusterImpl.fireNodeJoined(DsoClusterImpl.java:322)
    at com.tc.object.handler.ClientCoordinationHandler.handleClusterMembershipMessage(ClientCoordinationHandler.java:54)
    at com.tc.object.handler.ClientCoordinationHandler.handleEvent(ClientCoordinationHandler.java:30)
    at com.tc.async.impl.StageImpl$WorkerThread.run(StageImpl.java:127)
Comment by Piero Positivo [ 08/Dec/09 ]

Here are the logs of the postOfficeApp. I have run many times on both MacOSX machines and Linux machines. They all reproduce the problem.
There are two TC servers called TC1 and TC2 in active-passive mode and 3 clients.
I have included the 4 client logs where the fourth is the client that attempts to join the cluster while the passive takes over after client 3 has been killed.

Comment by Raghvendra Singh [ 03/Jan/10 ]

fixed in trunk with r14254, merged in 3.2 with r14255





[CDV-1424] Races between transaction commits and cluster info api queries can cause confusing returns Created: 13/Nov/09  Updated: 23/Mar/11  Resolved: 16/Nov/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Chris Dennis Assignee: Chris Dennis
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Superset
Severity: 2 Feature failure (but system usable), no workaround available
Fix In Branch:
trunk
Fixed In Revision: 13974, 13975

 Description   

As the cluster info API currently relies entirely on the server for its data, races between committing transactions and object locality queries can lead to confusing results. This was seen in the ClusterMetaDataActiveActiveTest where the server was reporting that objects created in transactions that are yet to be committed are reported as not being local on the originating client.

This can be solved by merging the locality information reported by the client into the server results to ensure that new objects are reported correctly.



 Comments   
Comment by Chris Dennis [ 16/Nov/09 ]

Fixed in trunk and merged to 3.1 branch





[CDV-1411] Unable to interrupt client threads waiting on shared condition object Created: 16/Oct/09  Updated: 12/Feb/13  Resolved: 12/Nov/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 3.1.0, 3.1.1
Fix Version/s: 3.2.0

Type: Bug Priority: 3 Minor
Reporter: Joan Sala Assignee: Himadri Singh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File MySharedObject.java     XML File tc-config.xml     Java Source File ThreadInterruptTest.java    
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Fixed In Revision: 13962
Bug Type:
Implementation Error
Bug Found In Detail: Terracotta 3.1.1

 Description   

Calling Thread.interrupt() for a DSO-instrumented client thread that is blocked on a wait() call on a shared object does not cause the call to terminate until other clients sharing the same lock get disconnected. Ideally, the wait() call should terminate immediately with an InterruptedException as in non-instrumented Java.

Steps to reproduce:

  • DSO-start the attached program in two client processes. Both processes will start a thread and invoke wait() on a shared object.
  • Wait until "Done!" is displayed in both processes. This indicates that the corresponding threads have been interrupted.
  • The processes don't exit as one would expect. The corresponding threads are still blocked in the wait() call (see stack dump below) despite they have been interrupted.
  • Kill one of the client processes. The other receives now the InterruptedException and exits cleanly.

The stack dump of both threads when blocked is:
Object.wait(long) line: not available [native method]
MySharedObject(Object).wait() line: 485
ClientLock.waitForLock(ThreadID, int, Object) line: 676
ClientLock.wait(ThreadID, TimerSpec, Object, WaitListener) line: 396
ClientLockManagerImpl.wait(LockID, ThreadID, TimerSpec, Object, WaitListener) line: 477
StripedClientLockManagerImpl.wait(LockID, ThreadID, TimerSpec, Object, WaitListener) line: 171
ThreadLockManagerImpl.wait(LockID, TimerSpec, Object, WaitListener) line: 58
ClientTransactionManagerImpl.wait(String, TimerSpec, Object) line: 272
ManagerImpl.objectWait(Object) line: 459
ManagerUtil.objectWait(Object) line: 515
MySharedObject.__tc_wrapped_doWait() line: 5
MySharedObject.doWait() line: not available
ThreadInterruptTest$1.run() line: 18
Thread.run() line: 619

Surprisingly, the bug does not occur (i.e., the threads exit immediately) if main() is refactored to remove the superfluous use of an ArrayList to hold the (single) Thread object. I have not been able to figure out the reason for this.



 Comments   
Comment by Chris Dennis [ 12/Nov/09 ]

I've reproduced this in a system test (and have an associated fix for it) - both of which I will check-in soon. However I'm slightly concerned/confused about the reporters assertion that this worked when he used a straight reference to the thread instead of an ArrayList.

Comment by Himadri Singh [ 09/Dec/09 ]

Both clients now throw InterruptedException

Starting Terracotta client...
2009-12-10 11:21:46,609 INFO - Terracotta Enterprise 3.2.0-nightly, as of 20091207-161253 (Revision 5540-14152 by cruise@su10mo4 from 3.2)
2009-12-10 11:21:46,937 INFO - Configuration loaded from the file at 'c:\Terracotta\terracotta-3.2.0-nightly-ee-rev14152\CDV-1411\tc-config.xml'.
2009-12-10 11:21:47,078 INFO - Log file: 'c:\Terracotta\terracotta-3.2.0-nightly-ee-rev14152\CDV-1411\clients\tests\ThreadInterruptTest\logs\20091210112147046\terracotta-client.log'.
2009-12-10 11:21:47,281 INFO - Product key found at: C:\Terracotta\terracotta-3.2.0-nightly-ee-rev14152\product.key
2009-12-10 11:21:47,359 INFO -
---------------- Terracotta product key --------------
License type = Trial
License number = 1
Licensee = Terracotta Test
Product = FX
Max clients = 200
Capabilities = roots, sessions, TOC, server striping
------------------------------------------------------
2009-12-10 11:21:48,500 INFO - Connection successfully established to server at 10.0.7.27:9510
Waiting for other process...
Starting thread...
Interrupting thread...
Done!
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at com.tc.object.locks.LockStateNode$LockWaiter.park(LockStateNode.java:392)
at com.tc.object.locks.ClientLockImpl.waitOnLockWaiter(ClientLockImpl.java:237)
at com.tc.object.locks.ClientLockImpl.wait(ClientLockImpl.java:200)
at com.tc.object.locks.ClientLockImpl.wait(ClientLockImpl.java:165)
at com.tc.object.locks.ClientLockManagerImpl.wait(ClientLockManagerImpl.java:508)
at com.tc.object.locks.ClientLockManagerImpl.wait(ClientLockManagerImpl.java:203)
at com.tc.object.bytecode.ManagerImpl.wait(ManagerImpl.java:806)
at com.tc.object.bytecode.ManagerUtil.objectWait(ManagerUtil.java:508)
at MySharedObject.__tc_wrapped_doWait(MySharedObject.java:5)
at MySharedObject.doWait(MySharedObject.java)
at ThreadInterruptTest$1.run(ThreadInterruptTest.java:18)
at java.lang.Thread.run(Thread.java:619)





[CDV-1316] Lock eviction fails (as per spec) when lock is not pinned Created: 22/Jul/09  Updated: 14/Jan/10  Resolved: 16/Nov/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.2.0

Type: Bug Priority: 2 Major
Reporter: Chris Dennis Assignee: Chris Dennis
Resolution: Not a Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 3.1

 Description   

The current "spec" (the javadoc) for manual lock management defines the eviction of a unpinned lock as a no-op. For the ConcurrentDistributedMap this means that remove operations on previously non-local keys do not evict (and therefore recall) the associated key lock (as the lock will not be pinned as it is not local on entry to the method). The fix to change this behavior is a one-liner in the ClientLock class.



 Comments   
Comment by Fiona OShea [ 22/Jul/09 ]

What problem are we trying to solve?
Is it necessary for 3.1?

Comment by Chris Dennis [ 22/Jul/09 ]

As of the moment I have no proof that this is a bottleneck. I filed this simply to make sure that the "bug"s existence was recorded. If we find it to be a bottleneck then I will obviously post a comment here.

Comment by Fiona OShea [ 22/Jul/09 ]

thanks Chris. I'll move out to Santiago, if we find it is an issue we will move it back to Rivera

Comment by Chris Dennis [ 16/Nov/09 ]

I'm closing this since the evictLock method no longer exists in the new lock implementation, and as it was never shown to be a bottleneck in CSM (the only code that I know of that uses it) I'm reluctant to rock the 3.1 boat in order to fix it.





[CDV-1309] Lock recalls caused by calls to evictLock do not appear in statistics Created: 07/Jul/09  Updated: 15/Jul/10  Resolved: 21/May/10

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1, Statistics
Affects Version/s: None
Fix Version/s: 3.3.0

Type: Bug Priority: 2 Major
Reporter: Chris Dennis Assignee: Chris Dennis
Resolution: Not a Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Terracotta Target:
Taraval

 Description   

At the moment lock recalls that happen due to an explicit call to ManagerUtil.evictLock do not appear in the statistics - this should probably be fixed. Currently the only use of lock eviction is the CSM. You can kind of work round this in CSM by checking for flushing of the map entries (every flush will have an associated lock recall - depending on the locking scheme) - but that is far from ideal.



 Comments   
Comment by Chris Dennis [ 21/May/10 ]

The concept of an evicted lock no longer exists. Locks are now just unpinned and the lock is gc'ed in the same way as a lock that was never pinned.





[CDV-1282] ClientLock is relying on UnsupportedOperationException to detect that a map has to be instantiated Created: 29/May/09  Updated: 12/Feb/13  Resolved: 01/Jun/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.1.0

Type: Bug Priority: 2 Major
Reporter: Geert Bevin Assignee: Kalai Kannaiyan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to CDV-1218 Reduce memory footprint of ClientLock... Closed
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Fixed In Revision: 12821
Bug Type:
Implementation Error
Bug Found In Detail: 12804

 Description   

Per forum post:
http://forums.terracotta.org/forums/posts/list/2185.page#12972

The pendingLockRequests and waitLocksByRequesterID maps are initialized as empty maps and rely on UnsupportedOperationException exceptions to instantiate real maps. This seems indeed needlessly expensive and can be done through pre-conditions.



 Comments   
Comment by Geert Bevin [ 29/May/09 ]

This change is what caused this. I think this could be done through some flags instead and a bit more code instead of throwing a lot of needless exceptions.

Comment by Steve Harris [ 29/May/09 ]

what change?

Comment by Chris Dennis [ 29/May/09 ]

The change that caused it was 12167 - I made the change to reduce memory usage of ClientLock instances for simple lock usage. I have a fix for this on my local machine (using a ref check against a statically held empty map like Geert and Tim suggested via email). Will checkin after we reopen things after JavaOne code freeze.

Comment by Chris Dennis [ 01/Jun/09 ]

Switch to a singleton map/set and use a reference check for lazy instantiation.

Comment by Kalai Kannaiyan [ 12/Aug/09 ]

Verified the fix on trunk with svn rev12821.





[CDV-1276] L1 logging should not call toString() on clustered objects Created: 26/May/09  Updated: 20/Aug/09  Resolved: 27/May/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 3.0.1
Fix Version/s: 3.1.0

Type: Bug Priority: 2 Major
Reporter: Walter Harley Assignee: Chris Dennis
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to CDV-1176 Circular reference in logged object c... Resolved
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 3.0
Fixed In Revision: 12796, 12798

 Description   

ManagerImpl.isDsoMonitorEntered() logs a problem with an object, but it tries to print the object (implicitly calling toString()). For many objects this will cause an unbounded stack dive, as trying to get the object's state triggers the same method. Getting the object's state can also trigger Hibernate to resolve lazy-initialized collections, thus adding to the cluster at an inappropriate time.

It would be better to just print the object's class and perhaps its identityHashCode().

I don't see any other examples in ManagerImpl, but it looks like there are some in ClientObjectManagerImpl too.



 Comments   
Comment by Chris Dennis [ 27/May/09 ]

Changed the method in ManagerImpl to only log the class and identity hashcode of the object to prevent any side-effects of calling toString. Also changed the contents of two assertions in ClientObjectManagerImpl (not so crucial). I'm going to resolve this for now, but if anyone knows of any others we can either reopen this JIRA or file a fresh one.

Comment by Kalai Kannaiyan [ 12/Aug/09 ]

Verified the fix made on trunk and 3.0 with svn rev12796 and 12798





[CDV-1272] postCreate methods not invoked on subclasses Created: 22/May/09  Updated: 20/Aug/09  Resolved: 22/May/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.1.0

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Tim Eck
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

Class A has a postCreate method
Class B extends A.

If you share an instance of class B the postCreate method will not be invoked. When we look for postCreate methods we only take the top level type name into consideration.

This is currently causing the evictor thread to not be started in nodes which initially share instances of ClusteredDistributedMap (from tim-map-evictor).



 Comments   
Comment by Kalai Kannaiyan [ 12/Aug/09 ]

Verified the changes on trunk with svn rev 12764





[CDV-1262] ThreadIDMapJdk15 uses the non-final getId method in Thread as the Thread identifier Created: 07/May/09  Updated: 20/Aug/09  Resolved: 21/May/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.1.0

Type: Bug Priority: 2 Major
Reporter: Chris Dennis Assignee: Walter Harley
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones CDV-1260 Locking error in sub-class of Thread ... Closed
Related
Severity: 1 Down/unusable, workaround available
Fix In Branch:
trunk
Fixed In Revision: 12756

 Description   

We key global thread id objects in each L1 against the return of getId for associated local thread object. getId is not a final method. Thread subclasses are free to override and return whatever they like (including a static value). I suspect (although it is not yet confirmed) that this has already been exposed by at least one forum user. In addition this map is not ever scrubbed of dead threads, and even in the absence of bizarre subclasses the JVM can recycle the ids of dead threads.

Note that we assert this mapping to be unique for any given thread - so breaking subclasses or JVM id reuse will trigger an assertion error.

Is there some reason we are not using a WeakHashMap with the threads themselves as the keys? This would fix the id bug and also be self cleaning.



 Comments   
Comment by Chris Dennis [ 08/May/09 ]

Confirmed case of a subclass causing this @ http://forums.terracotta.org/forums/posts/list/0/2116.page

Comment by Chris Dennis [ 08/May/09 ]

Sun are aware of the non-final method being a bug but are not going to change it to avoid breaking backwards compatibility.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6346938

Comment by Alex Miller [ 08/May/09 ]

For now, target Rivera. Depending on scope of fix, might want to roll back to 3.0 branch for next 3.0.x.

Comment by Walter Harley [ 18/May/09 ]

Our main use of thread IDs, in lock management, uses TC ThreadIds, which are associated to a VM thread via a ThreadLocal (in ThreadIdManagerImpl). Thus, we are using actual Thread objects, not the getId(), for most of what we do.

The ThreadIdMap seems to only be used for the sake of getting thread dumps; at least that's the only caller of ThreadIdMap.getTCThreadID() that I can find. Unfortunately in that case the VM thread ID that we're looking up on is coming from the ThreadMXBean, which does not provide a way to get actual threads, only thread IDs. This is a Java class, not one of ours.

I'm inclined to say that the assert in ThreadIDMapJdk15.addTCThreadID() is incorrect, that is, that we should silently tolerate duplicated ids. If someone overrides getId() and fails to honor the contract in its javadoc ("The thread ID is unique during its lifetime. When a thread is terminated, this thread ID may be reused"), they'll get bogus thread dumps, but not broken locking. If they are simply recycling thread IDs, then no harm done.

But the map can grow forever. We could make the map be <Thread, ThreadId> if in ThreadDumpUtilJdk15 we used Thread.enumerate() instead of ThreadMXBean.getAllThreadIds(). I can't tell from the docs whether these are identical: enumerate() returns only threads in the current thread's ThreadGroup, but getAllThreadIds() looks like it is less restrictive.

Another idea would be to create a WeakReference to the Thread at the same time that we put its ID into the map. Then when we dequeue the references we can remove the corresponding IDs from the map. This has two problems: first, where do we check the queue? On a separate cleanup thread, or inside all the methods that access the map, or ... ? Second, it is not robust against a badly overridden getThreadId() method that fails to produce unique thread IDs: collisions will cause live threads to be removed from the map.

Comment by Walter Harley [ 18/May/09 ]

Looks like it is possible to walk up the thread group tree with ThreadGroup.getParent(), to find the root thread group; calling enumerate() on that should give the same result as ThreadMXBean.getAllThreadIds(). I'll explore this approach.

Comment by Walter Harley [ 20/May/09 ]

The ThreadMXBean (the VM's way of reporting thread info, that we use to obtain locks, monitors, and thread state, as well as the stack trace) has a getThreadInfo(id) method; but if you pass in the id of a Thread that has overridden getId(), it returns null - instead, if you pass in the original, non-overridden id, you get the correct thread info. It seems that the VM itself does not cope correctly with overriding Thread.getId().

I think we should prevent the ThreadIdMap from growing without bound, and we should gracefully handle (ie, no crash, no assertion) the case where thread ID has been overridden, but I do not think it is worth further dev effort to try to correctly report full thread dump info in that case. Instead, we should just doc the gotcha.

Comment by Walter Harley [ 21/May/09 ]

Fixed in trunk with 12756. We could merge this into 3.0.x; it does change the ThreadIDMap interface but that is not in a -api project.

We certainly want to advise users to NOT override Thread.getId(), as doing so exposes JVM inconsistencies (specifically in the ThreadMXBean). If they do so anyway, our locking will be unaffected; our thread dumps may not be able to get full information about thread state, but they will still contain complete stack traces and information about TC locks.

Comment by Walter Harley [ 21/May/09 ]

Created DOC-614 for the doc issue.

Comment by Kalai Kannaiyan [ 12/Aug/09 ]

Verified the changes made on trunk with svn rev 12755, 12756 and 12758.





[CDV-1241] NPE in aspectwerkz on AsmFieldInfo.getAnnotations() Created: 07/Apr/09  Updated: 12/Feb/13  Resolved: 13/Apr/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 3.0.0
Fix Version/s: 3.0.1

Type: Bug Priority: 1 Critical
Reporter: Alex Miller Assignee: Himadri Singh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 3.0

 Description   

All from Tim:

Jetty-6.1.11 doesn't look like it is friendly with tim-jetty-1.2.0 (the version we released with TC 3.0) so I stepped up to 6.1.15 of jetty to test examinator.

Unfortunately it looks like something else is busted....I think it has something to do with annotation matching (as opposed to anything with tim-jetty). Examinator with tomcat seems fine tho

Digging into it I feel this is yet one more bug in Aspectwerkz. It's a bit involved and one of our earlier fixes to cut down the number of "AW::WARNING" messages is partially to blame.

I don't think it would be hard to apply another "fix" here, though it would be change in the core TC code. We could maybe workaround it in examinator if sl4j was getting into the examinator.war, but I can't say until I try it. Adding more libraries in jetty's classpath might work too.

[WARNING] [cargo1] java.lang.NullPointerException
[WARNING] [cargo1] at com.tc.aspectwerkz.reflect.impl.asm.AsmFieldInfo.getAnnotations(AsmFieldInfo.java:96)
[WARNING] [cargo1] at com.tc.aspectwerkz.expression.ExpressionVisitor.visitAttributes(ExpressionVisitor.java:815)
[WARNING] [cargo1] at com.tc.aspectwerkz.expression.ExpressionVisitor.visitAnnotatedNode(ExpressionVisitor.java:1021)
[WARNING] [cargo1] at com.tc.aspectwerkz.expression.ExpressionVisitor.visit(ExpressionVisitor.java:171)
[WARNING] [cargo1] at com.tc.aspectwerkz.expression.ast.ASTGet.jjtAccept(ASTGet.java:22)
[WARNING] [cargo1] at com.tc.aspectwerkz.expression.ExpressionVisitor.visit(ExpressionVisitor.java:100)
[WARNING] [cargo1] at com.tc.aspectwerkz.expression.ast.ASTExpression.jjtAccept(ASTExpression.java:22)
[WARNING] [cargo1] at com.tc.aspectwerkz.expression.ExpressionVisitor.visit(ExpressionVisitor.java:88)
[WARNING] [cargo1] at com.tc.aspectwerkz.expression.ExpressionVisitor.match(ExpressionVisitor.java:74)
[WARNING] [cargo1] at com.tc.object.config.Root.matches(Root.java:94)
[WARNING] [cargo1] at com.tc.object.config.StandardDSOClientConfigHelperImpl.findMatchingRootDefinition(StandardDSOClientConfigHelperImpl.java:980)
[WARNING] [cargo1] at com.tc.object.config.StandardDSOClientConfigHelperImpl.classContainsAnyRoots(StandardDSOClientConfigHelperImpl.java:988)
[WARNING] [cargo1] at com.tc.object.config.StandardDSOClientConfigHelperImpl.shouldBeAdapted(StandardDSOClientConfigHelperImpl.java:1218)
[WARNING] [cargo1] at com.tc.object.bytecode.hook.impl.DefaultWeavingStrategy.transformInternal(DefaultWeavingStrategy.java:164)
[WARNING] [cargo1] at com.tc.object.bytecode.hook.impl.DefaultWeavingStrategy.transform(DefaultWeavingStrategy.java:124)
[WARNING] [cargo1] at com.tc.object.bytecode.hook.impl.DSOContextImpl.preProcess(DSOContextImpl.java:168)
[WARNING] [cargo1] at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.defineClass0Pre(ClassProcessorHelper.java:665)
[WARNING] [cargo1] at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
[WARNING] [cargo1] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
[WARNING] [cargo1] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
[WARNING] [cargo1] at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
[WARNING] [cargo1] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
[WARNING] [cargo1] at java.security.AccessController.doPrivileged(Native Method)
[WARNING] [cargo1] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
[WARNING] [cargo1] at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:392)
[WARNING] [cargo1] at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:363)
[WARNING] [cargo1] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
[WARNING] [cargo1] at org.slf4j.impl.StaticLoggerBinder.<init>(StaticLoggerBinder.java:68)
[WARNING] [cargo1] at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:57)
[WARNING] [cargo1] at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:60)
[WARNING] [cargo1] at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155)
[WARNING] [cargo1] at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:131)
[WARNING] [cargo1] at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
[WARNING] [cargo1] at org.springframework.web.context.ContextLoader.<clinit>(ContextLoader.java:146)
[WARNING] [cargo1] at org.springframework.web.context.ContextLoaderListener.createContextLoader(ContextLoaderListener.java:53)
[WARNING] [cargo1] at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:44)
[WARNING] [cargo1] at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
[WARNING] [cargo1] at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
[WARNING] [cargo1] at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239)
[WARNING] [cargo1] at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
[WARNING] [cargo1] at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466)
[WARNING] [cargo1] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[WARNING] [cargo1] at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
[WARNING] [cargo1] at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
[WARNING] [cargo1] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[WARNING] [cargo1] at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
[WARNING] [cargo1] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[WARNING] [cargo1] at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
[WARNING] [cargo1] at org.mortbay.jetty.Server.doStart(Server.java:222)
[WARNING] [cargo1] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[WARNING] [cargo1] at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
[WARNING] [cargo1] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[WARNING] [cargo1] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[WARNING] [cargo1] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[WARNING] [cargo1] at java.lang.reflect.Method.invoke(Method.java:597)
[WARNING] [cargo1] at org.mortbay.start.Main.invokeMain(Main.java:194)
[WARNING] [cargo1] at org.mortbay.start.Main.start(Main.java:523)
[WARNING] [cargo1] at org.mortbay.start.Main.main(Main.java:119)



 Comments   
Comment by Fiona OShea [ 08/Apr/09 ]

happens if you use Jetty > 6.1.11 and slf4j, workaround = add the jar to jetty libs

Comment by Himadri Singh [ 21/May/09 ]

1. Checked out tc-3.0 branch of examinator
2. Used 1.3.0 version of tc-maven-plugin which uses terracotta 3.0.0
3. Modified version of tim-jetty in tc-config.xml to tim-jetty-6.1-1.2.0
4. tc-3.0 branch uses jetty 6.1.15
5. Ran mvn clean tc:run
6. Received the exception

[WARNING] [cargo0] 2009-05-21 22:27:13.135::WARN: Nested in java.lang.ExceptionInInitializerError:
[WARNING] [cargo0] java.lang.NullPointerException
[WARNING] [cargo0] at com.tc.aspectwerkz.reflect.impl.asm.AsmFieldInfo.getAnnotations(AsmFieldInfo.java:96)
[WARNING] [cargo0] at com.tc.aspectwerkz.expression.ExpressionVisitor.visitAttributes(ExpressionVisitor.java:815)
[WARNING] [cargo0] at com.tc.aspectwerkz.expression.ExpressionVisitor.visitAnnotatedNode(ExpressionVisitor.java:1021)
[WARNING] [cargo0] at com.tc.aspectwerkz.expression.ExpressionVisitor.visit(ExpressionVisitor.java:171)
[WARNING] [cargo0] at com.tc.aspectwerkz.expression.ast.ASTGet.jjtAccept(ASTGet.java:22)
[WARNING] [cargo0] at com.tc.aspectwerkz.expression.ExpressionVisitor.visit(ExpressionVisitor.java:100)
[WARNING] [cargo0] at com.tc.aspectwerkz.expression.ast.ASTExpression.jjtAccept(ASTExpression.java:22)
[WARNING] [cargo0] at com.tc.aspectwerkz.expression.ExpressionVisitor.visit(ExpressionVisitor.java:88)
[WARNING] [cargo0] at com.tc.aspectwerkz.expression.ExpressionVisitor.match(ExpressionVisitor.java:74)
[WARNING] [cargo0] at com.tc.object.config.Root.matches(Root.java:94)
[WARNING] [cargo0] at com.tc.object.config.StandardDSOClientConfigHelperImpl.findMatchingRootDefinition(StandardDSOClientConfigHelperImpl.java:980)
[WARNING] [cargo0] at com.tc.object.config.StandardDSOClientConfigHelperImpl.classContainsAnyRoots(StandardDSOClientConfigHelperImpl.java:988)
[WARNING] [cargo0] at com.tc.object.config.StandardDSOClientConfigHelperImpl.shouldBeAdapted(StandardDSOClientConfigHelperImpl.java:1218)
[WARNING] [cargo0] at com.tc.object.bytecode.hook.impl.DefaultWeavingStrategy.transformInternal(DefaultWeavingStrategy.java:164)
[WARNING] [cargo0] at com.tc.object.bytecode.hook.impl.DefaultWeavingStrategy.transform(DefaultWeavingStrategy.java:124)
[WARNING] [cargo0] at com.tc.object.bytecode.hook.impl.DSOContextImpl.preProcess(DSOContextImpl.java:168)
[WARNING] [cargo0] at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.defineClass0Pre(ClassProcessorHelper.java:665)
[WARNING] [cargo0] at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
[WARNING] [cargo0] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
[WARNING] [cargo0] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
[WARNING] [cargo0] at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
[WARNING] [cargo0] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
[WARNING] [cargo0] at java.security.AccessController.doPrivileged(Native Method)
[WARNING] [cargo0] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
[WARNING] [cargo0] at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:392)
[WARNING] [cargo0] at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:363)
[WARNING] [cargo0] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
[WARNING] [cargo0] at org.slf4j.impl.StaticLoggerBinder.<init>(StaticLoggerBinder.java:68)
[WARNING] [cargo0] at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:57)
[WARNING] [cargo0] at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:60)
[WARNING] [cargo0] at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155)
[WARNING] [cargo0] at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:131)
[WARNING] [cargo0] at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
[WARNING] [cargo0] at org.springframework.web.context.ContextLoader.<clinit>(ContextLoader.java:146)
[WARNING] [cargo0] at org.springframework.web.context.ContextLoaderListener.createContextLoader(ContextLoaderListener.java:53)
[WARNING] [cargo0] at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:44)
[WARNING] [cargo0] at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
[WARNING] [cargo0] at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
[WARNING] [cargo0] at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239)
[WARNING] [cargo0] at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
[WARNING] [cargo0] at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466)
[WARNING] [cargo0] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[WARNING] [cargo0] at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
[WARNING] [cargo0] at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
[WARNING] [cargo0] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[WARNING] [cargo0] at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
[WARNING] [cargo0] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[WARNING] [cargo0] at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
[WARNING] [cargo0] at org.mortbay.jetty.Server.doStart(Server.java:222)
[WARNING] [cargo0] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[WARNING] [cargo0] at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
[WARNING] [cargo0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[WARNING] [cargo0] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[WARNING] [cargo0] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[WARNING] [cargo0] at java.lang.reflect.Method.invoke(Method.java:597)
[WARNING] [cargo0] at org.mortbay.start.Main.invokeMain(Main.java:194)
[WARNING] [cargo0] at org.mortbay.start.Main.start(Main.java:523)
[WARNING] [cargo0] at org.mortbay.start.Main.main(Main.java:119)

1. Used 1.3.1 version of tc-maven-plugin which uses terracotta 3.0.1
2. Modified version of tim-jetty in tc-config.xml to tim-jetty-6.1-1.3.0
3. tc-3.0 branch uses jetty 6.1.15
4. Ran mvn clean tc:run
5. Ran fine without any exceptions

Verified in version
2009-05-21 22:36:09,982 INFO - Terracotta 3.0.1, as of 20090514-130526 (Revision 12704 by cruise@su10mo5 from 3.0)





[CDV-1232] Can't make java.lang.Boolean.TRUE a DSO root Created: 02/Apr/09  Updated: 24/Mar/11  Resolved: 02/Nov/10

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: Byte Code Transform, DSO:L1
Affects Version/s: None
Fix Version/s: 3.5.0

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Tim Eck
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 3.0
Terracotta Target:
Fremantle

 Description   

Not sure if this necessary needs to work, but it should perhaps fail in a different way. It has been reported that declaring something like java.lang.Boolean.TRUE as a root produces errors like:

Exception in thread "main" java.lang.NoSuchMethodError: java.lang.Boolean.__tc_getTRUE()Ljava/lang/Boolean;
at tctest.TcTest.<clinit>(TcTest.java:4)

The client code is trying to call a root getter synthetic method but alas it does not exist

NOTE: This might work if java.lang.Boolean is listed in <additional-bootjar-classes>



 Comments   
Comment by Tim Eck [ 20/Aug/09 ]

moving to 3.1.x at least (since it was sitting in 3.0.x)





[CDV-1218] Reduce memory footprint of ClientLock instances via lazy initialization of instance data. Created: 16/Mar/09  Updated: 29/May/09  Resolved: 16/Mar/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.0.0

Type: Task Priority: 2 Major
Reporter: Chris Dennis Assignee: Chris Dennis
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to CDV-1282 ClientLock is relying on UnsupportedO... Closed
Fix In Branch:
trunk, 3.0
Fixed In Revision: 3.0 12167 : trunk 12178

 Description   

ClientLocks currently hold large amounts of instance data some of which may never be used (e.g. structures associated with waiting and notifying). The memory footprint of ClientLocks can be reduced by lazily initializing these instance variables.






[CDV-1212] L1 <-> ssh tunnel <-> L2's ; try all the L2's, not only the first one secified in the config file Created: 19/Mar/09  Updated: 27/Jul/12  Resolved: 01/Apr/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.7.3
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: eg eg Assignee: Terracotta User
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File tc-config-server.xml     XML File tc-config.xml     XML File tc-config.xml    
Severity: 2 Feature failure (but system usable), no workaround available
Fix In Branch:
trunk
Bug Type:
Usability Error
Bug Found In Detail: Terracotta 2.7.3, as of 20090129-100125 (Revision 11424 by cruise@su10mo5 from 2.7)

 Description   

L1 <> ssh tunnel <> L2's

using attached config.

setup:
1. L2S2 & L2S3 are on machineA
2. L1 is on machineB
3. ssh tunnel created by executing on machineA:
ssh -v -o "KeepAlive=yes" -Llocalhost:7101:localhost:7101 -Llocalhost:7102:localhost:7102 -Llocalhost:7103:localhost:7103 -Rlocalhost:7201:localhost:7201 -Rlocalhost:7202:localhost:7202 -Rlocalhost:7203:localhost:7203 -Rlocalhost:7301:localhost:7301 -Rlocalhost:7302:localhost:7302 -Rlocalhost:7303:localhost:7303 ssh@machineB

steps to replicate issue:

1. L2S2 - active
2. L2S3 - passive
3. start L1, can connect to active; kill L1
4. force L2 failover
5. L2S3 - active
6. L2S2 - passive
7. start L1, can Not connect to active (do not kill L1). message repeated: "WARN - Timeout connecting to server: localhost:7202. Timeout of 10000 milliseconds occurred"
8. force L2 failover
9. L2S2 - active
10. L2S3 - passive
11. now L1 (from 7.) can connect
12. force L2 failover
13. L2S3 - active
14. L2S2 - passive
15. L1 still connected (jmx thisNodeDisconnect & thisNodeConnect received)

issue:
behavior should be the same as when ssh tunnels aren't used; searching for all the L2's not only the first one secified in the config file.

for normal behavior, modify config file, replacing "localhost" with appropriate values

environment:
1. using 2.7.3
2. machineA - solaris 10 on sparc
3. machineB - windows xp sp3



 Comments   
Comment by Terracotta User [ 01/Apr/09 ]

Hi there,

I think that there is a problem with the ssh tunnel configuration. -Llocalhost:7101:localhost:7101 for example is forwarding the port 7101 on machineA to port 7101 on machineA.

I ran a couple of tests with ssh tunneling and I was not able to reproduce the problem: everything including failover is working as expected. Here is my configuration:

  • server sales02: first L2 (dso port: 9510)
  • server sales03: second L2 (dso port: 9511)
  • server sales04: L1

On sales04, I created the ssh tunnel using the following command: ssh -f -N -L9510:sales02:9510 sales02 && ssh -f -N -L9511:sales03:9511 sales03

The trick is that the tc-config.xml for the L2 and L1 are differents. I have attached the 2 tc-config.xml I am using:

  • tc-config-server.xml is for the L2s
  • tc-config.xml for the L1

Differences between tc-config.xml and tc-config-server.xml:
tc-config-server.xml:
<server name="server1" host="sales02">
[...]
<server name="server2" host="sales03">

tc-config.xml:
<server name="server1" host="localhost">
[...]
<server name="server2" host="localhost">

Hope this helps,

Cheers,

Sylvain





[CDV-1206] attempt to load more than one jar for one <module> listed in tc-config.xml Created: 16/Mar/09  Updated: 10/Apr/09  Resolved: 23/Mar/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.0.0

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Abhishek Singh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File tc-config.xml    
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 3.0
Fixed In Revision: 12276

 Description   

1. Download a 3.0 kit
2. Run tim-get.sh install tim-concurrent-collections (which should intall in kit "modules" dir)
3. Build tim-concurrent-collections and install to local maven repo
4. Try to build a boot jar with the attached config (which includes a <repository>)

It seems to try to load all tim-concurrent-collections in can find, which in this case will be one too many. Why doesn't it stop when it find the first one? What should the preferred repository and order be?

teck@piggy:~/tmp/terracotta-3.0.0-nightly-rev12167/bin$ ./make-boot-jar.sh
2009-03-16 16:47:51,240 INFO - Terracotta 3.0.0-nightly, as of 20090316-150356 (Revision 12167 by cruise@su10mo5 from 3.0)
2009-03-16 16:47:51,904 INFO - Configuration loaded from the file at '/home/teck/tmp/terracotta-3.0.0-nightly-rev12167/bin/tc-config.xml'.
2009-03-16 16:47:52,603 FATAL - BootJarTool: Unable to open the bundle at: 'file:/home/teck/.m2/repository/org/terracotta/modules/tim-concurrent-collections/1.1.0-SNAPSHOT/tim-concurrent-collections-1.1.0-SNAPSHOT.jar'
2009-03-16 16:47:52,603 FATAL - Exception thrown
org.osgi.framework.BundleException: Unable to open the bundle at: 'file:/home/teck/.m2/repository/org/terracotta/modules/tim-concurrent-collections/1.1.0-SNAPSHOT/tim-concurrent-collections-1.1.0-SNAPSHOT.jar'
at com.tc.bundles.AbstractEmbeddedOSGiRuntime.exception(AbstractEmbeddedOSGiRuntime.java:93)
at com.tc.bundles.KnopflerfishOSGi.installBundle(KnopflerfishOSGi.java:200)
at com.tc.bundles.KnopflerfishOSGi.installBundles(KnopflerfishOSGi.java:62)
at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:169)
at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:103)
at com.tc.object.tools.BootJarTool.loadModules(BootJarTool.java:259)
at com.tc.object.tools.BootJarTool.<init>(BootJarTool.java:243)
at com.tc.object.tools.BootJarTool.main(BootJarTool.java:2653)
Caused by: org.osgi.framework.BundleException: Failed to install bundle: java.lang.IllegalArgumentException: Bundle with same symbolic name and version is already installed (org.terracotta.modules.tim-concurrent-collections, 1.1.0.SNAPSHOT
at org.knopflerfish.framework.Bundles.install0(Bundles.java:163)
at org.knopflerfish.framework.PermissionOps.callInstall0(PermissionOps.java:249)
at org.knopflerfish.framework.Bundles.install(Bundles.java:93)
at org.knopflerfish.framework.Framework.installBundle(Framework.java:488)
at com.tc.bundles.KnopflerfishOSGi.installBundle(KnopflerfishOSGi.java:186)
... 6 more
Caused by: java.lang.IllegalArgumentException: Bundle with same symbolic name and version is already installed (org.terracotta.modules.tim-concurrent-collections, 1.1.0.SNAPSHOT
at org.knopflerfish.framework.BundleImpl.checkManifestHeaders(BundleImpl.java:1263)
at org.knopflerfish.framework.BundleImpl.<init>(BundleImpl.java:245)
at org.knopflerfish.framework.Bundles.install0(Bundles.java:143)
... 10 more



 Comments   
Comment by Walter Harley [ 20/Mar/09 ]

Same breakage is affecting tim-hibernate tests, when run against locally built 3.0 TC. Tests fail with this output in client log:

2009-03-20 12:08:45,070 [main] INFO com.tc.bundles.Resolver - Resolved TIM org.terracotta.modules:tim-tomcat-6.0:1.0.0-SNAPSHOT from /Users/wharley/.m2/repository/org/terracotta/modules/tim-tomcat-6.0/1.0.0-SNAPSHOT/tim-tomcat-6.0-1.0.0-SNAPSHOT.jar
2009-03-20 12:08:45,169 [main] INFO com.tc.bundles.Resolver - Resolved TIM org.terracotta.modules:tim-hibernate-3.2.5:1.3.0-SNAPSHOT from /Users/wharley/.m2/repository/org/terracotta/modules/tim-hibernate-3.2.5/1.3.0-SNAPSHOT/tim-hibernate-3.2.5-1.3.0-SNAPSHOT.jar
2009-03-20 12:08:45,191 [main] INFO com.tc.bundles.Resolver - Resolved TIM org.terracotta.modules:tim-ehcache-1.3:1.3.0-SNAPSHOT from /Users/wharley/.m2/repository/org/terracotta/modules/tim-ehcache-1.3/1.3.0-SNAPSHOT/tim-ehcache-1.3-1.3.0-SNAPSHOT.jar
2009-03-20 12:08:45,219 [main] ERROR com.terracottatech.dso.runtime - Unable to open the bundle at: 'file:/Users/wharley/dev/forge/projects/trunk/tim-hibernate/tim-hibernate-3.2.5-system-tests/target/temp/ContainerHibernate325Test/sandbox/modules/org/terracotta/modules/tim-tomcat-6.0/1.0.0-SNAPSHOT/tim-tomcat-6.0-1.0.0-SNAPSHOT.jar'
org.osgi.framework.BundleException: Failed to install bundle: java.lang.IllegalArgumentException: Bundle with same symbolic name and version is already installed (org.terracotta.modules.tim-tomcat-6.0, 1.0.0.SNAPSHOT
at org.knopflerfish.framework.Bundles.install0(Bundles.java:163)
at org.knopflerfish.framework.PermissionOps.callInstall0(PermissionOps.java:249)
at org.knopflerfish.framework.Bundles.install(Bundles.java:93)
at org.knopflerfish.framework.Framework.installBundle(Framework.java:488)
at com.tc.bundles.KnopflerfishOSGi.installBundle(KnopflerfishOSGi.java:186)
at com.tc.bundles.KnopflerfishOSGi.installBundles(KnopflerfishOSGi.java:62)
at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:169)
at com.tc.object.bytecode.hook.impl.DSOContextImpl.<init>(DSOContextImpl.java:114)
at com.tc.object.bytecode.hook.impl.DSOContextImpl.createGlobalContext(DSOContextImpl.java:67)
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 com.tc.object.bytecode.hook.impl.ClassProcessorHelper.createGlobalContext(ClassProcessorHelper.java:641)
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.initialize(ClassProcessorHelper.java:400)
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.defineClass0Pre(ClassProcessorHelper.java:680)
at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
at javax.management.remote.rmi.NoCallStackClassLoader.findClass(NoCallStackClassLoader.java:108)
at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at javax.management.remote.rmi.RMIConnector$1.run(RMIConnector.java:2050)
at java.security.AccessController.doPrivileged(Native Method)
at javax.management.remote.rmi.RMIConnector.<clinit>(RMIConnector.java:2071)
at javax.management.remote.rmi.RMIConnectorServer.objectToBind(RMIConnectorServer.java:728)
at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:392)
at sun.management.jmxremote.ConnectorBootstrap.exportMBeanServer(ConnectorBootstrap.java:686)
at sun.management.jmxremote.ConnectorBootstrap.initialize(ConnectorBootstrap.java:379)
at sun.management.Agent.startAgent(Agent.java:127)
at sun.management.Agent.startAgent(Agent.java:239)
[etc...]
Caused by: java.lang.IllegalArgumentException: Bundle with same symbolic name and version is already installed (org.terracotta.modules.tim-tomcat-6.0, 1.0.0.SNAPSHOT
at org.knopflerfish.framework.BundleImpl.checkManifestHeaders(BundleImpl.java:1263)
at org.knopflerfish.framework.BundleImpl.<init>(BundleImpl.java:245)
at org.knopflerfish.framework.Bundles.install0(Bundles.java:143)
... 29 more

Comment by Abhishek Singh [ 23/Mar/09 ]

Fix in rev-12276 fro 3.0 and rev-12277in trunk.

Comment by Abhishek Singh [ 24/Mar/09 ]

Added test - testModuleInMultipleRepo() in ModulesLoaderTest
Rev-12292 for trunk
Rev-12293 for tc-3.0 branch

Comment by nadeem ghani [ 30/Mar/09 ]

fixed in rev12376

> bin/make-boot-jar.sh -f ~/Desktop/CDV-1206-tc-config.xml
2009-03-30 13:24:29,074 INFO - Terracotta Enterprise 3.0.0-nightly, as of 20090330-080314 (Revision 3808-12376 by cruise@su10mo5 from 3.0)
2009-03-30 13:24:29,601 INFO - Configuration loaded from the file at '/Users/nghani/Desktop/CDV-1206-tc-config.xml'.





[CDV-1186] jboss 4.2.3 integration changed since terracotta 2.7.3 release? Created: 10/Mar/09  Updated: 16/Nov/09  Resolved: 10/Mar/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1, Integration Modules, Sessions
Affects Version/s: trunk-nightly
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Mike Ruddy Assignee: Issue Review Board
Resolution: As Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 273-terracotta-client.log     Text File nightly-terracotta-client.log    
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Bug Found In Detail: Terracotta trunk-nightly, as of 20090309-110315 (Revision 12046 by cruise@su10mo5 from trunk)

 Description   

it appears that the jboss 4.2.3 integration has changed since "Terracotta 2.7.3, as of 20090129-100125 (Revision 11424 by cruise@su10mo5 from 2.7)"

i have a simple test app that i can setup and run with clustered sessions on jboss 4.2.3 with terracotta 2.7.3. when i start up the same client and point it to the terracotta nightly installation, everything starts up fine, but the sessions don't get clustered.

i'll attach the client logs. the obvious difference is that in the nightly log, there's this:
2009-03-10 11:34:22,195 [main] WARN com.terracottatech.dso - One or more web applications are listed in the Terracotta configuration file, but no container TIMs have been loaded.
See http://www.terracotta.org/tim-warning for more information.

obviously, i went to that url, but i didn't see an obvious answer to solve this problem.

my questions are, is this a planned switch in how the features should work out of the box? if so, will the jboss app server integration documentation be updated to include the extra steps necessary to get things working in the new versions? and, in the meantime, what are those steps?



 Comments   
Comment by Fiona OShea [ 10/Mar/09 ]

Mike, yes using 3.0 (Terracotta trunk-nightly, as of 20090309-110315 (Revision 12046 by cruise@su10mo5 from trunk) you will need to add the container tim to the installed version of Terracotta, using tim-get.

2.7.3 will contain the containers.

http://www.terracotta.org/web/display/orgsite/Integration+Guides

Comment by Mike Ruddy [ 11/Mar/09 ]

1 - today, i started with a fresh install of terracotta-trunk-nightly-rev12059

2 - i changed my tc-config.xml to be:

<tc:tc-config xmlns:tc="http://www.terracotta.org/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.terracotta.org/schema/terracotta-4.xsd">
<servers>
<server host="localhost">
<dso-port>9510</dso-port>
</server>
</servers>
<clients>
<modules>
<module name="tim-jboss-4.2" version="1.0.0-SNAPSHOT" />
</modules>
</clients>
<application>
<dso>
<web-applications>
<web-application>test</web-application>
</web-applications>
</dso>
</application>
</tc:tc-config>

3 - i installed all the tims:

> ./terracotta-trunk-nightly-rev12059/bin/tim-get.sh install --all
Terracotta trunk-nightly, as of 20090310-110303 (Revision 12059 by cruise@su10mo5 from trunk)

      • Installing all of the latest integration modules for TC 1.1.0-SNAPSHOT ***

Installing tim-annotations 1.3.0-SNAPSHOT...
INSTALLED: tim-annotations 1.3.0-SNAPSHOT - Ok
Installing tim-apache-collections-3.1 1.0.0-SNAPSHOT...
INSTALLED: tim-apache-collections-3.1 1.0.0-SNAPSHOT - Ok
Installing tim-apache-struts-1.1 1.3.0-SNAPSHOT...
SKIPPED: tim-apache-struts-1.1 1.3.0-SNAPSHOT - Already installed
Installing tim-async-processing 1.1.0-SNAPSHOT and dependencies...
INSTALLED: tim-async-processing 1.1.0-SNAPSHOT - Ok
SKIPPED: tim-annotations 1.3.0-SNAPSHOT - Already installed
Installing tim-cglib-2.1.3 1.3.0-SNAPSHOT...
INSTALLED: tim-cglib-2.1.3 1.3.0-SNAPSHOT - Ok
Installing tim-concurrent-collections 1.1.0-SNAPSHOT...
INSTALLED: tim-concurrent-collections 1.1.0-SNAPSHOT - Ok
Installing tim-ehcache-1.2.4 1.3.0-SNAPSHOT and dependencies...
INSTALLED: tim-ehcache-1.2.4 1.3.0-SNAPSHOT - Ok
DOWNLOAD FAILED: clustered-commons-collections-3.1 2.8.0-SNAPSHOT
Attempt to download TIM file at http://www.terracotta.org/download/reflector/maven2/org/terracotta/modules/clustered-commons-collections-3.1/2.8.0-SNAPSHOT/clustered-commons-collections-3.1-2.8.0-SNAPSHOT.jar failed - http://download.terracotta.org/maven2/org/terracotta/modules/clustered-commons-collections-3.1/2.8.0-SNAPSHOT/clustered-commons-collections-3.1-2.8.0-SNAPSHOT.jar
INSTALLED: tim-ehcache-commons 1.3.0-SNAPSHOT - Ok
Installing tim-ehcache-1.3 1.3.0-SNAPSHOT and dependencies...
INSTALLED: tim-ehcache-1.3 1.3.0-SNAPSHOT - Ok
SKIPPED: tim-ehcache-commons 1.3.0-SNAPSHOT - Already installed
Installing tim-ehcache-1.4.1 1.3.0-SNAPSHOT and dependencies...
INSTALLED: tim-ehcache-1.4.1 1.3.0-SNAPSHOT - Ok
SKIPPED: tim-ehcache-commons 1.3.0-SNAPSHOT - Already installed
Installing tim-ehcache-commons 1.3.0-SNAPSHOT...
SKIPPED: tim-ehcache-commons 1.3.0-SNAPSHOT - Already installed
Installing tim-glassfish-common 1.0.0-SNAPSHOT and dependencies...
INSTALLED: tim-glassfish-common 1.0.0-SNAPSHOT - Ok
INSTALLED: tim-session-common 1.0.0-SNAPSHOT - Ok
INSTALLED: tim-tomcat-5.0 1.0.0-SNAPSHOT - Ok
INSTALLED: tim-tomcat-common 1.0.0-SNAPSHOT - Ok
Installing tim-glassfish-v1 1.0.0-SNAPSHOT and dependencies...
INSTALLED: tim-glassfish-v1 1.0.0-SNAPSHOT - Ok
SKIPPED: tim-glassfish-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-session-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-tomcat-5.0 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-tomcat-common 1.0.0-SNAPSHOT - Already installed
Installing tim-glassfish-v2 1.0.0-SNAPSHOT and dependencies...
INSTALLED: tim-glassfish-v2 1.0.0-SNAPSHOT - Ok
SKIPPED: tim-glassfish-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-session-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-tomcat-5.0 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-tomcat-common 1.0.0-SNAPSHOT - Already installed
Installing tim-guice-1.0 1.1.0-SNAPSHOT...
INSTALLED: tim-guice-1.0 1.1.0-SNAPSHOT - Ok
Installing tim-hashtable 2.4.0-SNAPSHOT...
INSTALLED: tim-hashtable 2.4.0-SNAPSHOT - Ok
Installing tim-hibernate-3.1.2 1.3.0-SNAPSHOT and dependencies...
INSTALLED: tim-hibernate-3.1.2 1.3.0-SNAPSHOT - Ok
SKIPPED: tim-apache-collections-3.1 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-cglib-2.1.3 1.3.0-SNAPSHOT - Already installed
SKIPPED: tim-ehcache-1.3 1.3.0-SNAPSHOT - Already installed
SKIPPED: tim-ehcache-commons 1.3.0-SNAPSHOT - Already installed
Installing tim-hibernate-3.2.5 1.3.0-SNAPSHOT and dependencies...
INSTALLED: tim-hibernate-3.2.5 1.3.0-SNAPSHOT - Ok
SKIPPED: tim-apache-collections-3.1 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-cglib-2.1.3 1.3.0-SNAPSHOT - Already installed
SKIPPED: tim-ehcache-1.3 1.3.0-SNAPSHOT - Already installed
SKIPPED: tim-ehcache-commons 1.3.0-SNAPSHOT - Already installed
Installing tim-ibatis-2.2.0 1.2.0-SNAPSHOT and dependencies...
INSTALLED: tim-ibatis-2.2.0 1.2.0-SNAPSHOT - Ok
SKIPPED: tim-cglib-2.1.3 1.3.0-SNAPSHOT - Already installed
Installing tim-jboss-3.2 1.0.0-SNAPSHOT and dependencies...
INSTALLED: tim-jboss-3.2 1.0.0-SNAPSHOT - Ok
INSTALLED: tim-jboss-common 1.0.0-SNAPSHOT - Ok
SKIPPED: tim-tomcat-5.0 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-tomcat-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-session-common 1.0.0-SNAPSHOT - Already installed
Installing tim-jboss-4.0 1.0.0-SNAPSHOT and dependencies...
INSTALLED: tim-jboss-4.0 1.0.0-SNAPSHOT - Ok
SKIPPED: tim-jboss-common 1.0.0-SNAPSHOT - Already installed
INSTALLED: tim-tomcat-5.5 1.0.0-SNAPSHOT - Ok
SKIPPED: tim-tomcat-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-session-common 1.0.0-SNAPSHOT - Already installed
Installing tim-jboss-4.2 1.0.0-SNAPSHOT and dependencies...
INSTALLED: tim-jboss-4.2 1.0.0-SNAPSHOT - Ok
SKIPPED: tim-jboss-4.0 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-jboss-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-tomcat-5.5 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-tomcat-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-session-common 1.0.0-SNAPSHOT - Already installed
Installing tim-jboss-common 1.0.0-SNAPSHOT...
SKIPPED: tim-jboss-common 1.0.0-SNAPSHOT - Already installed
Installing tim-jetty-6.1 1.2.0-SNAPSHOT...
SKIPPED: tim-jetty-6.1 1.2.0-SNAPSHOT - Already installed
Installing tim-jmx-util 1.1.0-SNAPSHOT...
INSTALLED: tim-jmx-util 1.1.0-SNAPSHOT - Ok
Installing tim-map-evictor 1.1.0-SNAPSHOT...
INSTALLED: tim-map-evictor 1.1.0-SNAPSHOT - Ok
Installing tim-masterworker 1.4.0-SNAPSHOT and dependencies...
INSTALLED: tim-masterworker 1.4.0-SNAPSHOT - Ok
INSTALLED: tim-pipes 1.4.0-SNAPSHOT - Ok
Installing tim-pipes 1.4.0-SNAPSHOT...
SKIPPED: tim-pipes 1.4.0-SNAPSHOT - Already installed
Installing tim-quartz-1.5.1 1.1.0-SNAPSHOT...
INSTALLED: tim-quartz-1.5.1 1.1.0-SNAPSHOT - Ok
Installing tim-quartz-1.6.1 1.1.0-SNAPSHOT...
INSTALLED: tim-quartz-1.6.1 1.1.0-SNAPSHOT - Ok
Installing tim-rife-1.6.0 1.2.0-SNAPSHOT...
SKIPPED: tim-rife-1.6.0 1.2.0-SNAPSHOT - Already installed
Installing tim-session-common 1.0.0-SNAPSHOT...
SKIPPED: tim-session-common 1.0.0-SNAPSHOT - Already installed
Installing tim-session-system-tests 1.0.0-SNAPSHOT...
INSTALLED: tim-session-system-tests 1.0.0-SNAPSHOT - Ok
Installing tim-spring-security-2.0 1.1.0-SNAPSHOT...
INSTALLED: tim-spring-security-2.0 1.1.0-SNAPSHOT - Ok
Installing tim-spring-security-2.0.3 1.0.0-SNAPSHOT...
INSTALLED: tim-spring-security-2.0.3 1.0.0-SNAPSHOT - Ok
Installing tim-spring-webflow 1.1.0-SNAPSHOT...
INSTALLED: tim-spring-webflow 1.1.0-SNAPSHOT - Ok
Installing tim-svt 1.1.0-SNAPSHOT...
INSTALLED: tim-svt 1.1.0-SNAPSHOT - Ok
Installing tim-synchronizedcollection 2.4.0-SNAPSHOT...
INSTALLED: tim-synchronizedcollection 2.4.0-SNAPSHOT - Ok
Installing tim-synchronizedmap 2.4.0-SNAPSHOT...
INSTALLED: tim-synchronizedmap 2.4.0-SNAPSHOT - Ok
Installing tim-synchronizedset 2.4.0-SNAPSHOT...
INSTALLED: tim-synchronizedset 2.4.0-SNAPSHOT - Ok
Installing tim-synchronizedsortedmap 2.4.0-SNAPSHOT...
INSTALLED: tim-synchronizedsortedmap 2.4.0-SNAPSHOT - Ok
Installing tim-synchronizedsortedset 2.4.0-SNAPSHOT...
INSTALLED: tim-synchronizedsortedset 2.4.0-SNAPSHOT - Ok
Installing tim-tccache 1.1.0-SNAPSHOT and dependencies...
INSTALLED: tim-tccache 1.1.0-SNAPSHOT - Ok
SKIPPED: tim-concurrent-collections 1.1.0-SNAPSHOT - Already installed
SKIPPED: tim-map-evictor 1.1.0-SNAPSHOT - Already installed
Installing tim-tomcat-5.0 1.0.0-SNAPSHOT and dependencies...
SKIPPED: tim-tomcat-5.0 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-tomcat-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-session-common 1.0.0-SNAPSHOT - Already installed
Installing tim-tomcat-5.5 1.0.0-SNAPSHOT and dependencies...
SKIPPED: tim-tomcat-5.5 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-tomcat-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-session-common 1.0.0-SNAPSHOT - Already installed
Installing tim-tomcat-6.0 1.0.0-SNAPSHOT and dependencies...
INSTALLED: tim-tomcat-6.0 1.0.0-SNAPSHOT - Ok
SKIPPED: tim-tomcat-5.5 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-tomcat-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-session-common 1.0.0-SNAPSHOT - Already installed
Installing tim-tomcat-common 1.0.0-SNAPSHOT and dependencies...
SKIPPED: tim-tomcat-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-session-common 1.0.0-SNAPSHOT - Already installed
Installing tim-tree-map-cache 1.3.0-SNAPSHOT...
INSTALLED: tim-tree-map-cache 1.3.0-SNAPSHOT - Ok
Installing tim-vector 2.4.0-SNAPSHOT...
INSTALLED: tim-vector 2.4.0-SNAPSHOT - Ok
Installing tim-weblogic-10 1.0.0-SNAPSHOT and dependencies...
INSTALLED: tim-weblogic-10 1.0.0-SNAPSHOT - Ok
INSTALLED: tim-weblogic-common 1.0.0-SNAPSHOT - Ok
SKIPPED: tim-session-common 1.0.0-SNAPSHOT - Already installed
Installing tim-weblogic-9 1.0.0-SNAPSHOT and dependencies...
INSTALLED: tim-weblogic-9 1.0.0-SNAPSHOT - Ok
SKIPPED: tim-weblogic-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-session-common 1.0.0-SNAPSHOT - Already installed
Installing tim-weblogic-common 1.0.0-SNAPSHOT and dependencies...
SKIPPED: tim-weblogic-common 1.0.0-SNAPSHOT - Already installed
SKIPPED: tim-session-common 1.0.0-SNAPSHOT - Already installed
Installing tim-wicket-1.3 1.2.0-SNAPSHOT...
INSTALLED: tim-wicket-1.3 1.2.0-SNAPSHOT - Ok

Done. (Make sure to update your tc-config.xml with the new/updated version if necessary)

4 - i started the tc server and then tried to start a client and got the following exception:

> ./jboss-eap-4.3/jboss-as/bin/tc-run.sh
Starting BootJarTool...
2009-03-11 09:45:56,278 INFO - Terracotta trunk-nightly, as of 20090310-110303 (Revision 12059 by cruise@su10mo5 from trunk)
2009-03-11 09:45:56,730 INFO - Configuration loaded from the file at '/home/mruddy/jboss-eap-4.3/jboss-as/server/tc-config.xml'.
2009-03-11 09:45:57,353 FATAL - BootJarTool: Unable to resolve dependency TIM: modules-base version [1.0.0.SNAPSHOT,1.1.0.SNAPSHOT) (group-id: org.terracotta.modules)

Attempted to resolve the TIM using the following descriptors:

groupId: org.terracotta.modules
name : tim-jboss-common
version: 1.0.0-SNAPSHOT

Expected the TIM's filename to be:

tim-jboss-common-1.0.0-SNAPSHOT.jar

Expected these attributes to be in the manifest:

Bundle-SymbolicName: org.terracotta.modules.tim-jboss-common
Bundle-Version : 1.0.0.SNAPSHOT

Searched using the following repositories:

+ /home/mruddy/terracotta-trunk-nightly-rev12059/modules

Tried to resolve the jar file using the following paths:

+ /home/mruddy/terracotta-trunk-nightly-rev12059/modules/org/terracotta/modules/tim-jboss-common/1.0.0-SNAPSHOT/tim-jboss-common-1.0.0-SNAPSHOT.jar
+ /home/mruddy/terracotta-trunk-nightly-rev12059/modules/tim-jboss-common-1.0.0-SNAPSHOT.jar

The following shows the dependencies path the resolver took and why it needed to locate the missing TIM:

tim-jboss-4.2 version 1.0.0-SNAPSHOT (group-id: org.terracotta.modules, file: tim-jboss-4.2-1.0.0-SNAPSHOT.jar)
+- tim-jboss-common version 1.0.0-SNAPSHOT (group-id: org.terracotta.modules, file: tim-jboss-common-1.0.0-SNAPSHOT.jar)
+- modules-base version [1.0.0.SNAPSHOT,1.1.0.SNAPSHOT) (group-id: org.terracotta.modules, file: modules-base-[1.0.0.SNAPSHOT,1.1.0.SNAPSHOT).jar)

If the jar file exists and is in one of the paths listed above, make sure that the Bundle-SymbolicName and
Bundle-Version attribute in its manifest matches the ones that the resolver expects.

If you do not have this particular TIM or any of its dependencies installed, try using the tim-get tool's
'install' command:

$ tim-get.sh install tim-jboss-common 1.0.0-SNAPSHOT org.terracotta.modules

You can also use the tool's 'list' command to see if it's actually available:

$ tim-get.sh list tim-jboss-common # list anything that has 'tim-jboss-common' in it's name
$ tim-get.sh list # or, list everything that is available

For more information on how to use the tim-get tool, invoke:

$ tim-get.sh help
2009-03-11 09:45:57,355 FATAL - Exception thrown
org.osgi.framework.BundleException: Unable to resolve dependency TIM: modules-base version [1.0.0.SNAPSHOT,1.1.0.SNAPSHOT) (group-id: org.terracotta.modules)

Attempted to resolve the TIM using the following descriptors:

groupId: org.terracotta.modules
name : tim-jboss-common
version: 1.0.0-SNAPSHOT

Expected the TIM's filename to be:

tim-jboss-common-1.0.0-SNAPSHOT.jar

Expected these attributes to be in the manifest:

Bundle-SymbolicName: org.terracotta.modules.tim-jboss-common
Bundle-Version : 1.0.0.SNAPSHOT

Searched using the following repositories:

+ /home/mruddy/terracotta-trunk-nightly-rev12059/modules

Tried to resolve the jar file using the following paths:

+ /home/mruddy/terracotta-trunk-nightly-rev12059/modules/org/terracotta/modules/tim-jboss-common/1.0.0-SNAPSHOT/tim-jboss-common-1.0.0-SNAPSHOT.jar
+ /home/mruddy/terracotta-trunk-nightly-rev12059/modules/tim-jboss-common-1.0.0-SNAPSHOT.jar

The following shows the dependencies path the resolver took and why it needed to locate the missing TIM:

tim-jboss-4.2 version 1.0.0-SNAPSHOT (group-id: org.terracotta.modules, file: tim-jboss-4.2-1.0.0-SNAPSHOT.jar)
+- tim-jboss-common version 1.0.0-SNAPSHOT (group-id: org.terracotta.modules, file: tim-jboss-common-1.0.0-SNAPSHOT.jar)
+- modules-base version [1.0.0.SNAPSHOT,1.1.0.SNAPSHOT) (group-id: org.terracotta.modules, file: modules-base-[1.0.0.SNAPSHOT,1.1.0.SNAPSHOT).jar)

If the jar file exists and is in one of the paths listed above, make sure that the Bundle-SymbolicName and
Bundle-Version attribute in its manifest matches the ones that the resolver expects.

If you do not have this particular TIM or any of its dependencies installed, try using the tim-get tool's
'install' command:

$ tim-get.sh install tim-jboss-common 1.0.0-SNAPSHOT org.terracotta.modules

You can also use the tool's 'list' command to see if it's actually available:

$ tim-get.sh list tim-jboss-common # list anything that has 'tim-jboss-common' in it's name
$ tim-get.sh list # or, list everything that is available

For more information on how to use the tim-get tool, invoke:

$ tim-get.sh help
at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:110)
at com.tc.object.tools.BootJarTool.loadModules(BootJarTool.java:260)
at com.tc.object.tools.BootJarTool.<init>(BootJarTool.java:244)
at com.tc.object.tools.BootJarTool.main(BootJarTool.java:2642)

5 - the file /home/mruddy/terracotta-trunk-nightly-rev12059/modules/org/terracotta/modules/tim-jboss-common/1.0.0-SNAPSHOT/tim-jboss-common-1.0.0-SNAPSHOT.jar exists and the manifest from it is:
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: cruise
Build-Jdk: 1.6.0_12
Bundle-Category: Terracotta Integration Module
Bundle-Name: tim-jboss-common
Bundle-Copyright: Copyright (c) 2007 - 2008 Terracotta, Inc.
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Require-Bundle: org.terracotta.modules.modules-base;bundle-version:="[
1.0.0.SNAPSHOT,1.1.0.SNAPSHOT)"
Bundle-Vendor: Terracotta, Inc.
Terracotta-InternalTIM: true
Bundle-Version: 1.0.0.SNAPSHOT
Bundle-ManifestVersion: 2
Bundle-Activator: org.terracotta.modules.jboss.common.JBossCommonConfi
gurator
Bundle-Description: tim-jboss root project
Import-Package: org.terracotta.modules.configuration
Bundle-SymbolicName: org.terracotta.modules.tim-jboss-common

the only modules-base that i have installed is at /home/mruddy/terracotta-trunk-nightly-rev12059/modules/org/terracotta/modules/modules-base/1.1.0-SNAPSHOT/modules-base-1.1.0-SNAPSHOT.jar

is the problem that the module loader's trying to find a file named "modules-base-[1.0.0.SNAPSHOT,1.1.0.SNAPSHOT).jar" ?

Comment by Tim Eck [ 11/Mar/09 ]

thanks for the report, we'll have a look. In the meantime I suggest you use terracotta builds from the 3.0 release line (trunk builds are development snapshots for beyond 3.0 are known to have issues with TIMs). You can get 3.0.0-stable0 TC version from our main download page.

Comment by Mike Ruddy [ 11/Mar/09 ]

cool, i just tried "Terracotta 3.0.0-stable0, as of 20090306-110324 (Revision 12024 by cruise@su10mo5 from 3.0)" and i did not get the same tim problem. thanks!

also, this next thing didn't effect me (at least not yet or that i realize), but i saw it while installing all of the tims (i tried multiple times and the download failed everytime):

./terracotta-3.0.0-stable0/bin/tim-get.sh install --all
Terracotta 3.0.0-stable0, as of 20090306-110324 (Revision 12024 by cruise@su10mo5 from 3.0)

      • Installing all of the latest integration modules for TC 1.0.0-SNAPSHOT ***

Installing tim-annotations 1.3.0-SNAPSHOT...
INSTALLED: tim-annotations 1.3.0-SNAPSHOT - Ok
Installing tim-apache-collections-3.1 1.0.0-SNAPSHOT...
INSTALLED: tim-apache-collections-3.1 1.0.0-SNAPSHOT - Ok
Installing tim-apache-struts-1.1 1.3.0-SNAPSHOT...
SKIPPED: tim-apache-struts-1.1 1.3.0-SNAPSHOT - Already installed
Installing tim-async-processing 1.1.0-SNAPSHOT and dependencies...
INSTALLED: tim-async-processing 1.1.0-SNAPSHOT - Ok
SKIPPED: tim-annotations 1.3.0-SNAPSHOT - Already installed
Installing tim-cglib-2.1.3 1.3.0-SNAPSHOT...
INSTALLED: tim-cglib-2.1.3 1.3.0-SNAPSHOT - Ok
Installing tim-concurrent-collections 1.1.0-SNAPSHOT...
INSTALLED: tim-concurrent-collections 1.1.0-SNAPSHOT - Ok
Installing tim-ehcache-1.2.4 1.3.0-SNAPSHOT and dependencies...
INSTALLED: tim-ehcache-1.2.4 1.3.0-SNAPSHOT - Ok
DOWNLOAD FAILED: clustered-commons-collections-3.1 2.8.0-SNAPSHOT
Attempt to download TIM file at http://www.terracotta.org/download/reflector/maven2/org/terracotta/modules/clustered-commons-collections-3.1/2.8.0-SNAPSHOT/clustered-commons-collections-3.1-2.8.0-SNAPSHOT.jar failed - http://download.terracotta.org/maven2/org/terracotta/modules/clustered-commons-collections-3.1/2.8.0-SNAPSHOT/clustered-commons-collections-3.1-2.8.0-SNAPSHOT.jar
INSTALLED: tim-ehcache-commons 1.3.0-SNAPSHOT - Ok

Comment by Tim Eck [ 11/Mar/09 ]

I think you're talking about "clustered-commons-collections" failing to download, and if so that is something that is in the process of being fixed. thanks again, glad to hear 3.0 is working for you

Comment by Fiona OShea [ 11/Mar/09 ]

CDV-1190 tracks the clsutered-commons-collections failing to download





[CDV-1183] Improve error message for missing classloader Created: 09/Mar/09  Updated: 27/Jul/12  Resolved: 12/Mar/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 3.0.0, trunk-nightly
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Walter Harley Assignee: Interfaces Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by CDV-1256 Bad error message when missing classl... Closed
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 3.0

 Description   

Now that we've moved sessions to the forge, some applications and tests that used to work will fail somewhat mysteriously with an IllegalStateException, along the lines of the appended stack trace.

This exception happens because the container TIM (in the below case, tim-tomcat-6.0) was not included in the modules list. It would be nice to expand this error message a little bit, to suggest that the user may be missing a TIM. The message is generated in NamedLoaderAdapter, which is applied to java.lang.ClassLoader, so it needs to be phrased very generally, but still it is safe to assume that if a user hits this it is because of some missing integration code.

I would suggest "This classloader instance has not been registered. This may indicate that a required Terracotta Integration Module is missing from the Terracotta configuration. (loader class: org.apache.catalina.loader.WebappClassLoader)"

As an aside, the reason this specific exception happens is that in lieu of the container TIM, the WebappClassLoader gets an implementation of NamedClassLoader from our instrumentation of java.lang.ClassLoader. Thus, it's still a NamedClassLoader as far as com.tcspring.ApplicationHelper is concerned, but it has not been registered. This makes me somewhat suspicious of TC core code (like the constructor of ApplicationHelper) that tries to check whether a ClassLoader is an instanceof NamedClassLoader - if TC is running at all, this will always be true, and if TC is not running, how would the check get executed?

The problem has existed all along but it is made more likely by sessions -> forge.

[WARNING] [cargo0] java.lang.IllegalStateException: Classloader name not set, instances defined from this loader not supported in Terracotta (loader: org.apache.catalina.loader.WebappClassLoader)
[WARNING] [cargo0] at java.lang.ClassLoader.__tc_getClassLoaderName(ClassLoader.java)
[WARNING] [cargo0] at com.tcspring.ApplicationHelper.getAppNameFrom(ApplicationHelper.java:49)
[WARNING] [cargo0] at com.tcspring.ApplicationHelper.<init>(ApplicationHelper.java:42)
[WARNING] [cargo0] at com.tcspring.DistributableBeanFactoryMixin.<init>(DistributableBeanFactoryMixin.java:64)
[WARNING] [cargo0] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[WARNING] [cargo0] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
[WARNING] [cargo0] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[WARNING] [cargo0] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
[WARNING] [cargo0] at com.tc.aspectwerkz.aspect.DefaultMixinFactory.mixinOf(DefaultMixinFactory.java:130)
[WARNING] [cargo0] at com.tc.aspectwerkz.aspect.management.Mixins.mixinOf(Mixins.java:142)
[WARNING] [cargo0] at com.tc.aspectwerkz.aspect.management.Mixins.mixinOf(Mixins.java:124)
[WARNING] [cargo0] at org.springframework.beans.factory.support.AbstractBeanFactory.<init>(AbstractBeanFactory.java:147)
[WARNING] [cargo0] at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.<init>(AbstractAutowireCapableBeanFactory.java:144)
[WARNING] [cargo0] at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.<init>(AbstractAutowireCapableBeanFactory.java:155)
[WARNING] [cargo0] at org.springframework.beans.factory.support.DefaultListableBeanFactory.<init>(DefaultListableBeanFactory.java:121)
[WARNING] [cargo0] at org.springframework.context.support.AbstractRefreshableApplicationContext.createBeanFactory(AbstractRefreshableApplicationContext.java:176)
[WARNING] [cargo0] at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:121)
[WARNING] [cargo0] at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:423)
[WARNING] [cargo0] at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:353)
[WARNING] [cargo0] at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
[WARNING] [cargo0] at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
[WARNING] [cargo0] at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
[WARNING] [cargo0] at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843)
[WARNING] [cargo0] at org.apache.catalina.core.StandardContext.start(StandardContext.java:4342)
[WARNING] [cargo0] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
[WARNING] [cargo0] at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
[WARNING] [cargo0] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
[WARNING] [cargo0] at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
[WARNING] [cargo0] at org.apache.catalina.core.StandardService.start(StandardService.java:516)
[WARNING] [cargo0] at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
[WARNING] [cargo0] at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
[WARNING] [cargo0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[WARNING] [cargo0] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[WARNING] [cargo0] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[WARNING] [cargo0] at java.lang.reflect.Method.invoke(Method.java:597)
[WARNING] [cargo0] at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
[WARNING] [cargo0] at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)



 Comments   
Comment by Tim Eck [ 09/Mar/09 ]

The message could allude to a missing TIM for sure. Of course this isn't the only reason that you;d get this exception since there are lots of loaders in this world that are both not named and not part of a web container internals. As long as the message doesn't claim that the only thing that can wrong is a missing container TIM then I'm all for this

Comment by Walter Harley [ 12/Mar/09 ]

Resolving as duplicate of DEV-2031





[CDV-1180] LiteralValues should be an enum Created: 09/Mar/09  Updated: 20/Aug/09  Resolved: 09/Apr/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.1.0

Type: Bug Priority: 2 Major
Reporter: Walter Harley Assignee: Abhishek Singh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Fixed In Revision: 12481 in trunk

 Description   

The LiteralValues class is a big collection of int constants and switch statements. It is subject to change over time depending on what types are handled as literals. When it changes, code in several different other classes is affected, so it has a comment:

  • NOTE:: READ THIS IF YOU ARE ADDING NEW TYPES TO THIS FILE. XXX:: If you are adding more types, please see
  • PhysicalStateClassLoader and DNAEncoding. You need to be adding New code in both those classes or else some things
  • will be broken.

Now that we can use Java 5 features, this class seems like a good candidate for conversion to an enum. At the same time we do that, we should also consider changing the way it is used: at present, the class is separately and privately instantiated by more than a dozen clients, even though it has no mutable data and could just be static.



 Comments   
Comment by Alex Miller [ 25/Mar/09 ]

trunk-only!

Comment by Abhishek Singh [ 09/Apr/09 ]

Fixed in trunk rev-12481

Do we need to merge in 3.0 branch?

Comment by Kalai Kannaiyan [ 12/Aug/09 ]

Verified the changes made with trunk rev-12481.





[CDV-1116] Global instrumentation + Ehcache causing trouble Created: 04/Feb/09  Updated: 10/Apr/09  Resolved: 20/Feb/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1, Integration Modules
Affects Version/s: 2.7.3
Fix Version/s: 3.0.0

Type: Bug Priority: 2 Major
Reporter: Gary Keim Assignee: Abhishek Singh
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

People trying to use tim-ehcache that also instrument everything are running into difficulties:

http://forums.terracotta.org/forums/posts/list/1765.page

Workaround is to not instrument everything (remove .. rule).



 Comments   
Comment by Fiona OShea [ 20/Feb/09 ]

Cannot reproduce on supported platform.





[CDV-1114] Add clustered support for CopyOnWriteArray[Set,List] Created: 03/Feb/09  Updated: 14/Jan/10  Resolved: 23/Nov/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.2.0

Type: Bug Priority: 2 Major
Reporter: Alex Miller Assignee: Hung Huynh
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Roadmap
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 3.1
Fixed In Revision: trunk 3.1 14060

 Description   

Currently, CopyOnWriteArrayList and Set are non-portable. We investigated this a bit and it would not be hard to physically instrument these classes and provide at least base level support for them. This was requested to support tim-wicket for wicket 1.4. It would be nice if we could include this in the next 2.7.x if possible.

Some notes here (see comments):
http://tech.puredanger.com/2009/02/02/copyonwritearraylist-concurrency-fun/

I messed with this a little and was able to work around the permanent exclude and see something basically working. Some minimum necessities:

  • make the internal transient array field clustered
  • make existing synchronized methods write locked
  • make existing array() method (used for read-only methods) synchronized and read-locked
  • add to boot jar

Tim also suggested that some of our internal support volatiles may make this easier to implement.



 Comments   
Comment by Alex Miller [ 09/Jun/09 ]

Decided to instrument logically (although it was kind of a toss-up). Some reasons why:

  • lower memory footprint (but not a big deal)
  • there are different implementations of COWAL in jdk 1.5 / 1.6 - one uses synchronized and newer uses ReentrantLock

Things to do:

  • Add to BootJarTool.addInstrumentedJavaUtilCollection()
  • Add spec in same places as other logical lists
  • Remove from ExcludesConfiguration
  • Add config somewhere
  • Make syncronized methods read/write locked
  • Make lock instance a clustered lock instance in 1.6 - need applicator and a state object
    ListManagedObjectState also needs to contain a lock object
    Extend ListManagedObjectState and contain new field for the lock
  • Add tests to GenericListTest, GenericSetTest
Comment by Hung Huynh [ 21/Nov/09 ]

CopyOnWriteArrayList is now supported.

Working on CopyOnWriteArraySet

Comment by Kalai Kannaiyan [ 07/Dec/09 ]

Verified that the CopyOnWriteArrayList, CopyOnWriteArraySet classes are added in the boot jar with Terracotta 3.2.0-nightly, as of 20091207-081213 (Revision 14149 by cruise@su10mo4 from 3.2)





[CDV-1113] ConcurrentModificationException in TransactionBatchWriter Created: 03/Feb/09  Updated: 27/Jul/12  Resolved: 18/Mar/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: 1 Critical
Reporter: Alex Miller Assignee: Tim Eck
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 0 Down/unusable, no workaround available
Fix In Branch:
trunk, 2.7

 Description   

Seen in forum issue:
http://forums.terracotta.org/forums/posts/list/0/1756.page

java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at java.util.AbstractList.equals(AbstractList.java:505)
at com.tc.object.tx.TransactionBatchWriter$FoldingKey.canAcceptFold(TransactionBatchWriter.java:615)
at com.tc.object.tx.TransactionBatchWriter.getOrCreateBuffer(TransactionBatchWriter.java:191)
at com.tc.object.tx.TransactionBatchWriter.addTransaction(TransactionBatchWriter.java:278)
at com.tc.object.tx.TransactionSequencer.addTransactionToBatch(TransactionSequencer.java:86)
at com.tc.object.tx.TransactionSequencer.addTxnInternal(TransactionSequencer.java:116)
at com.tc.object.tx.TransactionSequencer.addTransaction(TransactionSequencer.java:95)
at com.tc.object.tx.RemoteTransactionManagerImpl.commit(RemoteTransactionManagerImpl.java:230)
at com.tc.object.tx.ClientTransactionManagerImpl.commitInternal(ClientTransactionManagerImpl.java:456)
at com.tc.object.tx.ClientTransactionManagerImpl.commit(ClientTransactionManagerImpl.java:421)
at com.tc.object.tx.ClientTransactionManagerImpl.commit(ClientTransactionManagerImpl.java:360)
at com.tc.object.bytecode.ManagerImpl.monitorExit(ManagerImpl.java:520)
at com.tc.object.bytecode.ManagerUtil.monitorExit(ManagerUtil.java:478)
at net.sf.ehcache.Cache.put(CacheTC.java:637)
at net.sf.ehcache.Cache.put(CacheTC.java:573)
at net.sf.ehcache.hibernate.EhCache.put(EhCache.java:130)
at org.hibernate.cache.ReadWriteCache.put(ReadWriteCache.java:159)
at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:156)
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:854)
at org.hibernate.loader.Loader.doQuery(Loader.java:729)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.loadCollection(Loader.java:1994)
at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:36)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:565)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:60)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1716)
at org.hibernate.collection.AbstractPersistentCollection.__tc_wrapped_initialize(AbstractPersistentCollection.java:344)
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java)
at org.hibernate.collection.AbstractPersistentCollection.__tc_wrapped_read(AbstractPersistentCollection.java:86)
at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java)
at org.hibernate.collection.PersistentBag.__tc_wrapped_iterator(PersistentBag.java:249)
at org.hibernate.collection.PersistentBag.iterator(PersistentBag.java)
at wildfire.model.event.Event.getRsvpResponseForContact(Event.java:517)



 Comments   
Comment by Tim Eck [ 18/Mar/09 ]

Closing this for now. I fixed the only path I (and others) could possibly see for this issue.





[CDV-1110] Unknown Solaris architecture os.arch = amd64 - solaris 10 x64 / amd64 Created: 02/Feb/09  Updated: 20/Apr/09  Resolved: 05/Mar/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: trunk-nightly
Fix Version/s: 3.0.0

Type: Bug Priority: 2 Major
Reporter: Mike Ruddy Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File VendorVmSignature.java    
Issue Links:
Related
is related to CDV-1124 Change behaviour of Terracotta when "... Resolved
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 3.0
Fixed In Revision: trunk r12009, 3.0 r 12010
Bug Found In Detail: Terracotta trunk-nightly, as of 20090201-170215 (Revision 11448 by cruise@su10mo5 from trunk)

 Description   

> /usr/java/bin/java -version
java version "1.5.0_16"
Java(TM) Platform, Standard Edition for Business (build 1.5.0_16-b02)
Java HotSpot(TM) Server VM (build 1.5.0_16-b02, mixed mode)

> /usr/java/bin/java -version -d64
java version "1.5.0_16"
Java(TM) Platform, Standard Edition for Business (build 1.5.0_16-b02)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_16-b02, mixed mode)

> cat /etc/release
Solaris 10 10/08 s10x_u6wos_07b X86

JBoss [EAP] 4.3.0.GA_CP03

with libsigar installed as mentioned in CDV-1109...

starting as a 32-bit process starts up and runs a small test application successfully.

adding "-d64" to the jboss app server's java command line to run as a 64-bit process fails with the following stack trace:

> ./jboss-eap-4.3/jboss-as/bin/tc-run.sh
Starting BootJarTool...
2009-02-02 15:10:30,920 INFO - Terracotta trunk-nightly, as of 20090201-170215 (Revision 11448 by cruise@su10mo5 from trunk)
2009-02-02 15:10:31,352 INFO - Configuration loaded from the file at '/home/mruddy/jboss-eap-4.3/jboss-as/server/tc-config.xml'.
=========================================================================

JBoss Bootstrap Environment

JBOSS_HOME: /home/mruddy/jboss-eap-4.3/jboss-as

JAVA: /usr/java/bin/java

JAVA_OPTS: -d64 -Dprogram.name=run.sh -server -Xbootclasspath/p:/home/mruddy/terracotta-trunk-nightly-rev11448/lib/dso-boot/dso-boot-hotspot_solaris-x86_150_16.jar -Dtc.install-root=/home/mruddy/terracotta-trunk-nightly-rev11448 -Dtc.config=/home/mruddy/jboss-eap-4.3/jboss-as/server/tc-config.xml

CLASSPATH: /home/mruddy/jboss-eap-4.3/jboss-as/bin/run.jar:/usr/java/lib/tools.jar

=========================================================================

2009-02-02 15:10:34,525 INFO - Terracotta trunk-nightly, as of 20090201-170215 (Revision 11448 by cruise@su10mo5 from trunk)
2009-02-02 15:10:34,943 INFO - Configuration loaded from the file at '/home/mruddy/jboss-eap-4.3/jboss-as/server/tc-config.xml'.
2009-02-02 15:10:35,035 INFO - Log file: '/home/mruddy/logs-192.168.103.73/terracotta-client.log'.
java.lang.reflect.InvocationTargetException
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 com.tc.object.bytecode.hook.impl.ClassProcessorHelper.createGlobalContext(ClassProcessorHelper.java:593)
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.initialize(ClassProcessorHelper.java:393)
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.defineClass0Pre(ClassProcessorHelper.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
Caused by: com.tc.config.schema.setup.ConfigurationSetupException:
*************************************************
Unknown Solaris architecture: ("os.arch" = amd64)
*************************************************

at com.tc.object.config.StandardDSOClientConfigHelperImpl.<init>(StandardDSOClientConfigHelperImpl.java:246)
at com.tc.object.config.StandardDSOClientConfigHelperImpl.<init>(StandardDSOClientConfigHelperImpl.java:198)
at com.tc.object.bytecode.hook.impl.DSOContextImpl.getGlobalConfigHelper(DSOContextImpl.java:208)
at com.tc.object.bytecode.hook.impl.DSOContextImpl.createGlobalContext(DSOContextImpl.java:65)
... 18 more
Caused by: com.tc.object.tools.UnsupportedVMException: Unknown Solaris architecture: ("os.arch" = amd64)
at com.tc.object.tools.BootJarSignature.<init>(BootJarSignature.java:23)
at com.tc.object.tools.BootJarSignature.getSignatureForThisVM(BootJarSignature.java:52)
at com.tc.object.tools.BootJar.getBootJarForReading(BootJar.java:82)
at com.tc.object.tools.BootJar.getDefaultBootJarForReading(BootJar.java:130)
at com.tc.object.config.StandardDSOClientConfigHelperImpl.doAutoconfig(StandardDSOClientConfigHelperImpl.java:634)
at com.tc.object.config.StandardDSOClientConfigHelperImpl.<init>(StandardDSOClientConfigHelperImpl.java:244)
... 21 more



 Comments   
Comment by Mike Ruddy [ 05/Feb/09 ]

using the new terracotta-2.7.3 source and distro, i got this working. i'll attach the source addition soon.
also, below's the contents of my tc-run.sh script. to run in 64-bit mode, it's important to put "-d64" into the JAVA_OPTS before calling the dso-env.sh so that the boot jar gets created and DSO_BOOT_JAR set correctly:
export JAVA_OPTS="$JAVA_OPTS -d64"
TC_INSTALL_DIR=/home/mruddy/terracotta-2.7.3
TC_CONFIG_PATH=/home/mruddy/jboss-eap-4.3/jboss-as/server/tc-config.xml
. $TC_INSTALL_DIR/bin/dso-env.sh -q
export JAVA_OPTS="$TC_JAVA_OPTS $JAVA_OPTS"
/home/mruddy/jboss-eap-4.3/jboss-as/bin/run.sh -b 0.0.0.0 -c axi01

Comment by Mike Ruddy [ 05/Feb/09 ]

diff of terracotta-2.7.3 version vs. the attached

21a21
> private static final String OS_SOLARIS_AMD64 = "solaris-amd64";
109c110,112
< } else

{ --- > }

else if ("amd64".equals(lowerCaseArch))

{ > return OS_SOLARIS_AMD64; > }

else {

Comment by Hung Huynh [ 05/Mar/09 ]

applied the attached patch

Comment by nadeem ghani [ 20/Apr/09 ]

Verified patch is in; don't have a AMD 64 bit machine to test





[CDV-1073] Write lock nested in read lock throws exception Created: 05/Dec/08  Updated: 17/Feb/09  Resolved: 16/Feb/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.7.1
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Eric Ellis Assignee: Eric Ellis
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

Since when does a write lock need to release it's read lock?

*******************************************************************************
Lock upgrade is not supported. The READ lock needs to be unlocked before a WRITE lock can be requested.

*******************************************************************************

at com.tc.object.lockmanager.impl.ClientLock.basicLock(ClientLock.java:149)
at com.tc.object.lockmanager.impl.ClientLock.lock(ClientLock.java:118)
at com.tc.object.lockmanager.impl.ClientLock.lock(ClientLock.java:108)
at com.tc.object.lockmanager.impl.ClientLockManagerImpl.lock(ClientLockManagerImpl.java:311)
at com.tc.object.lockmanager.impl.StripedClientLockManagerImpl.lock(StripedClientLockManagerImpl.java:119)
at com.tc.object.lockmanager.impl.ThreadLockManagerImpl.lock(ThreadLockManagerImpl.java:55)
at com.tc.object.tx.ClientTransactionManagerImpl.begin(ClientTransactionManagerImpl.java:187)
at com.tc.object.bytecode.ManagerImpl.begin(ManagerImpl.java:331)
at com.tc.object.bytecode.ManagerImpl.monitorEnter(ManagerImpl.java:501)
at com.tc.object.bytecode.ManagerUtil.monitorEnterWithContextInfo(ManagerUtil.java:469)
at net.jforum.entities.UserSession.setModeratorAssignments(UserSession.java)
at net.jforum.entities.UserSession.__tc_wrapped_isZDMModerator(UserSession.java:382)
at net.jforum.entities.UserSession.isZDMModerator(UserSession.java)
at net.jforum.security.PermissionControl.hasZDMModeratorOverride(PermissionControl.java:180)
at net.jforum.security.PermissionControl.__tc_wrapped_canAccess(PermissionControl.java:142)
at net.jforum.security.PermissionControl.canAccess(PermissionControl.java)
at net.jforum.repository.SecurityRepository.canAccess(SecurityRepository.java:214)
at net.jforum.repository.SecurityRepository.canAccess(SecurityRepository.java:180)
at net.jforum.entities.UserSession.__tc_wrapped_isModerator(UserSession.java:341)
at net.jforum.entities.UserSession.isModerator(UserSession.java)
at net.jforum.exceptions.ExceptionWriter.handleExceptionData(ExceptionWriter.java:98)
at net.jforum.JForum.handleException(JForum.java:303)
at net.jforum.JForum.service(JForum.java:222)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at net.jforum.util.legacy.clickstream.ClickstreamFilter.doFilter(ClickstreamFilter.java:59)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at com.tc.tomcat55.session.SessionValve55.tcInvoke(SessionValve55.java:63)
at com.tc.tomcat55.session.SessionValve55.invoke(SessionValve55.java:50)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:619)



 Comments   
Comment by Steve Harris [ 05/Dec/08 ]

Having upgradable locks leads to almost guaranteed deadlocks. Run through the scenarios in your head a bit and see if it is really what you want.

Comment by Fiona OShea [ 16/Feb/09 ]

Resolving as no feedback received to date





[CDV-1053] StandardDSOClientConfigHelperImpl.addClassResource() relies on URL methods that can block Created: 13/Nov/08  Updated: 10/Apr/09  Resolved: 05/Mar/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.0.0

Type: Bug Priority: 3 Minor
Reporter: Alex Miller Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 3.0
Fixed In Revision: trunk r12013, 3.0 r12014

 Description   

addClassResource() uses URL.equals() to compare URLs but this method actually does domain name resolution and blocks, so is a bad thing to rely on. See: http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html

On severity, I don't see any obvious place where this method is actually used, so might be able to just remove it.



 Comments   
Comment by Tim Eck [ 13/Nov/08 ]

That method I think might be used from TIMs that do class exporting. I think only jar or file type URLs would really be passed here in reality, but it would be good to clean up the interface to make the issue impossible

Comment by Alex Miller [ 05/Mar/09 ]

Need to check whether this is used by any tims in the forge before removing. That's unlikely but possible...if it is being used, please update this jira with that info so we can reassess.

Comment by Hung Huynh [ 05/Mar/09 ]

This method is used in TerracottaConfiguratorModule

protected final void addExportedBundleClass(final Bundle bundle, final String classname,
final boolean targetSystemLoaderOnly) {
String url = getBundleJarUrl(bundle) + ByteCodeUtil.classNameToFileName(classname);
try

{ configHelper.addClassResource(classname, new URL(url), targetSystemLoaderOnly); }

catch (MalformedURLException e)

{ throw new RuntimeException("Unexpected error while constructing the URL '" + url + "'", e); }

}

which is under module-base project.

Are we still trying to delete it then? or trying to work around the URL.equals() call by converting the URL to String then compare that?

Comment by Hung Huynh [ 05/Mar/09 ]

converted URL to String before doing the comparision

if ((prev != null) && (!prev.getResource().toString().equals(resource.toString())))

{ // we want to know if modules more than one module is trying to export the same class throw new AssertionError("Attempting to replace mapping for " + className + ", from " + prev + " to " + resource); }




[CDV-1052] ArrayManager does not take into account negative hash codes in calculations Created: 13/Nov/08  Updated: 16/Dec/08  Resolved: 17/Nov/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.7.2

Type: Bug Priority: 2 Major
Reporter: Alex Miller Assignee: Tim Eck
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 2.7

 Description   

There are two places in ArrayManager (register() and getObject()) where the array object hash code maps into an array of maps, but this could does not take into consideration negative hash code values for arrays.

Also, I think I'd argue that the object->hash bucket logic should be moved into a common helper method.

Found with FindBugs...






[CDV-1045] wrong referring field name printed in TCNonPortableObjectError Created: 11/Nov/08  Updated: 16/Dec/08  Resolved: 17/Nov/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.7.1
Fix Version/s: 2.7.2

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: nadeem ghani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive inner.zip     Text File output.txt    
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 2.7

 Description   

Use the attached program. The parent type (test.Foo$Parent) is not included but a non-static inner class of it is

The exception message makes reference to this non-existent field name:

Referring field : test.Foo$Parent$Inner.test.Foo$Parent$Inner.this$1



 Comments   
Comment by nadeem ghani [ 09/Dec/08 ]

verified on 2.7.2 build 1

ref is now to

Referring class : test.Foo$Parent$Inner
Referring field : test.Foo$Parent$Inner.this$0
Thread : main
JVM ID : VM(1)
Non-included class: test.Foo$Parent





[CDV-959] TCAssertionError if non-existent path given for stats dir Created: 22/Oct/08  Updated: 07/Nov/08  Resolved: 29/Oct/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1, DSO:L2
Affects Version/s: 2.7.0
Fix Version/s: 2.7.1

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: nadeem ghani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File tc-config-prod.xml    
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Fixed In Revision: 10705
Bug Type:
Implementation Error

 Description   

Attached is tc-config.xml used. Started server with "start-tc-server.sh -f tc-config-prod.xml -n lasstc1"

com.tc.util.TCAssertionError: dbDir '/export1/terracotta-data/statistics' doesn't exist
at com.tc.util.Assert.failure(Assert.java:60)
at com.tc.util.Assert.fail(Assert.java:402)
at com.tc.statistics.database.impl.H2StatisticsDatabase.<init>(H2StatisticsDatabase.java:28)
at com.tc.statistics.store.h2.H2StatisticsStoreImpl.<init>(H2StatisticsStoreImpl.java:99)
at com.tc.statistics.StatisticsGathererSubSystem.setup(StatisticsGathererSubSystem.java:48)
at com.tc.server.TCServerImpl.<init>(TCServerImpl.java:120)
at com.tc.server.TCServerImpl.<init>(TCServerImpl.java:110)
at com.tc.server.StandardServerFactory.createServer(StandardServerFactory.java:12)
at com.tc.server.TCServerMain.main(TCServerMain.java:27)

The error seems to happen both if the path doesn't exist and if the directory cannot be created due to permission problems



 Comments   
Comment by Alex Miller [ 28/Oct/08 ]

What do we expect to happen in this case?

Seems like the options are
1) create the dir
2) warn nicely (more nicely than assertion error)
3) refuse to start

I'd be happy with at least 2 and maybe 1 with a fallback to 2.

Comment by Walter Harley [ 29/Oct/08 ]

I have a nice fix for the failure to create the directory.

Unfortunately, failing gently in this spot makes us fail really ugly a bit later on: although StatisticsGathererSubSystem.setup() returns a boolean, TCServerImpl.<init>() does not check it. (FWIW, the same code and same bug occur later on in StatisticsAgentSubsystemImpl, if we make it that far.)

The easy way out is #3, with a better error message. But I'll try to figure out how to make the initialization failure survivable, that is, how to disable statistics and keep running. It seems like that's the intention of the code but I don't see how it could have been working.

Comment by Walter Harley [ 29/Oct/08 ]

Fixed in 2.7.1 BRANCH, by making server exit gracefully, as below:

[~/dev/branches/2.7/code/base/build/dist/terracotta-2.7.1-snapshot/bin]
> ./start-tc-server.sh -f ~/test/tc-config-prod.xml -n lasstc1
2008-10-29 12:53:38,216 INFO - Terracotta 2.7.1-SNAPSHOT, as of 20081029-121056 (Revision 10697 by wharley@Terracotta-Mac-3.local from 2.7)
2008-10-29 12:53:38,615 INFO - Configuration loaded from the file at '/Users/wharley/test/tc-config-prod.xml'.
2008-10-29 12:53:38,724 INFO - Log file: '/tmp/var/log/terracotta/terracotta-server.log'.
2008-10-29 12:53:38,761 ERROR -
**************************************************************************************
Unable to create the directory '/export1/terracotta-data/statistics' for the statistics buffer.
This directory is specified in the Terracotta configuration. Please ensure that the
Terracotta client has read and write privileges to this directory and its parent directories.
**************************************************************************************

[~/dev/branches/2.7/code/base/build/dist/terracotta-2.7.1-snapshot/bin]
>

A better fix would be to replace the stats subsystem with a dummy, so that execution can continue. It seems as though this was the intent of the original code but I don't think it was completed. I will open a separate Jira for that.

Leaving this bug open until I've merged the change into TRUNK.

Comment by Walter Harley [ 29/Oct/08 ]

Fixed in trunk with 10705.

Comment by Abhishek Singh [ 31/Oct/08 ]

Was trying to start examinator and got the following:

[WARNING] [cargo0] **************************************************************************************
[WARNING] [cargo0] Unable to create the directory '/Users/asingh/workspace/examinator/target/terracotta/clients/statistics/cargo0' for the statistics buffer.
[WARNING] [cargo0] The CVT system will not be active for this node. To fix this, ensure that the Terracotta
[WARNING] [cargo0] client has read and write privileges to this directory and its parent directories.
[WARNING] [cargo0] **************************************************************************************

The terracotta client has write access to '/Users/asingh/workspace/examinator/target/terracotta/clients/statistics/cargo0'
Seems like we are giving out a wrong warning message.
Maybe we can try doing something similar to "mkdir -p"

Comment by Walter Harley [ 31/Oct/08 ]

Interesting. So this is happening on the client, not the server, is that correct? That particular error message comes from StatisticsAgentSubsystemImpl, in dso-statistics. The server fails earlier, in StatisticsGathererSubSystem. The same code is being called, though, they're just different error messages.

We do call mkdirs(), which is the Java version of mkdir -p. Are you certain about the permissions being right? (E.g., it's a directory, not a normal file?)

Comment by Tim Eck [ 31/Oct/08 ]

Not sure if you think it is overkill, but we could in theory try to test all of these possible conditions and give more specific error messages.

Comment by Walter Harley [ 31/Oct/08 ]

I am not sure I trust the consistency of the java.io results on different platforms well enough to make that worthwhile.

Comment by nadeem ghani [ 07/Nov/08 ]

Nice error msg:

macbook ~/__releases/07nov/terracotta-2.7.1-ee > bin/start-tc-server.sh -f tools/sessions/configurator-sandbox/tomcat5.5/tc-config.xml
2008-11-07 12:07:30,574 INFO - Terracotta Enterprise 2.7.1, as of 20081106-141116 (Revision 2874-10770 by cruise@su10mo5 from 2.7)
2008-11-07 12:07:31,192 INFO - Configuration loaded from the file at '/Users/nghani/__releases/07nov/terracotta-2.7.1-ee/tools/sessions/configurator-sandbox/tomcat5.5/tc-config.xml'.
2008-11-07 12:07:31,232 INFO - Log file: '/tmp/logs/server-logs/terracotta-server.log'.
2008-11-07 12:07:31,393 ERROR -
**************************************************************************************
Unable to create the directory '/Users/noone/stats/server-stats' for the statistics buffer.
This directory is specified in the Terracotta configuration. Please ensure that the
Terracotta client has read and write privileges to this directory and its parent directories.
**************************************************************************************





[CDV-893] interruptible locking doesn't work Created: 11/Sep/08  Updated: 10/Apr/09  Resolved: 07/Jan/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.0.0

Type: Bug Priority: 2 Major
Reporter: Catalin Cirstoiu Assignee: Chris Dennis
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File InterruptibleLocking2.java     XML File tc-config.xml    
Issue Links:
Related
is related to CDV-892 ReentrantLock DSO cannot be interrupted Closed
Severity: 1 Down/unusable, workaround available
Fix In Branch:
trunk
Fixed In Revision: 11221
Bug Found In Detail: Terracotta 2.7.0-nightly-rev10012, as of 20080909-160946 (Revision 10012 by cruise@rh4mo0 from 2.7)

 Description   

Doing thread.interrupt() on a thread trying to acquire a shared lock with lockInterruptibly() doesn't release the blocked thread as it happens in a non-clustered environment. This happens both for ReentrantLock and ReentrantReadWriteLock.

The workaround consists in using a custom made interruptible lock based on two reentrant locks and a condition variable (await-ing on a condition is interrupted on thread.interrupt()).



 Comments   
Comment by Chris Dennis [ 18/Dec/08 ]

The fix for ReentrantLock is now in place (CDV-892). A fix for RRWL is coded (using the same solution as is now used for ReentrantLock). Some slightly more rigorous tests are required before the RRWL fix is checked-in however.

Comment by Chris Dennis [ 07/Jan/09 ]

ReentrantLock fix now extended to cover RRWL. Accompanying test ensures the semantics of RRWL still hold true. The ReentrantLock tests will ensure the robustness of the common code.

Comment by nadeem ghani [ 12/Mar/09 ]

Test with checkin is running in monkeys





[CDV-863] Using CHM with spring web-flow gives NPE Created: 27/Aug/08  Updated: 12/Feb/13  Resolved: 11/Jun/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.7.0-stable0
Fix Version/s: 3.1.0

Type: Bug Priority: 3 Minor
Reporter: Abhishek Singh Assignee: Kalai Kannaiyan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File sample-webapp.tar    
Issue Links:
Related
relates to CDV-244 Serialization of shared objects fails... Closed
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 2.7
Bug Found In Detail: Terracotta 2.7.0-nightly-rev9879, as of 20080826-160841 (Revision 9879 by cruise@rh4mo0 from 2.7)

 Description   

Using spring web-flow, if we use CHM in a domain object which gets stored as one of the scope variables in web-flow gives NPE.

java.lang.NullPointerException
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock._RWL_tc_lock(ReentrantReadWriteLock/java:637)
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock/java)
java.util.concurrent.ConcurrentHashMap$Segment.lock(ConcurrentHashMap.java)
java.util.concurrent.ConcurrentHashMap$Segment.put(ConcurrentHashMap.java:408)
java.util.concurrent.ConcurrentHashMap.put(Unknown Source)
java.util.concurrent.ConcurrentHashMap.readObject(Unknown Source)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
java.util.HashMap.readObject(HashMap.java:1067)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:479)
org.springframework.webflow.core.collection.LocalAttributeMap.readObject(LocalAttributeMap.java:331)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
java.util.HashMap.readObject(HashMap.java:1067)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:479)
org.springframework.webflow.core.collection.LocalAttributeMap.readObject(LocalAttributeMap.java:331)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
org.springframework.webflow.engine.impl.FlowSessionImpl.readExternal(FlowSessionImpl.java:147)
java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
java.util.LinkedList.readObject(LinkedList.java:776)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
org.springframework.webflow.engine.impl.FlowExecutionImpl.readExternal(FlowExecutionImpl.java:514)
java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
org.springframework.webflow.execution.repository.snapshot.SerializedFlowExecutionSnapshot.deserialize(SerializedFlowExecutionSnapshot.java:193)
org.springframework.webflow.execution.repository.snapshot.SerializedFlowExecutionSnapshot.unmarshal(SerializedFlowExecutionSnapshot.java:98)
org.springframework.webflow.execution.repository.snapshot.SerializedFlowExecutionSnapshotFactory.restoreExecution(SerializedFlowExecutionSnapshotFactory.java:80)
org.springframework.webflow.execution.repository.snapshot.AbstractSnapshottingFlowExecutionRepository.restoreFlowExecution(AbstractSnapshottingFlowExecutionRepository.java:89)
org.springframework.webflow.execution.repository.impl.DefaultFlowExecutionRepository.getFlowExecution(DefaultFlowExecutionRepository.java:104)
org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:152)
org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:173)
org.springframework.webflow.mvc.servlet.FlowController.handleRequest(FlowController.java:172)
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

Have attached a sample webapp which reproduces this problem
How to reproduce:
Untar attached sample-webapp.tar in a dir
cd sample-webapp
mvn tc:run

Point your browser to http://localhost:8080/sample-webapp/welcome.do
Click "Increment visit counter". Then Click "back to index"

Point your browser to the other webserver, http://localhost:8081/sample-webapp/welcome.do
Click "Increment visit counter"
Now clicking "back to index" will give the above NPE.



 Comments   
Comment by Alex Miller [ 12/Sep/08 ]

Probably fixed by this issue but need to double-check.

Comment by Abhishek Singh [ 11/Jun/09 ]

Fixed.

Not able to reproduce problem anymore with attached example and way to reproduce. Most probably fixed with CDV-244/CDV-907

Comment by Kalai Kannaiyan [ 07/Aug/09 ]

Tested with Terracotta 2.7.0, as of 20080925-140928 (Revision 10251 by cruise@rh4mo0 from 2.7), it is working fine.

Steps:
Untar attached sample-webapp.tar in a dir
cd sample-webapp
mvn tc:run

Point your browser to http://localhost:8080/sample-webapp/welcome.do
Click "Increment visit counter". Then Click "back to index"

Point your browser to the other webserver, http://localhost:8081/sample-webapp/welcome.do
Click "Increment visit counter"
Now clicking "back to index"

Actual: Goes back to welcome.do page





[CDV-835] ModulesLoader swallows exception Created: 08/Aug/08  Updated: 12/May/09  Resolved: 03/Apr/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.0.0

Type: Bug Priority: 2 Major
Reporter: Anonymous Assignee: nadeem ghani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 2.7
Fixed In Revision: trunk (11719) , 2.7 (11720)
Bug Type:
Implementation Error

 Description   

When an exception occurs while ModulesLoader is loading a TIM into the L1, the details of the exception are discarded and only a summary message is printed to the log: "BundleActivator start failed" for instance.

This makes it very difficult to debug problems with module loading. The full details of the exception should be logged so that problems loading modules can be debugged by reading the log output.

NOTE: Be sure to test whether a call to a regular (ie. non-console) logger will have any effect here. It is possible (but I don't know either way) that the log file has not been opened yet and thus logging to a regular logger and calling System.exit() afterwards will lose the log statement.



 Comments   
Comment by Alex Miller [ 08/Aug/08 ]

Need to fix this as it has (multiple times) made it difficult and time-consuming to debug monkey issues.

Comment by jvoegele [ 10/Dec/08 ]

I think this has been fixed. Can someone give a definitive statement?

Comment by Hung Huynh [ 17/Dec/08 ]

This is the same as DEV-2201, need to be fixed.

Comment by nadeem ghani [ 27/Mar/09 ]

if a tim is missing, we end up printing a duplicate message followed by a stacktrace

  • edit samples/pojo/chatter/tc-config.xml and add a <modules> section for tim-apache-struts
  • start-tc-server.sh -f samples/pojo/chatter/tc-config.xml
  • samples/pojo/chatter/run.sh

> Starting BootJarTool...
2009-03-27 13:33:51,302 INFO - Terracotta Enterprise 3.0.0-nightly, as of 20090327-080324 (Revision 3807-12356 by cruise@su10mo5 from 3.0)
2009-03-27 13:33:51,761 INFO - Configuration loaded from the file at '/Users/nghani/__releases/mar23/terracotta-3.0.0-nightly-ee-rev12356/samples/pojo/chatter/tc-config.xml'.
2009-03-27 13:33:51,991 INFO - Product key found at: /Users/nghani/__releases/mar23/terracotta-3.0.0-nightly-ee-rev12356/product.key
2009-03-27 13:33:52,107 INFO -
---------------- Terracotta product key --------------
License type = Commercial
License number = 1
Licensee = Terracotta Test
Product = FX
Max clients = 100
Capabilities = roots, sessions, TOC, server striping
------------------------------------------------------
2009-03-27 13:33:52,387 FATAL - BootJarTool: Unable to resolve TIM file for tim-apache-struts-1.1 version 1.3.0-SNAPSHOT (group-id: org.terracotta.modules)

Attempted to resolve the TIM using the following descriptors:

groupId: org.terracotta.modules
name : tim-apache-struts-1.1
version: 1.3.0-SNAPSHOT

Expected the TIM's filename to be:

tim-apache-struts-1.1-1.3.0-SNAPSHOT.jar

Expected these attributes to be in the manifest:

Bundle-SymbolicName: org.terracotta.modules.tim-apache-struts-1.1
Bundle-Version : 1.3.0.SNAPSHOT

Searched using the following repositories:

+ /Users/nghani/__releases/mar23/terracotta-3.0.0-nightly-ee-rev12356/modules

Tried to resolve the jar file using the following paths:

+ /Users/nghani/__releases/mar23/terracotta-3.0.0-nightly-ee-rev12356/modules/org/terracotta/modules/tim-apache-struts-1.1/1.3.0-SNAPSHOT/tim-apache-struts-1.1-1.3.0-SNAPSHOT.jar
+ /Users/nghani/__releases/mar23/terracotta-3.0.0-nightly-ee-rev12356/modules/tim-apache-struts-1.1-1.3.0-SNAPSHOT.jar

If the jar file exists and is in one of the paths listed above, make sure that the Bundle-SymbolicName and
Bundle-Version attribute in its manifest matches the ones that the resolver expects.

If you do not have this particular TIM or any of its dependencies installed, try using the tim-get tool's
'install' command:

$ tim-get.sh install tim-apache-struts-1.1 1.3.0-SNAPSHOT org.terracotta.modules

You can also use the tool's 'list' command to see if it's actually available:

$ tim-get.sh list tim-apache-struts-1.1 # list anything that has 'tim-apache-struts-1.1' in it's name
$ tim-get.sh list # or, list everything that is available

For more information on how to use the tim-get tool, invoke:

$ tim-get.sh help
2009-03-27 13:33:52,388 FATAL - Exception thrown
org.osgi.framework.BundleException: Unable to resolve TIM file for tim-apache-struts-1.1 version 1.3.0-SNAPSHOT (group-id: org.terracotta.modules)

Attempted to resolve the TIM using the following descriptors:

groupId: org.terracotta.modules
name : tim-apache-struts-1.1
version: 1.3.0-SNAPSHOT

Expected the TIM's filename to be:

tim-apache-struts-1.1-1.3.0-SNAPSHOT.jar

Expected these attributes to be in the manifest:

Bundle-SymbolicName: org.terracotta.modules.tim-apache-struts-1.1
Bundle-Version : 1.3.0.SNAPSHOT

Searched using the following repositories:

+ /Users/nghani/__releases/mar23/terracotta-3.0.0-nightly-ee-rev12356/modules

Tried to resolve the jar file using the following paths:

+ /Users/nghani/__releases/mar23/terracotta-3.0.0-nightly-ee-rev12356/modules/org/terracotta/modules/tim-apache-struts-1.1/1.3.0-SNAPSHOT/tim-apache-struts-1.1-1.3.0-SNAPSHOT.jar
+ /Users/nghani/__releases/mar23/terracotta-3.0.0-nightly-ee-rev12356/modules/tim-apache-struts-1.1-1.3.0-SNAPSHOT.jar

If the jar file exists and is in one of the paths listed above, make sure that the Bundle-SymbolicName and
Bundle-Version attribute in its manifest matches the ones that the resolver expects.

If you do not have this particular TIM or any of its dependencies installed, try using the tim-get tool's
'install' command:

$ tim-get.sh install tim-apache-struts-1.1 1.3.0-SNAPSHOT org.terracotta.modules

You can also use the tool's 'list' command to see if it's actually available:

$ tim-get.sh list tim-apache-struts-1.1 # list anything that has 'tim-apache-struts-1.1' in it's name
$ tim-get.sh list # or, list everything that is available

For more information on how to use the tim-get tool, invoke:

$ tim-get.sh help
at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:110)
at com.tc.object.tools.BootJarTool.loadModules(BootJarTool.java:258)
at com.tc.object.tools.BootJarTool.<init>(BootJarTool.java:242)
at com.tc.object.tools.BootJarTool.main(BootJarTool.java:2651)

Comment by Fiona OShea [ 27/Mar/09 ]

Is this a new issue? with the original issue resolved?
If so please add a new Jira and close original.
thanks





[CDV-810] Custom protocol handlers make the L1 initialization fail Created: 17/Jul/08  Updated: 20/Oct/08  Resolved: 17/Jul/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.7.0-stable0

Type: Bug Priority: 2 Major
Reporter: Geert Bevin Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 0 Down/unusable, no workaround available
Fix In Branch:
trunk
Fixed In Revision: 9277

 Description   

As per http://forums.terracotta.org/forums/posts/list/0/1237.page

Just executing this:
JAVA_OPTS="-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol" dso-java.sh tutorial.HelloWorld

Results in:

2008-07-17 09:59:24,051 INFO - Terracotta 2.7.0-SNAPSHOT, as of 20080717-080730 (Revision 9274 by gbevin@oak.local from trunk)
2008-07-17 09:59:24,582 INFO - Configuration loaded from the file at '/Users/gbevin/Downloads/demos/helloworld/tc-config.xml'.
java.lang.NullPointerException
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.registerStandardLoaders(ClassProcessorHelper.java:467)
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.init(ClassProcessorHelper.java:414)
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.systemLoaderInitialized(ClassProcessorHelper.java:795)
at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1382)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1341)
at java.net.URL.getURLStreamHandler(URL.java:1139)
at java.net.URL.<init>(URL.java:393)
at java.net.URL.<init>(URL.java:283)
at java.net.URL.<init>(URL.java:306)
at sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:245)
at sun.misc.Launcher.getFileURL(Launcher.java:400)
at sun.misc.Launcher$ExtClassLoader.getExtURLs(Launcher.java:177)
at sun.misc.Launcher$ExtClassLoader.<init>(Launcher.java:149)
at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:133)
at java.security.AccessController.doPrivileged(Native Method)
at sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Launcher.java:130)
at sun.misc.Launcher.<init>(Launcher.java:51)
at sun.misc.Launcher.<clinit>(Launcher.java:39)
at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1359)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1341)
Error occurred during initialization of VM
java.lang.AssertionError: already set
Abort trap



 Comments   
Comment by Steve Harris [ 17/Jul/08 ]

on the 2.6 question, how much work is it. How dangerous is the change?

Comment by Geert Bevin [ 17/Jul/08 ]

Work is trivial, as far as I can see it's not dangerous since it just adds another level of protection before initializing the TC client. Ie. it ensures that the system classloader actually has a values before using it for initialization. While is is bound to the actual bytecode of the ClassLoader class, but this was already the case before so I don't expect any problems.

Comment by Hung Huynh [ 20/Oct/08 ]

tested with ~/builds/terracotta-trunk-nightly-rev10506/samples/pojo/chatter

works fine.

java.exe 1396 c:\jdk\hotspot1.6.0_07\bin\java.exe -Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol -Xbootclasspath/p:c:\terracotta\builds\terracotta-trunk-nightly-rev10506\lib\dso-boot\dso-boot-hotspot_win32_160_07.jar -Dtc.install-root=c:\terracotta\builds\terracotta-trunk-nightly-rev10506\ -Dtc.config=tc-config.xml -Djava.awt.Window.locationByPlatform=true -cp ./classes demo.chatter.Main





[CDV-797] LockNotPendingError: Attempt to reject a lock request that isn't pending Created: 25/Jun/08  Updated: 24/Sep/08  Resolved: 10/Jul/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.6.1
Fix Version/s: 2.6.4

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: nadeem ghani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to CDV-649 .LockNotPendingError: Attempt to reje... Closed
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 2.6

 Description   

MultiNodeInvalidatorTest fails fairly regularly because the L1s exit with this assertion error

com.tc.object.lockmanager.api.LockNotPendingError: Attempt to reject a lock request that isn't pending: lockID: LockID(D540816D200CA69D05EEA7C8750978970808F6A9D90AA0B12625), level: 2, requesterID: ThreadID=[7], waitLocksByRequesterID: {}
at com.tc.object.lockmanager.impl.ClientLock.cannotAwardLock(ClientLock.java:466)
at com.tc.object.lockmanager.impl.ClientLockManagerImpl.cannotAwardLock(ClientLockManagerImpl.java:483)
at com.tc.object.handler.LockResponseHandler.handleEvent(LockResponseHandler.java:43)
at com.tc.async.impl.StageImpl$WorkerThread.run(StageImpl.java:142)

I'm almost certain this problem has something to do with the tryLock() APIs. TC sessions makes pretty heavy use of this API, and anyone who uses tryLock() on ReentrantLock and/or ReentrantReadWriteLock() could be affected by this bug

this is probably the same thing as CDV-649



 Comments   
Comment by Tim Eck [ 10/Jul/08 ]

this should be resolved with Geert's fixes for tryLock(). Test is re-enabled

Comment by nadeem ghani [ 15/Aug/08 ]

closing because this test is passing now





[CDV-771] synchronization in StandardDSOClientConfigHelperImpl causing deadlock Created: 30/May/08  Updated: 01/Jul/08  Due: 13/Jun/08  Resolved: 02/Jun/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.6.0
Fix Version/s: 2.6.2

Type: Bug Priority: 2 Major
Reporter: Scott Bale Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 2 Feature failure (but system usable), no workaround available
Fix In Branch:
trunk, 2.6
Fixed In Revision: 8706, 8713 (trunk) and 8726 (2.6 branch)
Bug Type:
Race Condition
Bug Found In Detail: 2.6.0

 Description   

From forum thread http://forums.terracotta.org/forums/posts/list/1107.page

synchronization in StandardDSOClientConfigHelperImpl.getInstrumentationDescriptorFor() method can lead to deadlocks, because the call to InstrumentationDescriptor.matches(..) within the synchronized block triggers many more method calls which can contend for locks. In the case of this forum post, the other lock belonged to a ClassLoader instance that was already held by another thread, which was trying to acquire the lock for the LinkedList of InstrumentationDescriptors.

It would be nice to go to a copy-on-write data structure to hold those InstrumentationDescriptors, so synchronization wasn't necessary on the read operations. If nothing else, you could always copy-on-read within the synchronized block, then iterate and check after relinquishing the lock. Tim points out that there may be additional more complicated synchronization and atomicity requirements around the addIncludeAndLockIfRequired() method (but we could use a different lock there).



 Comments   
Comment by Alex Miller [ 02/Jun/08 ]

Assigning to Scott as he has been hashing through some options with Tim.

Comment by Scott Bale [ 02/Jun/08 ]

Switched to using a CopyOnWriteArrayList for "instrumentationDescriptors". This should prevent the deadlock which the forum user experienced, which happened when trying to read (iterate) this List.

Comment by Fiona OShea [ 02/Jun/08 ]

This fix will be available in trunk-nightly builds after revision 8706

Comment by Scott Bale [ 03/Jun/08 ]

Added revision 8713 to this JIRA, which was additional correction to synchronization within the same class as was modified in 8706. Merged to 2.6 branch (revision 8726).





[CDV-731] RuntimeLoggerImpl is too strict in trimming the stack trace on lock acquires producing spurious warnings Created: 15/Apr/08  Updated: 04/Aug/08  Resolved: 24/Jul/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.6-stable0
Fix Version/s: 2.7.0-stable0

Type: Bug Priority: 2 Major
Reporter: Alex Miller Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to CDV-815 Remove <caller> element in <runtime-o... Open
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Fixed In Revision: 9472

 Description   

From looking at some customer logs on the forum (http://forums.terracotta.org/forums/posts/list/910.page), there are some warnings like this:
tc_client_01.log:2008-04-13 16:55:04,251 [CacheInvalidator -
org.hibernate.cache.UpdateTimestampsCache invalidation thread0] WARN
com.tc.object.logging.RuntimeLoggerImpl - could not find proper stack
frame:
<<com.tc.object.logging.RuntimeLoggerImpl.getTrimmedStack(RuntimeLoggerImpl.java:215)>>,
<<com.tc.object.logging.RuntimeLoggerImpl.appendCall(RuntimeLoggerImpl.java:113)>>,
<<com.tc.object.logging.RuntimeLoggerImpl.namedLockAcquired(RuntimeLoggerImpl.java:93)>>,
<<com.tc.object.logging.RuntimeLoggerImpl.lockAcquired(RuntimeLoggerImpl.java:86)>>,
<<com.tc.object.bytecode.ManagerImpl.begin(ManagerImpl.java:323)>>,
<<com.tc.object.bytecode.ManagerImpl.beginLock(ManagerImpl.java:298)>>,
<<com.tcclient.cache.Lock.writeLock(Lock.java:53)>>,
<<com.tcclient.cache.CacheEntryInvalidator.run(CacheEntryInvalidator.java:87)>>,
<<com.tcclient.cache.CacheInvalidationTimer$EvictionRunner.run(CacheInvalidationTimer.java:53)>>,
<<java.lang.Thread.run(Thread.java:619)>>

The code in RuntimeLoggerImpl.getTrimmedStack() is attempting to prune
all of the stack below the call from
"com.tc.object.bytecode.ManagerUtil". In the stack above
com.tcclient.cache.Lock.writeLock() is calling ManagerImpl directly instead of
going through ManagerUtil. I suspect that's due to some refactoring I
did to make this more testable a while back (switching the call to the
static method in ManagerUtil to a call to an injected Manager instance).

We need to either stop trimming the stack at all, or be more flexible with when we filter, or change the ehcache code back to go through ManagerUtil.



 Comments   
Comment by Alex Miller [ 15/Jul/08 ]

Should be more flexible with what we filter here.

Comment by Tim Eck [ 15/Jul/08 ]

I'd actually vote for removing the "trimmed" stack thing completely. Makes this easy to solve

Comment by Abhishek Singh [ 22/Jul/08 ]

Fixed in trunk rev-9424.

Comment by Abhishek Singh [ 24/Jul/08 ]

Made <caller> element in <runtime-output-options> deprecated.

trunk rev-9472





[CDV-633] Client LocksGC prevents Lock activity during its execution Created: 28/Feb/08  Updated: 25/Apr/08  Resolved: 15/Apr/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.5.2
Fix Version/s: 2.6-stable1

Type: Bug Priority: 1 Critical
Reporter: Anonymous Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 2.6

 Description   

Refer to forum thread

http://forums.terracotta.org/forums/posts/list/812.page

This guys is touching many distributed locks in his JVM. When LockGC run, it locks ClientLockManagerImpl, which prevent grant/release of the lock until LockGC completes. I his case LockGc takes 5 seconds to execute (see the attached thread dump in the posts) and lock activities are halted during that time, resulting into the transaction rate drop to zero during LockGC.



 Comments   
Comment by Saravanan Subbiah [ 09/Apr/08 ]

In progress.





[CDV-623] Support unique, repeatable identifiers for each node Created: 18/Feb/08  Updated: 17/Feb/09  Resolved: 11/Apr/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: 2 Major
Reporter: Geert Bevin Assignee: Product Management
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
has a dependency CDV-671 Stats file should be auto selected Open
Related
relates to CDV-677 standardize system properties and dat... Resolved
relates to CDV-727 Discuss best way to avoid stat direct... Resolved
Fix In Branch:
trunk

 Description   

Currently, there is no way to uniquely identify individual nodes in a repeatable fashion.

This for example prevents several nodes on the same machine to easily have different log directories without resorting to using different users or JVM properties. The causes the default tc.config.xml to not support log files by default for more than one L1 node on the same machine. The same is true for CVT agents buffer databases.



 Comments   
Comment by Geert Bevin [ 07/Apr/08 ]

Suggestion by Hung:
I was wondering if we could use ClientID (assinged to each client by DSO server) as a unique folder name for the clients' logs. If users specify the paths in tc-config.xml then we'll use those. If not, dump all logs and statistics files to workingdir/terracotta/$ClientID

Observation about that from me:
Using the client ID is more difficult than it sounds since it only gets assigned when the actual connection between L1 and L2 is established. This currently happens after all the startup logic of L1. It might need quite a large amount of shuffling around and refactoring.

Comment by Fiona OShea [ 11/Apr/08 ]

we are not sure this is the right approach. We will evaluate and enter new jiras when we figure out the best approach





[CDV-521] HibernateUtil Dependency on hibernate.cf.xml creates problem in Spring application Created: 14/Nov/07  Updated: 10/Apr/09  Resolved: 20/Oct/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.4.8
Fix Version/s: 3.0.0

Type: New Feature Priority: 2 Major
Reporter: Anonymous Assignee: Unassigned
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Fix In Branch:
trunk

 Description   

Refer to post http://forums.terracotta.org/forums/posts/list/568.page

HibernateUtil is written with assumption that hibernate.cfg.xml will be always available. That may not be the case in applications based on Spring, where hibernate configuration is defined via spring bean. It might fail even in those setup where SessionFactory is configured in a NamingService, a typical scenario in J2EE based applications.

Possible solution could be is to ask application developer provide an implementation of some interface that returns reference to session factory and if not configured use default implementation of HibernateUtil.



 Comments   
Comment by Russell Pitre [ 04/Feb/08 ]

Is there anymore information if there will be fix for this issue coming out sooner than later? Because of this issue, we have had to turn off clustering and run in a single-node environmnet. One thing i have noticed with this issue is that it appears to surface when one of the tc clients is restarted and joins rejoins the cluster.

Comment by njain [ 28/Apr/08 ]

This is fixed for hibernate 3.1.2 and 3.2.5 in tim-hibernate inside forge.

Comment by jvoegele [ 20/Oct/08 ]

This is no longer an issue.





[CDV-478] NPE building boot jar if java.lang.Object is included in <additional-boot-jar-classes> Created: 22/Oct/07  Updated: 27/Jul/12  Resolved: 14/Apr/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1, Eclipse Plugin
Affects Version/s: 2.4.4
Fix Version/s: 2.6-stable1

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Eugene Kuleshov
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Related
relates to CDV-548 Emit a warning or error when classes ... Closed
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 2.6

 Description   

I think there are two problems in here. The more severe is the actual NPE that happens in the classadapter, and as such this should be assigned to someone on transparency team.

The class adapter will try to dereference the super class of Object, which will be null, geting an NPE.

I got myself into this situation since I marked an Object variable as a root using the eclipse plugin. In theory we could exclude Object in this case, but that isn't truly necessary to special case



 Comments   
Comment by Alex Miller [ 14/Apr/08 ]

Is this a dup?

Comment by Hung Huynh [ 14/Apr/08 ]

dup of DEV-1110





[CDV-472] Internal DSO errors and/or TCClassNotFoundException from TCObject.resolveArrayReference() produce IllegalMonitorStateException Created: 16/Oct/07  Updated: 12/Feb/13  Resolved: 16/Jan/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Kalai Kannaiyan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to CDV-391 CloneNotSupportedException got swallo... Closed
Superset
incorporates CDV-400 research exceptions during TCObject.r... Closed
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
2.7
Fixed In Revision: 11289
Bug Type:
Implementation Error

 Description   

The code that introduces synchronization on the resolve lock during array de-reference doesn't handle exceptions correctly. In fact, the original exception will get lost and an IllegalMonitorStateException will be generated instead.

Exceptions can occur in this code path if:

a) Something unexpected like an OOME happens
b) There is a programming error in the TC code, like an assertion failure
c) The class for the array element cannnot be resolved.

The one that I worry most about is (c) since that is something a user can more or less naturally do on their own. Although, even though they are getting the wrong exception, I can't imagine the handling in the customer application would really be any different in practice, it will be an unexpected exception.

If possible, it would be nice to isolate the deference into a helper method where we can make sure the the synchronization is always done correctly. It is hard (impossible?) to do inline at the moment since an existing exception handler can already be covering the code. But using a helper method means computing the type of dereference since AALOAD is not a typed instruction. The verifier won't let us just write a method that returns Object here



 Comments   
Comment by Chris Dennis [ 16/Jan/09 ]

Integration of an exception table sorter into the main adapter chain (beneath TransparencyCodeAdapter) solves this. The finally block added by the instrumentation will now appear before any enclosing handlers in the table ensuring that the monitorexit is always correctly executed. This has also allowed the removal of the checkArrayIndex method from TCObject as the array access can now throw in directly, knowing that the handler will correctly unlock the monitor.

Comment by Chris Dennis [ 16/Jan/09 ]

CDV-391 has the same underlying cause (exception table ordering).

Comment by Chris Dennis [ 19/Jan/09 ]

Retargeted as this was fixed as a side effect of a 2.7.3 targeted item (CDV-391).

Comment by Kalai Kannaiyan [ 03/Feb/09 ]

Tested with Terracotta 2.7.3, as of 20090129-100112 (Revision 11424 by cruise@WXPMO0 from 2.7), it is working as expected.





[CDV-445] Client throws assertion error when attempting to reconnect to the TCServer - (assuming l1.reconnect is turned off). Created: 30/Sep/07  Updated: 12/Oct/07  Due: 26/Oct/07  Resolved: 10/Oct/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.4.3
Fix Version/s: None

Type: Bug Priority: 0 Showstopper
Reporter: Sreenivasan Iyer Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

When testing a simple app I unplugged the network cable to see how TC would react to this.
To my surprise the only thing I noticed on the TC client side were log statements in the client log files.

After a while I pluged the network cable back in and the client was not able te reconnect to the server. The server actually stopped with the following mdg

java.lang.AssertionError: Client connected before disconnecting : old Client state = ClientStateImpl[ChannelID=[3], ObjectIDSet2 [ Range(21000,21002)]]
at com.tc.objectserver.l1.impl.ClientStateManagerImpl.startupClient(ClientStateManagerImpl.java:176)
at com.tc.objectserver.handshakemanager.ServerClientHandshakeManager.notifyClientConnect(ServerClientHandshakeManager.java:90)
at com.tc.objectserver.handler.ClientHandshakeHandler.handleEvent(ClienHandshakeHandler.java:22)
at com.tc.async.impl.StageImpl$WorkerThread.run(StageImpl.java:140)

How can a client react when losing the connection with the TC server? how does TC help?



 Comments   
Comment by Sreenivasan Iyer [ 30/Sep/07 ]

see http://forums.terracotta.org/forums/posts/list/501.page

Comment by Steve Harris [ 30/Sep/07 ]

It's supposed to just log this not crash the server. If this is crashing the server we should fix it in the 2.4.4 release. Not sure when this regression occured

Comment by Hung Huynh [ 12/Oct/07 ]

Tim already added a test for this





[CDV-442] deal with missing/unavailable class resources in AsmClassInfo Created: 28/Sep/07  Updated: 29/Oct/07  Due: 26/Oct/07  Resolved: 16/Oct/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1, X-AspectWerkz
Affects Version/s: 2.4.3
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

From the forums, http://forums.terracotta.org/forums/posts/list/479.page

AsmClassInfo prints a warning when a class cannot be loaded as a stream resource. For generated classes, there may be no .class resource available, or in the case of hivemind, the classloader might just have a bug in it.

This item is to look into whether we should have a fallback to JavaClassInfo in some places, and also to look into whether ASMClassInfo should be remembering that a resource cannot be loaded through a particular loader.

AsmClassInfo(line 734)
System.out.println(
"AW::WARNING - could not load class ["
+ componentName
+ "] as a resource in loader ["
+ loader
+ "]"
);



 Comments   
Comment by Tim Eck [ 16/Oct/07 ]

revision 5963 has some changes that will at least only make this get printed once per missing resource. Made a small, but measurable speedup for the sample tapestry app in question





[CDV-441] jboss custom URLStreamHandler is defeated when TC in the mix Created: 28/Sep/07  Updated: 04/Oct/07  Resolved: 28/Sep/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.4.3
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File jboss-stack.txt    
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

From the forums: http://forums.terracotta.org/forums/posts/list/496.page

Looking at the attached stack trace, we cause org.jboss.net.protocol.URLStreamHandlerFactory.createURLStreamHandler() to be re-entered. That JBoss code uses a thread local to try to deal with re-entrancy, but in the end the effect is that the VM falls back to using the sun.* stream handler types instead of JBoss' internal handlers.

There doesn't seem to be a huge impact to this, but it does dramatically increase the number of simultaneous open file handles when the URLDeploymentScanner runs. It ends up using sun's file:// handler and doesn't close them. The file handles are eventually closed, but only after a GC runs and some finalizers get kicked off.






[CDV-435] explicitly specify versions and dependency versions in config bundles Created: 26/Sep/07  Updated: 04/Oct/07  Resolved: 04/Oct/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Eugene Kuleshov Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Fixed In Revision: 5797

 Description   

It is been agreed that we should always explicitly specify all versions and also use -SNAPSHOTS between releases, but it doesn't seem like it been changed in existing modules, except that tcbuild is adding -SNAPSHOT suffix to the nightly build jars deployed to maven repo. This last piece is most troublesome because module versions have 1.0.0, but artifacts deployed to maven repository are using version 1.0.0-SNAPSHOT.

Versions should be explicitly specified in tc.properties and module manifests:

l1.configbundles.default = excludes-config,1.0.0-SNAPSHOT;guimodels-config,1.0.0-SNAPSHOT;jdk15-preinst-config,1.0.0-SNAPSHOT;spring-config,1.0.0-SNAPSHOT;standard-config,1.0.0-SNAPSHOT

Bundle-SymbolicName: org.terracotta.modules.clustered-hibernate-3.1.2
Bundle-Version: 1.0.0.SNAPSHOT
Require-Bundle: org.terracotta.modules.modules_common;bundle-version="1.0.0.SNAPSHOT",
org.terracotta.modules.clustered-cglib-2.1.3;bundle-version="1.0.0.SNAPSHOT"

We'll have to match 1.0.0.SNAPSHOT version in module bundle with 1.0.0-SNAPSHOT version used in jar file names and Maven artifact versions.



 Comments   
Comment by Fiona OShea [ 27/Sep/07 ]

Can you verify that this is how everything works now?





[CDV-434] lookups for non-existent objects from the l1, should affect the l1 instead of the l2 Created: 25/Sep/07  Updated: 04/Oct/07  Resolved: 25/Sep/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.4.3
Fix Version/s: 2.4.4

Type: New Feature Priority: 2 Major
Reporter: Fiona OShea Assignee: Saravanan Subbiah
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Related
Fix In Branch:
trunk, 2.4
Fixed In Revision: 5547

 Description   

Currently we dont differentiate a lookup from the client or a server in the ObjectManager. When we receive a lookup for a non-existent object in the server, we consider it as a bug in the system (which it is) and throw an AssertionError which inturn crashes the server.

Instead we should propagate that error to the client that requested it. That way only the misbehaving client will crash and the assertion will be closer to the problem.






[CDV-429] Websphere module Created: 24/Sep/07  Updated: 15/Oct/07  Resolved: 08/Oct/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.4.3
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Ari Zilka Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File stackoverflow.txt     XML File tc-config.xml    
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Bug Found In Detail: Terracotta 2.4.3

 Description   

When trying to get wars loaded in Websphere using the Websphere config module, I had everything setup correctly but ended up with a failed container startup when my included classes where set as "..".

I tried leaving out include-classes and just defining my webapp name. That throws no errors but doesn't work.

I then included ".." and Websphere writes a 24MB log file to nativeErr.log with what is seemingly the world's longest stack trace. So I just eyeballed the stacktrace, and chose to exlude 2 things:

com.ibm..*
and
org.eclipse..*

Then everything worked perfectly.

I was sharing our Cart.war demo. And I have attached my tc-config (the one that works).



 Comments   
Comment by Tim Eck [ 24/Sep/07 ]

Not sure how many exceptions were happening, but one of them is a stackoverflow. The code that tries to create ClassInfo for isRoot() is getting an endless cycle of class loading with permissions.

It's not clear why InstrumentEverythingInContainerTest isn't failing – unless this specific only to 6.1.0.0 (We run 6.1.0.7 in the monkey)

Comment by Geert Bevin [ 25/Sep/07 ]

Following Tim's comment, I'm just curious, you're using WebSphere 6.1.0.7 (6.1 base version, fix pack 7), right? This includes the JDK fix pack.

Comment by Ari Zilka [ 28/Sep/07 ]

I could not find the fixpacks on ibm.com to go straight from 6.1.0.0 to 6.1.0.7. Their site is poorly organized. So, I was indeed running 6.1.0.7. If someone will help me find out how to patch, I will do so and see if the problem goes away. That's the next step.

Comment by Ari Zilka [ 29/Sep/07 ]

Sorry. I WAS NOT running 6.1.0.7. I was running 6.1.0.0.

Comment by Tim Eck [ 05/Oct/07 ]

This stackoverflow does not happen in 6.1.0.7. I observed it broken and not-broken in two different contexts (1) Using clean standalone installs of WAS and deploying the Cart demo, (2) Running our InstrumentEverythingInContainerTest. In both contexts, 6.1.0.0 got the same stackoverflowerror, and 6.1.0.7 worked fine.

This particular type of cycle can be detected and avoided (leaving some set of classes un-instrumentable). The overhead involved is not worth it in my opinion, even though this can really happen in any application.

Comment by Geert Bevin [ 07/Oct/07 ]

I agree that the IBM site is very poorly organized and it always takes me a while to find what I need too.

This is a document with all fixpacks and cumulative fixes for Websphere and the IBM JDK:

http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&uid=swg27004980#ver61

Comment by Geert Bevin [ 07/Oct/07 ]

Tim, can you comment more about why this endless cycle happens?

Comment by Tim Eck [ 08/Oct/07 ]

added a (non-overrideable) exclude for one class. 6.1.0.0 will start now with .. include in user config





[CDV-410] Investigate how to improve the IBM JDK memory manager Created: 05/Sep/07  Updated: 27/Jul/12  Resolved: 01/Oct/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.4-stable0, 2.4-stable1, 2.4.0, 2.4.1, 2.4.2
Fix Version/s: 2.5.1

Type: New Feature Priority: 2 Major
Reporter: Geert Bevin Assignee: Geert Bevin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Fix In Branch:
trunk

 Description   

Verify if we can't use the IBM JDK platform management beans to create a version of the memory manager pool monitor for the IBM JDK. More info here: http://www-128.ibm.com/developerworks/java/library/j-mxbeans/



 Comments   
Comment by Erh-Yuan Tsai [ 06/Sep/07 ]

Committed 5463 to enable using IBM jdk memory management.

A simple test program showed that ibm jdk using "Java heap" as name for old generation, Sun uses "PS Old Gen".
Test code:

List<GarbageCollectorMXBean> gcmbeans = ManagementFactory.getGarbageCollectorMXBeans();
for( GarbageCollectorMXBean gcmbean : gcmbeans )
{ System.out.println( "\nName: " + gcmbean.getName() );
System.out.println( "Collection count: " + gcmbean.getCollectionCount() );
System.out.println( "Collection time: " + gcmbean.getCollectionTime() );
System.out.println( "Memory Pools: " );
String[] memoryPoolNames = gcmbean.getMemoryPoolNames();
for( int i=0; i<memoryPoolNames.length; i++ )

{ System.out.println( "\t" + memoryPoolNames[ i ] ); }

}

Sun:


Name: PS Scavenge
Collection count: 21
Collection time: 5
Memory Pools: PS Eden Space
PS Survivor Space

Name: PS MarkSweep
Collection count: 0
Collection time: 0
Memory Pools: PS Eden Space
PS Survivor Space
PS Old Gen
PS Perm Gen


IBM:

Name: J9 GC
Collection count: 2
Collection time: 7
Memory Pools: Java heap

------

1) IBM-jdk, for ManagementFactory.getGarbageCollectorMXBeans(), it returns only one pool.
I guess, returns only one interested ( behaving different from Sun).
If test with ManagementFactory.getMemoryPoolMXBeans(); It lists all.

Name: class storage
Usage: init = 0(0K) used = 1625032(1586K) committed = 1968416(1922K) max = -1(undefined)
Collection Usage: null
Peak Usage: init = 0(0K) used = 1625032(1586K) committed = 1968416(1922K) max = -1(undefined)
Type: Non-heap memory
Memory Manager Names: J9 non-heap manager

Name: JIT code cache
Usage: init = 0(0K) used = 0(0K) committed = 524288(512K) max = -1(undefined)
Collection Usage: null
Peak Usage: init = 0(0K) used = 0(0K) committed = 0(0K) max = -1(undefined)
Type: Non-heap memory
Memory Manager Names: J9 non-heap manager

Name: JIT data cache
Usage: init = 0(0K) used = 24140(23K) committed = 524288(512K) max = -1(undefined)
Collection Usage: null
Peak Usage: init = 0(0K) used = 24140(23K) committed = 524288(512K) max = -1(undefined)
Type: Non-heap memory
Memory Manager Names: J9 non-heap manager

Name: miscellaneous non-heap storage
Usage: init = 0(0K) used = 326036(318K) committed = 458752(448K) max = -1(undefined)
Collection Usage: null
Peak Usage: init = 0(0K) used = 346764(338K) committed = 458752(448K) max = -1(undefined)
Type: Non-heap memory
Memory Manager Names: J9 non-heap manager

Name: Java heap
Usage: init = 67108864(65536K) used = 42254416(41264K) committed = 67108864(65536K) max = 67108864(65536K)
Collection Usage: init = 67108864(65536K) used = 470568(459K) committed = 67108864(65536K) max = 67108864(65536K)
Peak Usage: init = 67108864(65536K) used = 63753728(62259K) committed = 67108864(65536K) max = 67108864(65536K)
Type: Heap memory
Memory Manager Names: J9 GC

2) Tried different options, -server, -XX:+AggressiveOpts, -XX:+AggressiveOpts, -XX:-UseParallelGC.
All returns "Java heap".





[CDV-400] research exceptions during TCObject.resolveArrayReference() Created: 27/Aug/07  Updated: 29/Oct/07  Due: 26/Oct/07  Resolved: 16/Oct/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.4.2
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Tim Eck
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to CDV-391 CloneNotSupportedException got swallo... Closed
Superset
is incorporated by CDV-472 Internal DSO errors and/or TCClassNot... Closed
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

I don't know for sure if this broken, but I suspect it is. If TCObejct.resolveArrayReference() throws an exception, the artificial synchronized block on the resolveLock will fail to complete, probably earning oneself an IllegalMonitorStateException when the containing method exits.

The instrumentation in question is in TransparencyCodeAdpater.visitInsn() for the AALOAD case.



 Comments   
Comment by Tim Eck [ 16/Oct/07 ]

This is indeed broken, but I can't think of a good way to fix it without some really funky/horrible bytecode OR figuring out a way to know the precise type of the array dereference so that we can generate method to do the resolve in a controlled manner (and maybe more hotspot friendly)

Either way, I think I'm going to close this "research" item and enter a real bug about it





[CDV-391] CloneNotSupportedException got swallowed and replaced by IllegalMonitorStateException Created: 08/Aug/07  Updated: 02/Feb/09  Resolved: 16/Jan/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.4.2
Fix Version/s: 2.7.3

Type: Bug Priority: 3 Minor
Reporter: Hung Huynh Assignee: nadeem ghani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to CDV-400 research exceptions during TCObject.r... Closed
relates to CDV-472 Internal DSO errors and/or TCClassNot... Closed
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Fixed In Revision: 11289
Bug Type:
Implementation Error

 Description   

For a class that doesn't implement Cloneable, the expected CloneNotSupportedException got lost if you wrap it in RuntimeException. The caller will see a IllegalMonitorStateException instead.

Test for this bug: CloneExceptionTest, currently disabled.

private static class MyStuff {
protected Object clone() {
try

{ return super.clone(); }

catch (CloneNotSupportedException e)

{ throw new RuntimeException(e); }

}
}

Another case to be considered is when clone() is called on an object in a way other than super.clone(), for instance when an object's clone clones the fields of itself.

Additionally, there seems to be another wrinkle when calling clone() on an Object[] such that the same sort of resolving needs to occur that happens with a typical call to Object.clone(). As far as I can see, that's not handled by any of the current code.



 Comments   
Comment by Alex Miller [ 23/Aug/07 ]

The modification currently made by TransparencyCodeAdapter.handleJavaLangObjectCloneCall() is to replace calls to refToBeCloned.clone() with:

   Object refToBeCloned;
   Object rv;
   
   TCObject tco = (refToBeCloned instanceof Manageable) ? ((Manageable) refToBeCloned).__tc_managed() : null;
   if (tco != null) {
     synchronized (tco.getResolveLock()) {
       tco.resolveAllReferences();
       rv = Util.fixTCObjectReferenceOfClonedObject(refToBeCloned, refToBeCloned.clone());
     }
   } else {
     rv = refToBeCloned.clone();
   }

This modification of the caller of clone() is done using ASM and is not really exactly this, but something like this with some modifications. The subtle bug is introduced because clone() can throw CloneNotSupportedException, which is not handled here and the ASM modification will not (cannot?) properly update the exception handlers at the call site. I took a few stabs at tweaking the ASM code but it's pretty hairy (and will make this code even harder to maintain going forward).

Tim and I have been discussing some alternatives. One possibility is to make the modification at the callee intead of in the caller. We were trying to do it without modifying Manageable but I'm not sure it's possible to both do this in Manageable and avoid reflection (for performance).

Option 1: Given a clone() method on a Manageable object, replace with:

	public Object clone() {		// copy throws from original
		return Util.cloneHelper(this);
	}
	
	public Object __tc_clone() {	// copy throws from original clone
		return new Bar(a);
	}

and add a new static Util method (which would only be called from code in Manageable clone methods):

public static Object cloneHelper(Manabeable refToBeCloned) throws CloneNotSupportedException {
	Object rv;    
	TCObject tco = refToBeCloned.__tc_managed();
	if (tco != null) {
  		synchronized (tco.getResolveLock()) {
    		    tco.resolveAllReferences();
    		    rv = Util.fixTCObjectReferenceOfClonedObject(refToBeCloned, refToBeCloned.__tc_clone());
                }
	} else {
          rv = refToBeCloned.__tc_clone();      
	}		

The issue here is that __tc_clone() would need to be added to Manageable. I could work around that by using reflection in the call above to __tc_clone(), but I presume the performance implications would be too much to bear.

Another option would be to modify at both caller and callee site so that the caller would receive an extra method to do this logic. I think the exact same Manageable/reflection problem arises though (which is why callee would need a new method). Maybe this is the only option for logical?

Thoughts?

Comment by Geert Bevin [ 24/Aug/07 ]

I didn't look at it myself, but just read through your description. Imho changing Manageable is not really an option unless it's done in a major version upgrade. I was try to tweak the ASM modification to properly catch the exception and generate the expected one. Maybe it's not possible, as you say, but it seems to me that it should be.

Comment by Alex Miller [ 24/Aug/07 ]

The solution with the smallest change is probably tweaking the existing approach to handle exceptions thrown from the call to clone() better (basically need to make sure monitorexit is called). I think that is possible, having looked at it some more, just merely tricky and hard to maintain. So, I thought it was worth throwing out a couple alternatives.

Instead of changing Manageable, another option might be to add a new separate interface like ManageableWithClone that managed objects with clone() would also implement (in addition to Manageable). Or to extend the Manageable interface with a new interface like this.

I'd love some insight on how logical managed objects play into the choices here too - I don't understand enough of the difference to know whether it affects the choices.

Comment by Alex Miller [ 09/Nov/07 ]

Retarget per Steve

Comment by Chris Dennis [ 16/Dec/08 ]

I would go so far as to label this an ASM bug. Looking at ClassReader and ClassWriter it seems like ASM is forcing all the original exception handlers to the top of the table regardless of any nesting/scope relationships between the original handlers and any new handlers that have been added.

Comment by Chris Dennis [ 19/Dec/08 ]

I modified my local ASM copy (com.tc.asm) by implementing an exception handler comparator and then modding MethodWriter to sort the handlers using the comparator before writing out. This fix made the CloneExceptionTest pass...

Comment by Chris Dennis [ 19/Dec/08 ]

It appears ASM javadoc is incorrect... I managed to do this with just a method adapter. Adapter now checked into trunk at "dso-l1/com/tc/object/bytecode/ExceptionTableOrderingMethodAdapter".

Comment by Alex Miller [ 19/Dec/08 ]

If fixable now, go for it in 2.7.3.

Comment by Chris Dennis [ 16/Jan/09 ]

Exception table ordering (via a new adapter in the main chain) now ensures that the finally block that unlocks the monitor catches this exception (or any other exception) before any enclosing handler.

Comment by nadeem ghani [ 28/Jan/09 ]

test is enabled and passing





[CDV-387] Move all config module specific code out of the core code base Created: 22/Aug/07  Updated: 27/Jul/12  Resolved: 07/Apr/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1, Sessions, SpringRuntime
Affects Version/s: None
Fix Version/s: 2.6-stable1

Type: New Feature Priority: 1 Critical
Reporter: Steve Harris Assignee: Interfaces Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to CDV-329 Config Modules - reorganize Closed
Fix In Branch:
trunk, 2.6

 Description   

Specifically this is meant to represent

com.tc.hibernate
com.tc.jboss
com.tc.jetty
com.tc.geronimo.*
com.tc.ibatis
com.tc.session
com.tc.tomcat
tom.tc.weblogic.*
com.tc.websphere.*
com.tc.wicket

config module code should not be included in the tc.jar or the dso-l1 module



 Comments   
Comment by Fiona OShea [ 07/Apr/08 ]

Dup of CDV-329





[CDV-382] Hibernate SessionFactory.close() will shutdown CacheManager which will cause an IllegalStateException when other nodes try to access the 2nd level cache Created: 16/Aug/07  Updated: 27/Oct/08  Due: 31/Aug/07  Resolved: 06/Sep/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.4.1
Fix Version/s: 2.4.3

Type: Bug Priority: 2 Major
Reporter: Antonio Si Assignee: Hung Huynh
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

If an app invoke hibernate SessionFactory.close() when running ehcache, it will shutdown CacheMaanger. When running in a cluster, since the CacheManager is shared, other node will get an IllegalStateException when trying to access the CacheManager later.



 Comments   
Comment by Antonio Si [ 20/Aug/07 ]

For the time being, I am making the SessionFactory.close() method an no-op.

Please let me know if there is any concerns/issues.

Comment by Russell Pitre [ 30/Aug/07 ]

This jira issue says there is a workaround but does not describe what it is. Does anyone know what the workaround is?

Comment by Antonio Si [ 30/Aug/07 ]

The SessionFactory.close() calls org.hibernate.cache.EhCache.destroy() which removes a cache and calls org.hibernate.cache.EhCacheProvider.stop() which shutdowns the CacheManager.

For the time being, we are making these 2 methods an no-op when hibernate with ehcache as 2nd level cache running in a clustered mode.

Comment by Russell Pitre [ 30/Aug/07 ]

I'm running Terracotta 2.4.1 at the moment. How do i configure this for the time being untill the fix is released?

Comment by Antonio Si [ 06/Sep/07 ]

The fixes will be available in the upcoming releases or our nightly build.





[CDV-357] Getting verifier errors when instrumenting obfuscated classes Created: 01/Aug/07  Updated: 24/Sep/07  Resolved: 16/Aug/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.4.0
Fix Version/s: trunk-nightly

Type: Bug Priority: 2 Major
Reporter: Gary Keim Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to CDV-384 Create or start a basic config module Closed
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk
Fixed In Revision: rev 5074

 Description   

Users have encountered class verifier errors when instrumenting obfuscated classes, such as com/sun/crypto/provider/SunJCE_m:

http://forums.terracotta.org/forums/posts/list/344.page

The work-around is to exclude those classes from instrumentation:

<instrumented-classes>
<exclude>com.sun.crypto.provider..*</exclude>
</instrumented-classes>



 Comments   
Comment by Eugene Kuleshov [ 01/Aug/07 ]

In my recollection that happens only on early Sun's 1.5 JRE and been fixed in later versions...

Comment by Fiona OShea [ 02/Aug/07 ]

Add this exclude to all sample session files and configurator default files etc.

Comment by Juris Galang [ 15/Aug/07 ]

I think we could/should be able to always exclude the sun crypto classes by applying the appropriate excludes via the modules-common config-bundle.

Comment by Juris Galang [ 15/Aug/07 ]

We could also have a config-bundle specifically for excluding classes that we can not instrument. And make it so that this bundle is always loaded/started when an l1 starts.





[CDV-338] support lucene 2.2.0 Created: 22/Jul/07  Updated: 16/Dec/11  Resolved: 13/Feb/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.4.0
Fix Version/s: None

Type: New Feature Priority: 3 Minor
Reporter: Tim Eck Assignee: Interfaces Team
Resolution: Won't Fix Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to CDV-337 Lucene config bundle isn't locked pro... Closed
relates to CDV-469 Make Lucene integration module work w... Open
Roadmap
Fix In Branch:
trunk

 Description   

Our config module for lucene only supports version 2.0.0 at the moment. Lucene has moved on to version 2.2.0.

In all honesty, I think we should write a terracotta implementation of the "Directory" abstraction in lucene, as opposed to the current approach of trying to DSO'ize the existing RAMDirectory that ships with lucene. This implies figuring out how to best expose this implementation class to an end user (is it another jar, is it done with instrumentation magic, etc)



 Comments   
Comment by Stefan F [ 30/Apr/08 ]

I successfully used the Directory from the Compass SVN (see [1],[2]; [3],[4]) instead of Lucene's RAMDirectory together with tim-lucene-2.2.0 ([5]). Changing the Directory implementation resulted in a tremendous (!!! - and I could reasonably add some more) speed up of batch index creation: from 1 hour (there was probably also something fishy on my side) to 10 seconds for 5k sentences of 4 words (average). I would therefor suggest to adopt this Directory implementation for Lucene 2.2.0 support.

// blogs describing work on terracotta, compass, lucene:
[1] http://www.kimchy.org/compasslucene-terracotta-integration/
[2] http://javathink.blogspot.com/2008/03/chronicles-of-terracotta-integration.html

// compass svn
[3] http://svn.compass-project.org/svn/compass/trunk/src/main/src/terracotta.xml
[4] http://svn.compass-project.org/svn/compass/trunk/src/main/src/org/compass/needle/terracotta/

// tim-lucene-2.2.0
[5] http://svn.terracotta.org/svn/forge/projects/labs/tim-lucene-2.2.0/

Comment by Shay Banon [ 03/Nov/08 ]

Compass integration (recent one is 2.1 version, which supports Lucene 2.4) is a tim bundle. This means that you can easily use it within your terracotta application by including it as a tim in your tc config. Note, you don't have to use Compass and just use its Terracotta based Directory (it was done by Hibernate Search for example).

More information can be found here: http://www.compass-project.org/docs/2.1.0/reference/html/needle-terracotta.html

Comment by Taylor Gautier [ 13/Feb/09 ]

Compass solves this problem in a mostly lucene independent way.





[CDV-332] Seems like we run into an ASM exception when instrumenting a specific class from a ColdFusion package Created: 11/Jul/07  Updated: 27/Jul/12  Resolved: 23/Oct/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Sreenivasan Iyer Assignee: Issue Review Board
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 0 Down/unusable, no workaround available
Fix In Branch:
trunk

 Description   

Might be related to http://jira.terracotta.org/jira/browse/CDV-286

java.lang.IllegalStateException: Unknown local variable 2 : value Ljava/lang/Object;
at com.tc.asm.commons.LocalVariablesSorter.visitLocalVariable(LocalVariablesSorter.java:156)
at com.tc.asm.ClassReader.accept(ClassReader.java:1429)
at com.tc.asm.ClassReader.accept(ClassReader.java:394)
at com.tc.object.bytecode.hook.impl.DefaultWeavingStrategy.transform(DefaultWeavingStrategy.java:269)
at com.tc.object.bytecode.hook.impl.DSOContextImpl.preProcess(DSOContextImpl.java:137)
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.defineClass0Pre(ClassProcessorHelper.java:439)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at coldfusion.runtime.TemplateClassLoader.findClass(TemplateClassLoader.java:144)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at coldfusion.runtime.TemplateClassLoader$1.fetch(TemplateClassLoader.java:352)
at coldfusion.util.LruCache.get(LruCache.java:180)
at coldfusion.runtime.TemplateClassLoader$TemplateCache.fetchSerial(TemplateClassLoader.java:256)
at coldfusion.util.AbstractCache.fetch(AbstractCache.java:5
at coldfusion.util.SoftCache.get(SoftCache.java:81)
at coldfusion.runtime.TemplateClassLoader.findClass(TemplateClassLoader.java:477)
at coldfusion.filter.PathFilter.invoke(PathFilter.java:79)
at coldfusion.filter.LicenseFilter.invoke(LicenseFilter.java:27)
at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70)
at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:2
at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:3
at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46)
at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:3
at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
at coldfusion.CfmServlet.service(CfmServlet.java:175)
at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42)
at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:17
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at com.tc.tomcat55.session.SessionValve55.tcInvoke(SessionValve55.java:61)
at com.tc.tomcat55.session.SessionValve55.invoke(SessionValve55.java:4
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:14
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)
07/11 10:04:29 Error [http-9081-Processor4] - Unknown local variable 2 : value Ljava/lang/Object; The specific sequence of files included or processed is: C:\environment2\terracotta\terracotta-2.4-stable1\tools\sessions\configurator-sandbox\tomcat5.5\9081\webapps\cfusion.war\test.cfm''
java.lang.IllegalStateException: Unknown local variable 2 : value Ljava/lang/Object;
at com.tc.asm.commons.LocalVariablesSorter.visitLocalVariable(LocalVariablesSorter.java:156)
at com.tc.asm.ClassReader.accept(ClassReader.java:1429)
at com.tc.asm.ClassReader.accept(ClassReader.java:394)
at com.tc.object.bytecode.hook.impl.DefaultWeavingStrategy.transform(DefaultWeavingStrategy.java:269)
at com.tc.object.bytecode.hook.impl.DSOContextImpl.preProcess(DSOContextImpl.java:137)
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.defineClass0Pre(ClassProcessorHelper.java:439)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at coldfusion.runtime.TemplateClassLoader.findClass(TemplateClassLoader.java:144)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at coldfusion.runtime.TemplateClassLoader$1.fetch(TemplateClassLoader.java:352)
at coldfusion.util.LruCache.get(LruCache.java:180)
at coldfusion.runtime.TemplateClassLoader$TemplateCache.fetchSerial(TemplateClassLoader.java:256)
at coldfusion.util.AbstractCache.fetch(AbstractCache.java:5
at coldfusion.util.SoftCache.get(SoftCache.java:81)
at coldfusion.runtime.TemplateClassLoader.findClass(TemplateClassLoader.java:477)
at coldfusion.runtime.TemplateClassLoader.newInstance(TemplateClassLoader.java:434)
at coldfusion.tagext.lang.IncludeTag.setTemplate(IncludeTag.java:156)
at coldfusion.tagext.lang.IncludeTag.setTemplatePath(IncludeTag.java:91)
at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:64)
at coldfusion.filter.CfincludeFilter.include(CfincludeFilter.java:33)
at coldfusion.filter.ExceptionFilter.runBuiltInHandler(ExceptionFilter.java:552)
at coldfusion.filter.ExceptionFilter.handleException(ExceptionFilter.java:329)
at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:84)
at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:2
at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:3
at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46)
at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:3
at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
at coldfusion.CfmServlet.service(CfmServlet.java:175)
at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42)
at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:17
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at com.tc.tomcat55.session.SessionValve55.tcInvoke(SessionValve55.java:61)
at com.tc.tomcat55.session.SessionValve55.invoke(SessionValve55.java:4
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:14
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)
07/11 10:04:29 Error [http-9081-Processor4] - Exception thrown by error-handling template:
07/11 10:04:29 Error [http-9081-Processor4] - Unknown local variable 2 : value Ljava/lang/Object; The specific sequence of files included or processed is: C:\environment2\terracotta\terracotta-2.4-stable1\tools\sessions\configurator-sandbox\tomcat5.5\9081\webapps\cfusion.war\WEB-INF\exception\java\lang\Exception.cfm''
Exception thrown by error-handling template:
java.lang.IllegalStateException: Unknown local variable 2 : value Ljava/lang/Object;
at com.tc.asm.commons.LocalVariablesSorter.visitLocalVariable(LocalVariablesSorter.java:156)
at com.tc.asm.ClassReader.accept(ClassReader.java:1429)
at com.tc.asm.ClassReader.accept(ClassReader.java:394)
at com.tc.object.bytecode.hook.impl.DefaultWeavingStrategy.transform(DefaultWeavingStrategy.java:269)
at com.tc.object.bytecode.hook.impl.DSOContextImpl.preProcess(DSOContextImpl.java:137)
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.defineClass0Pre(ClassProcessorHelper.java:439)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at coldfusion.runtime.TemplateClassLoader.findClass(TemplateClassLoader.java:144)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at coldfusion.runtime.TemplateClassLoader$1.fetch(TemplateClassLoader.java:352)
at coldfusion.util.LruCache.get(LruCache.java:180)
at coldfusion.runtime.TemplateClassLoader$TemplateCache.fetchSerial(TemplateClassLoader.java:256)
at coldfusion.util.AbstractCache.fetch(AbstractCache.java:5
at coldfusion.util.SoftCache.get(SoftCache.java:81)
at coldfusion.runtime.TemplateClassLoader.findClass(TemplateClassLoader.java:477)
at coldfusion.filter.PathFilter.invoke(PathFilter.java:79)
at coldfusion.filter.LicenseFilter.invoke(LicenseFilter.java:27)
at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70)
at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:2
at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:3
at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46)
at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:3
at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
at coldfusion.CfmServlet.service(CfmServlet.java:175)
at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42)
at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:17
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at com.tc.tomcat55.session.SessionValve55.tcInvoke(SessionValve55.java:61)
at com.tc.tomcat55.session.SessionValve55.invoke(SessionValve55.java:4
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:14
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)



 Comments   
Comment by Eugene Kuleshov [ 11/Jul/07 ]

Can we find out what the class is and get the bytecode?

Comment by Sreenivasan Iyer [ 11/Jul/07 ]

"
The Tomcat version is the one used as default by terracotta, Version 5.5. The JDK is again the one provided within terracotta C:\environment2\terracotta\terracotta-2.4-stable1\jre. (1.5 I suppose)...I am using the terracotta 2.4-stable1 "

Comment by Eugene Kuleshov [ 11/Jul/07 ]

Iyer, it got to be some class from the user app of framework that is being loaded...

Comment by Tim Eck [ 11/Jul/07 ]

You might be able to figure out what class is being loaded by decompiling the place where the loadClass starts:

coldfusion.runtime.TemplateClassLoader$1.fetch(TemplateClassLoader.java:352)

A copy of that class might help (note: it is the anonymous inner class, not TemplateClassLoader)

Comment by Tim Eck [ 12/Jul/07 ]

I ran the code from coldfusion mx7 through our instrumentation – didn't reproduce this issue. Now that I look at the CF code, the bytecode issue might actually be in an application class. If one turns on instrumentation logging in dso, you should be able to figure out which class is causing the problem (it will be last one reported as "... included for instrumentation").

We'd still want to see the problematic class to figure out why it trips up the LocalVariableSorter





[CDV-304] workaround bug in Jboss' fork of commons-logging Created: 21/Jun/07  Updated: 29/Jun/07  Resolved: 21/Jun/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.4-stable0
Fix Version/s: 2.4-stable1

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
2.4

 Description   

We can potentially set the thread context loader to null when loading/initializing user land classes. Under JBoss (at least version 4.0.5-GA), there is a bug in their in-house fork of commons-loggging.

http://jira.jboss.com/jira/browse/JBAS-4437

java.lang.ExceptionInInitializerError
at sun.reflect.GeneratedSerializationConstructorAccessor60.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at com.tc.object.TCObjectFactoryImpl.getNewPeerObject(TCObjectFactoryImpl.java:77)
at com.tc.object.TCObjectFactoryImpl.getNewPeerObject(TCObjectFactoryImpl.java:65)
at com.tc.object.ClientObjectManagerImpl.createNewPeer(ClientObjectManagerImpl.java:1064)
at com.tc.object.ClientObjectManagerImpl.createNewPeer(ClientObjectManagerImpl.java:1025)
at com.tc.object.TCObjectImpl.createPeerObjectIfNecessary(TCObjectImpl.java:166)
at com.tc.object.TCObjectImpl.hydrate(TCObjectImpl.java:101)
at com.tc.object.ClientObjectManagerImpl.lookup(ClientObjectManagerImpl.java:511)
at com.tc.object.ClientObjectManagerImpl.lookupObject(ClientObjectManagerImpl.java:409)
at com.tc.object.ClientObjectManagerImpl.lookupObject(ClientObjectManagerImpl.java:402)
at com.tc.object.bytecode.ManagerImpl.lookupObject(ManagerImpl.java:605)
at com.tc.object.bytecode.ManagerUtil.lookupObject(ManagerUtil.java:161)
at java.util.HashMap.lookUpAndStoreIfNecessary(Unknown Source)
at java.util.HashMap.get(Unknown Source)
<snip – application code>
Caused by: org.apache.commons.logging.LogConfigurationException: java.lang.NullPointerException (Caused by java.lang.NullPointerException)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:538)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:353)
at XXX-APPLICATION-CODE.<clinit>(Workflow.java:40)
... 84 more
Caused by: java.lang.NullPointerException
at org.apache.commons.logging.impl.Log4jProxy$1.run(Log4jProxy.java:66)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.commons.logging.impl.Log4jProxy.threadContextClassLoader(Log4jProxy.java:88)
at org.apache.commons.logging.impl.Log4jProxy.<init>(Log4jProxy.java:94)
at org.apache.commons.logging.impl.Log4JLogger.<init>(Log4JLogger.java:39)
at sun.reflect.GeneratedConstructorAccessor23.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
... 88 more



 Comments   
Comment by Tim Eck [ 21/Jun/07 ]

We should only adjust the thread context loader if the current thread is not an application thread (another way to say that is that we should only adjust it if the current thread is a terracotta thread)





[CDV-286] Issues with Java 6 bytecode Created: 04/Jun/07  Updated: 19/Jun/07  Resolved: 19/Jun/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.3
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Eugene Kuleshov Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive mylar-context.zip     Text File terracotta-client_asmAssert_.log    
Issue Links:
Related
relates to CDV-302 create a test that will create class ... Resolved
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 2.4

 Description   

We saw some failure when instrumenting bytecode compiled with -target 1.6:

java.lang.IllegalStateException: ClassReader.accept() should be called with EXPAND_FRAMES flag
at com.tc.asm.commons.LocalVariablesSorter.visitFrame(LocalVariablesSorter.java:169)
at com.tc.asm.ClassReader.accept(ClassReader.java:1159)
at com.tc.asm.ClassReader.accept(ClassReader.java:394)
at com.tc.object.bytecode.hook.impl.DefaultWeavingStrategy.transform(DefaultWeavingStrategy.java:269)
at com.tc.object.bytecode.hook.impl.DSOContextImpl.preProcess(DSOContextImpl.java:137)
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.defineClass0Pre(ClassProcessorHelper.java:416)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)



 Comments   
Comment by Eugene Kuleshov [ 04/Jun/07 ]

The exception says it. There is a loaded feature in "LocalVariablesSorter" that allows to incrementally update stackmap frames, to allow to avoid full recalculation. So, ClassReader.accept() calls that receive any subclass of LocalVariable sorter need EXPAND_FRAMES flag.

However to make it work, all the chained visitors should also support incremental stackmap updates (which is not always simple task and it would require special attention).

If we can't support incremental updates, then we'll need to turn on COMPUTE_FRAMES on ClassWriters. But then we'll need special class resolver (ClassWriter.getCommonSuperClass() need to be overwritten) that would resolve classes without classloading. That all will slowdown transformation quite a bit.

There is an alternative way. Since JVM would fall back to old bytecode verifier and there is no other bytecode additions in Java 6, we can downgrade Java 6 bytecode to Java 5 and strip all frame information from transformed classes using ClassReader.SKIP_FRAMES flag. This option will buy us time until Java 7.

Comment by Eugene Kuleshov [ 04/Jun/07 ]

For the future reference see ClassInfo in http://tinyurl.com/2ueuk2 for an example of the naive non-caching class resolver. We should be able to use and extend ClasInfo implementation from AW.

Comment by Eugene Kuleshov [ 13/Jun/07 ]

Fix committed to trunk and 2.4 branch

Comment by Sreenivasan Iyer [ 15/Jun/07 ]

Using this nightly build results in an ASM assertion elsewhere (jdk1.6)
plz advise.

Comment by Steve Harris [ 15/Jun/07 ]

I don't see the new exception attached to this bug entry. Am I missing it? Tim felt it was not related?

Comment by Nathaniel Harward [ 15/Jun/07 ]

From Tim Eck on email: 'Any idea what the "tc.server" system property is? It looks like it might be getting set, and the code expects it to be of the form "server:port,server2:port,etc". The actual value in the property is missing the ":port" part...'

I agree with Tim here, the attached terracotta-client_asmAssert.log file looks like it has nothing to do with ASM at all, just a configuration error. You should be able to simply omit this system property in which case the tc-config.xml file will be consulted, and appears to have this:

<server host="localhost" name="localhost:9510">
<data>%(tc.home)/terracotta/server-data</data>
<logs>%(tc.home)/terracotta/server-logs</logs>
</server>

Or if you have to set tc.server to something, set it to "localhost:9510". Please try that, it should either work or get to the next problem in the chain

Comment by Nathaniel Harward [ 15/Jun/07 ]

Assigning back to Eugene, there may be something else to finish up or test before this is closed out.

Comment by Steve Harris [ 19/Jun/07 ]

Do we think this works now? Can you and tim figure this out so the customer doesn't bolt. Eu is out till thursday.

Comment by Eugene Kuleshov [ 19/Jun/07 ]

Apparently I missed few places where ClassReader.accept() method is called without SKIP_FRAMES (stupid method call references search in Eclipse). Here is the list:

\code\base\aspectwerkz\src\com\tc\aspectwerkz\proxy\ProxyDelegationCompiler.java
\code\base\aspectwerkz\src\com\tc\aspectwerkz\transform\inlining\ProxyWeavingStrategy.java
\code\base\aspectwerkz\src\com\tc\aspectwerkz\transform\inlining\weaver\SerialVersionUidVisitor.java
\code\base\dso-l1\src\com\tc\object\bytecode\hook\impl\DefaultWeavingStrategy.java

So, you need to find all calls to ClassReader.accept() methods and add ClassReader.SKIP_FRAMES bitmask into the second parameter. This is a trivial fix, I

Comment by Tim Eck [ 19/Jun/07 ]

The last comment seems to be cut short – I'm going to make the suggested changes now in 2.4 branch

Comment by Nathaniel Harward [ 19/Jun/07 ]

Tim is working on this for Iyer, so I'll assign it to him.

Comment by Tim Eck [ 19/Jun/07 ]

should have all accept() calls modified now





[CDV-285] Auto-locking should not do auto-locking on the clearReferences method added to logical classes. Created: 04/Jun/07  Updated: 11/Jun/07  Resolved: 05/Jun/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.3-Stable0, 2.3-stable1, 2.3 EE, 2.3, trunk-nightly
Fix Version/s: trunk-nightly

Type: Bug Priority: 2 Major
Reporter: Steve Harris Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

Also, we should rename clearReferences to something with the terracotta prefix so that we don't conflict with user space method
names (unlikely but possible).

TC Memory Monitor" daemon prio=1 tid=0x087cf6e0 nid=0x3213 in Object.wait() [0x50767000..0x50767878]
at java.lang.Object.wait(Native Method)

  • waiting on <0x47e6dcd8> (a java.lang.Object)
    at java.lang.Object.wait(Object.java:429)
    at com.tc.object.lockmanager.impl.ClientLock.waitForLock(ClientLock.java:505)
  • locked <0x47e6dcd8> (a java.lang.Object)
    at com.tc.object.lockmanager.impl.ClientLock.basicLock(ClientLock.java:168)
    at com.tc.object.lockmanager.impl.ClientLock.lock(ClientLock.java:88)
    at com.tc.object.lockmanager.impl.ClientLock.lock(ClientLock.java:78)
    at com.tc.object.lockmanager.impl.ClientLockManagerImpl.lock(ClientLockManagerImpl.java:221)
    at com.tc.object.lockmanager.impl.ThreadLockManagerImpl.lock(ThreadLockManagerImpl.java:46)
    at com.tc.object.tx.ClientTransactionManagerImpl.begin(ClientTransactionManagerImpl.java:170)
    at com.tc.object.bytecode.ManagerImpl.begin(ManagerImpl.java:308)
    at com.tc.object.bytecode.ManagerImpl.monitorEnter(ManagerImpl.java:445)
    at com.tc.object.bytecode.ManagerUtil.monitorEnter(ManagerUtil.java:208)
    at java.util.Hashtable.clearReferences(Hashtable.java)
    at com.tc.object.TCObjectLogical.clearReferences(TCObjectLogical.java:33)
    at com.tc.object.TCObjectImpl.clearReferences(TCObjectImpl.java:207)
  • locked <0x464ca4c0> (a com.tc.object.ObjectID)
    at com.tc.object.ClientObjectManagerImpl.evictCache(ClientObjectManagerImpl.java:1063)
    at com.tc.object.cache.CacheManager.memoryUsed(CacheManager.java:43)
    at com.tc.runtime.TCMemoryManagerImpl.fireMemoryEvent(TCMemoryManagerImpl.java:97)
  • locked <0x454f2340> (a com.tc.runtime.TCMemoryManagerImpl)
    at com.tc.runtime.TCMemoryManagerImpl.access$500(TCMemoryManagerImpl.java:15)
    at com.tc.runtime.TCMemoryManagerImpl$MemoryMonitor.fire(TCMemoryManagerImpl.java:190)
    at com.tc.runtime.TCMemoryManagerImpl$MemoryMonitor.reportUsage(TCMemoryManagerImpl.java:177)
    at com.tc.runtime.TCMemoryManagerImpl$MemoryMonitor.run(TCMemoryManagerImpl.java:132)


 Comments   
Comment by Steve Harris [ 04/Jun/07 ]

this is all related to:

http://forums.terracotta.org/forums/posts/list/267.page

Comment by Antonio Si [ 05/Jun/07 ]

Add new test HashtableAutoLockTest





[CDV-284] L1 disconnects abruptly from L2 Created: 15/Jan/07  Updated: 27/Jul/12  Resolved: 25/Jan/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Sreenivasan Iyer Assignee: Tim Eck
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

1. See log snippet below.

2. Inspite of all debugging being turned on, there was no message indicating why the disconnect occurred - so there should be some more visiblity

3. The issue was eventually traced back to starting tomcat from a controller process jsvc http://jakarta.apache.org/commons/daemon/jsvc.html. Stating Tomcat via catalina.sh without a controlling process worked around this issue. We should investigate this since starting a dameon process with jsvc appears to non-trivially prevalent.

Thanks.

2007-01-09 17:05:22,488 [WorkerThread(client_handshake_stage,0)] INFO com.tc.objectserver.handshakemanager.ServerClientHandshakeManager - Client connected ChannelID=[1]

2007-01-09 17:07:14,412 [WorkerThread(jmxremote_connect_stage,0)] INFO com.tc.management.remote.connect.ClientConnectEventHandler - DSO client channel[1] removed, closing tunneled JMX connection

2007-01-09 17:07:14,516 [Job_Executor0] INFO com.tc.management.remote.connect.ClientConnectEventHandler$ConnectorClosedListener

  • Tunneled JMX connection to a DSO client has terminated, unregistering its beans

2007-01-09 17:07:14,916 [WorkerThread(channel_life_cycle_stage,0)]
INFO com.tc.objectserver.handler.ChannelLifeCycleHandler - Received transport disconnect. Killing client ChannelID=[1]



 Comments   
Comment by Steve Harris [ 16/Jan/07 ]

See if you can straighten this out

Comment by Tim Eck [ 17/Jan/07 ]

this is probably the same issue we had with JBoss' tomcat. In all branches except trunk(Moraga), there was instrumentation that shut down the DSO client when a particular method org.apache.catalina.startup.Catalina.start() returned. That method has two contexts that is can be called in – a blocking and a non-blocking version. JBoss (and presumably tomcat under jsvc) use the non-blocking version, and thus the DSO client shuts down as soon as tomcat starts

I'll be addressing this in Moraga.

It would be great if a trunk build could be tested with tomcat+JSvc and the results posted here

Comment by Tim Eck [ 25/Jan/07 ]

looks like this is fixed in trunk (which will be Moraga(2.3.0)). I tested a tomcat running under jsvc. The DSO client disconnects as described when I run it with 2.2.1, and running with trunk it stays connected.





[CDV-283] JVM Error when using JProfiler with dso client Created: 27/May/07  Updated: 27/Mar/08  Resolved: 14/Sep/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: trunk-nightly
Fix Version/s: 2.6-stable0

Type: Bug Priority: 2 Major
Reporter: Hung Huynh Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File hs_err_pid9460.log    
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

The same error occurs for jdk1.5.0_11 and jdk1.6.0_01

Working directory: C:\Program Files\Terracotta\terracotta-trunk-nightly-rev3308\samples\pojo\jtable
Executed call: C:\jdk\jdk1.5.0_11\bin\javaw.exe -agentlib:jprofilerti=port=31757 "-Xbootclasspath/p:c:\Program Files\Terracotta\terracotta-trunk-nightly-rev3308\bin\..\lib\dso-boot\dso-boot-hotspot_win32_150_11.jar" "-Dtc.install-root=c:\Program Files\Terracotta\terracotta-trunk-nightly-rev3308\bin\.." -Dtc.config=tc-config.xml "-Xbootclasspath/a:C:\Program Files\jprofiler5\bin\agent.jar" -classpath "C:\Program Files\Terracotta\terracotta-trunk-nightly-rev3308\samples\pojo\jtable\classes" demo.jtable.Main

JProfiler> Protocol version 24
JProfiler> Using JVMTI
JProfiler> 32-bit library
JProfiler> Listening on port: 31757.
JProfiler> Native library initialized
JProfiler> Hotspot compiler enabled
JProfiler> Starting com/tc/net/NIOWorkarounds ...

JProfiler> Waiting for a connection from the JProfiler GUI ...
#

  1. An unexpected error has been detected by HotSpot Virtual Machine:
    #
  2. EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6874fa03, pid=9460, tid=6608
    #
  3. Java VM: Java HotSpot(TM) Client VM (1.5.0_11-b03 mixed mode)
  4. Problematic frame:
  5. C [jprofilerti.dll+0x4fa03]
    #
  6. An error report file with more information is saved as hs_err_pid9460.log
    #
  7. If you would like to submit a bug report, please visit:
  8. http://java.sun.com/webapps/bugreport/crash.jsp
    #


 Comments   
Comment by Anders Bengtsson [ 28/May/07 ]

This is the error I'm getting, with JProfiler 4. I've tried to re-arrange the bootclasspath stuff in lots of different combinations, but always getting this same error.

/usr/java/jdk1.5.0_11/bin/java -agentlib:jprofilerti=port=34505 -Xbootclasspath/a:/home/anders/jprofiler4/bin/agent.jar -Xbootclasspath/p:/home/anders/terracotta-2.3.0/lib/dso-boot/dso-boot-hotspot_linux_150_11.jar -Dtc.install-root=/home/anders/terracotta-2.3.0 -Dtc.config=pr-yggdrasil/config/tc.xml -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=9999 -Dmonitor.jmx.rmi.port=3000 -Dcom.sun.management.jmxremote -Xmx400m -Xms400m -Didea.launcher.port=7533 -Didea.launcher.bin.path=/home/anders/idea-6180/bin -Dfile.encoding=ISO-8859-1 -classpath /usr/java/jdk1.5.0_11/jre/lib/jce.jar:/usr/java/jdk1.5.0_11/jre/lib/javaws.jar:/usr/java/jdk1.5.0_11/jre/lib/jsse.jar:/usr/java/jdk1.5.0_11/jre/lib/deploy.jar:/usr/java/jdk1.5.0_11/jre/lib/charsets.jar:/usr/java/jdk1.5.0_11/jre/lib/plugin.jar:/usr/java/jdk1.5.0_11/jre/lib/rt.jar:/usr/java/jdk1.5.0_11/jre/lib/ext/sunjce_provider.jar:/usr/java/jdk1.5.0_11/jre/lib/ext/sunpkcs11.jar:/usr/java/jdk1.5.0_11/jre/lib/ext/dnsns.jar:/usr/java/jdk1.5.0_11/jre/lib/ext/localedata.jar:/home/anders/perforce/pr/pr-yggdrasil/build/test/classes:/home/anders/perforce/pr/pr-yggdrasil/build/prod/classes:/home/anders/perforce/pr/lib/ojdbc14.jar:/home/anders/perforce/pr/lib/junit-4.1.jar:/home/anders/perforce/pr/lib/log4j-1.2.14.jar:/home/anders/perforce/pr/pr-cluster/classes:/home/anders/perforce/pr/pr-util/classes:/home/anders/perforce/pr/lib/jmock-1.1.0.jar:/home/anders/perforce/pr/pr-yggdrasil/lib/jruby/jruby-1.0RC2.jar:/home/anders/perforce/pr/pr-yggdrasil/lib/jruby/backport-util-concurrent.jar:/home/anders/perforce/pr/lib/ehcache-1.2.4.jar:/home/anders/perforce/pr/lib/commons-logging-1.0.4.jar:/home/anders/perforce/pr/pr-yggdrasil-common/classes:/home/anders/idea-6180/lib/idea_rt.jar com.intellij.rt.execution.application.AppMain com.pricerunner.yggdrasil.Main
JProfiler> Protocol version 21
JProfiler> Using JVMTI
JProfiler> 32-bit library
JProfiler> Listening on port: 34505.
JProfiler> Native library initialized
JProfiler> Hotspot compiler enabled
JProfiler> A different instance of the native library has been
JProfiler> loaded. Please check the appropriate environment
JProfiler> variable. (PATH, LD_LIBRARY_PATH, DYLD_LIBRARY_PATH)
JProfiler> Exiting.

Comment by Eugene Kuleshov [ 28/May/07 ]

Anders, have you tried to report this problem to JProfiler folks? They may have better idea about the meaning of this error.

Comment by orion [ 14/Sep/07 ]

Anders reports that this has been fixed:

Hi,

Just thought I should let you know:

I asked some time ago about profilers that work with Terracotta clients, in particular JProfiler which we already had. We reported JProfiler's problems with Terracotta to the JProfiler support. They have fixed it, so the version of JProfiler they have available for download now (5.0.1 with some hot-fix) works fine with Terracotta.

/Anders





[CDV-279] Cannot share an enum value Created: 24/May/07  Updated: 12/Feb/13  Resolved: 25/May/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: trunk-nightly
Fix Version/s: 2.4-stable0

Type: Bug Priority: 2 Major
Reporter: Gary Keim Assignee: Kalai Kannaiyan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Archive File DSOEnum.jar    
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

Cannot share a simple enum value. Import the attached Eclipse project and run it twice:

com.tc.exception.TCClassNotFoundException: java.lang.ClassNotFoundException: com.tc.object.dna.impl.EnumInstance
at com.tc.object.ClientObjectManagerImpl.lookupOrCreateRoot(ClientObjectManagerImpl.java:568)
at com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:284)
at com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:263)
at com.tc.object.bytecode.ManagerUtil.lookupOrCreateRoot(ManagerUtil.java:82)
at test.DSOEnumTest.__tc_setcolor(DSOEnumTest.java)
at test.DSOEnumTest.<init>(DSOEnumTest.java:5)
at test.DSOEnumTest.main(DSOEnumTest.java:8)



 Comments   
Comment by Steve Harris [ 24/May/07 ]

Is this the same thing or something different?

Comment by Kalai Kannaiyan [ 15/Aug/07 ]

refer the comments for CDV-278. Closing this issue





[CDV-272] Remove classloader issues webapp to webapp Created: 22/May/07  Updated: 10/Apr/09  Resolved: 02/Mar/09

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.0.0

Type: New Feature Priority: 1 Critical
Reporter: Steve Harris Assignee: Tim Eck
Resolution: Fixed Votes: 9
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to CDV-112 Sharing classes between different cla... Closed
Roadmap
Fix In Branch:
trunk
Fixed In Revision: 11883

 Comments   
Comment by Walter Harley [ 25/Feb/09 ]

Fixed in trunk, mostly with change 11812, some additional support in 11883.

To share classes between web apps, use config similar to the following:

<application>
<dso>
<app-groups>
<app-group name="ab">
<web-application>contexta</web-application>
<web-application>contextb</web-application>
</app-group>
</app-groups>
</dso>
</application>

In addition to web apps, any registered loader can be shared by naming it explicitly; for instance, the standard system loader can be shared:

<application>
<dso>
<app-groups>
<app-group name="webAndPojo">
<web-application>contexta</web-application>
<named-classloader>Standard.system</named-classloader>
</app-group>
</app-groups>
</dso>
</application>

To find classloader names, enable named-classloader debugging:

<clients><dso><debugging><runtime-logging>
<named-loader-debug>true</named-loader-debug>
</runtime-logging></debugging></dso></clients>

Tests are in tim-session-system-tests: AppGroupTest, AppGroupNSTest, AppGroupWebAndPojoTest, AppGroupWebAndPojoNSTest. The reason the tests are there is because container TIMs are needed to test the web-application support.

Note that DSO client tests that use IsolationClassLoader are able to share classes with DSO apps spawned out of process without any custom app-groups config, because IsolationClassLoader is special-cased and treated as if it was in the same app-group as the standard system loader by default.

Comment by Walter Harley [ 25/Feb/09 ]

Eh, I probably resolved this too soon. The core code changes have been made and support has been implemented in tomcat and (thus) glassfish, but other containers haven't yet been completed; Tim is working on this. Assigning to him.

Comment by Tim Eck [ 02/Mar/09 ]

This is done with the exception of Webshere--CE. I opened another item (DEV-2485) to cover that remaining work

Comment by nadeem ghani [ 10/Mar/09 ]

verified with trunk versions of exam and examonitor and TC

Comment by Walter Harley [ 16/Mar/09 ]

The spec for this feature is attached to http://jira.terracotta.org/jira/browse/RMP-278, and the feature is fully detailed in the product docs (which may not yet be publicly available). There are a number of restrictions that should be noted; this bug report is NOT the full spec of the feature.

The most important restriction is that it is NOT possible to share data between two applications deployed to the same physical VM (ie the same TC node). The tc-config files for all nodes can be identical (thus it is still possible to get the configuration from the L2) but the applications themselves cannot be in the same VM.

The reason for this restriction is that we currently have no way to duplicate objects on a single VM; thus, a single object ID can only refer to a single POJO instance, whose classloader will therefore be wrong for one or the other of the sharing applications.





[CDV-271] Annotation support for Locks, includes by matching on what ever annotations they want. Created: 22/May/07  Updated: 18/Jun/07  Resolved: 31/May/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: Configurator, DSO:L1
Affects Version/s: None
Fix Version/s: 2.4-stable0

Type: New Feature Priority: 2 Major
Reporter: Steve Harris Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive mylar-context.zip    
Issue Links:
Duplicate
is duplicated by CDV-274 Annotation support in method-expression Closed
Related
Fix In Branch:
trunk

 Description   

Turns out that when we did subtype matching we did 99 percent of the work to get annotations working such that someone can specify an annotation to match on instead of a pattern. Fill in the last one percent.



 Comments   
Comment by Eugene Kuleshov [ 23/May/07 ]

Mylar context

Comment by Eugene Kuleshov [ 30/May/07 ]

I've added tests for functionality in description. So, I think it is.
Though I need to add some tests for matching methods for DMI, but they probably should go under separate issue.

Comment by Eugene Kuleshov [ 31/May/07 ]

Annotations for class includes, method locks and dmi should work in trunk now. Added tests for dso and config loader.





[CDV-269] Incompatible change in StandardDSOClientConfigHelper Created: 22/May/07  Updated: 20/Jun/07  Due: 05/Jul/07  Resolved: 20/Jun/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: trunk-nightly
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Kenney Westerhof Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 2.4

 Description   

The methd StandardDSOClientConfigHelper.addCustomAdapter has changed it's method signature from void (in 2.3.0) to boolean (in trunk).

I compiled a new module against trunk and ran it against 2.3.0 which gave me

Caused by: java.lang.NoSuchMethodError: com.tc.object.config.StandardDSOClientConfigHelper.addCustomAdapter(Ljava/lang/String;Lcom/tc/object/bytecode/ClassAdapterFactory;)Z
	at com.neonics.container.terracotta.ContainerActivator.addLoaderAdapters(ContainerActivator.java:37)

This may be a well-known incompatibility but it is a problem for backwards compatibility for new modules.
Just thought I'd mention this.



 Comments   
Comment by Geert Bevin [ 20/Jun/07 ]

Seems this API change is not used anywhere, it merely is reflected to the inner logic of the method. Reverted return type to void and adapted the javadoc for the method.





[CDV-256] *..* include pattern not currently functional under IBM JDK Created: 04/May/07  Updated: 24/Sep/07  Resolved: 18/Jun/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: trunk-nightly

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: GZip Archive ibm.tar.gz     Zip Archive mylar-context.zip    
Issue Links:
Related
relates to CDV-181 RMP: IBM Websphere AS Closed
relates to CDV-188 RMP: IBM JRE Closed
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

There is more than one problem here.

The first is that trying to load the "SHA" message digest in SerialVersionUIDAdder ends up calling back into itself (since the implementation classes are loaded by the extension loader if I recall correctly). Anyway, the resullt is StackOverflow.

I started working on a solution that tries to prevent cycles which gets one further, but then I get a unexplained VM exit (at least when I try to start WAS). Excluding "org.eclipse.osgi..*" gets rid of the problem, but that doesn't narrow it down too far. I'm going to attach the code just for good measure. There is also an issue with the System.err.println() in AbstractClassDumper that manifests under Websphere AS since it is trying to swap out System.out at some point in time.



 Comments   
Comment by Eugene Kuleshov [ 06/Jun/07 ]

I've removed use of JCE's digest.

Comment by Nathaniel Harward [ 18/Jun/07 ]

The configurator was failing because of this, and now it seems to work ok. The System.out.println() is not really an issue, it just goes to the WAS log instead of the console – if this becomes a problem for someone (I seriously doubt it) we can address it then.





[CDV-248] Can't Compile Java 5 source in JSP with Tomcat 5.5 Created: 01/May/07  Updated: 04/Jun/07  Resolved: 03/May/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.4-stable0

Type: Bug Priority: 2 Major
Reporter: Ron Bodkin Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tomcat 5.5.23, Java 1.5.0_09


Severity: 1 Down/unusable, workaround available
Fix In Branch:
trunk

 Description   

Our application uses Java 5 syntax in JSPs and is hitting problems when running with Terracotta but works normally. For example this code:

HashMap<String,Long> times = (HashMap<String,Long>)request.getAttribute("timings");

long totalTime = System.currentTimeMillis() - times.remove("total time");

Results in a compiler error:

An error occurred at line: 35 in the jsp file: /footer.jsp
Generated servlet error:
The operator - is undefined for the argument type(s) long, Object

If I load a JSP on Tomcat without TC, then restart with TC it works fine, i.e., the bug is solely when compiling the JSP. Eugene believes that the TC bootjar has lost the generic parameter information javac needs so it doesn't know that times.remove is a Long - it has only the raw type so it thinks it's an Object.

Work-around options (to be tested):

  • plug in ant to compile JSPs forking javac and set the bootstrap path to the uninstrumented classes
  • precompile JSPs


 Comments   
Comment by Steve Harris [ 01/May/07 ]

Tim can you take a look at this?

Comment by Eugene Kuleshov [ 01/May/07 ]

It seems like javac see HashMap class from the bootjar that we put in there after renaming from HashMapTC.

Because HashMapTC is compiled with 1.4 it don't have generics signatures and as a result javac can't do type inference and unbox to long value (it thinks that collection has raw Object types). So, we need to put "signature" values for all methods that HashMapTC overwrite from the original HashMap class. We can hardcode those values in the bootjar tool, or maybe less preferable - maintain separate version of HashMapTC for Java 5.

Comment by Eugene Kuleshov [ 01/May/07 ]

To clarify, this particular error don't really have much todo with jsp compilation. One would hit into it when running javac compiler anywhere with dso bootjar.

Comment by Steve Harris [ 01/May/07 ]

Is this something difficult to fix? Should we have antonio jump on it or is this something you can do?

Comment by Eugene Kuleshov [ 01/May/07 ]

I'll fix this. It should be reasonable trivial.

Comment by Eugene Kuleshov [ 03/May/07 ]

Fix is in trunk now. Added test case into ParameterizedTypesTest

Comment by Fiona OShea [ 30/May/07 ]

verify that test works and bug is fixed

Comment by Hung Huynh [ 30/May/07 ]

verified





[CDV-244] Serialization of shared objects fails to resolve reference fields Created: 26/Apr/07  Updated: 26/Sep/08  Resolved: 16/Sep/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: 2.7.0-stable1
Fix Version/s: 2.7.0

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by CDV-736 SerializationUtils (ObjectOutputStrea... Closed
Related
is related to CDV-907 HashMap Serialization can have unreso... Closed
is related to CDV-863 Using CHM with spring web-flow gives NPE Closed
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk, 2.7
Fixed In Revision: 10044

 Description   

From the forums: http://forums.terracotta.org/forums/posts/list/0/226.page

If a shared object is serialized, it possible to observe unresolved reference values. I believe the reason for this is that field values are read using sun.misc.Unsafe.getObject(..). Specifically in java.io.ObjectStreamClass$FieldReflector.getObjFieldValues(). This method of reading field data will bypass the DSO mechanics for resolving fields.

I don't think fields that are DSO literal types are affected since they are never unresolved.

I'm not sure about logical collections – although I guess they are okay since they implement readObject/writeObject in terms of their iterators which do flow though DSO goodness.



 Comments   
Comment by Tim Eck [ 11/Sep/08 ]

I think should be fixed in trunk now as of rev 10044

Comment by Scott Bale [ 15/Sep/08 ]

Looks like still a problem at least for clustered HashMap instances. With Tim's help I've duplicated Himadri's problem by adding to the system test that Tim wrote for this issue.

Comment by Scott Bale [ 16/Sep/08 ]

similar Serialization issue, both affect Lassen Exam caching

Comment by Scott Bale [ 16/Sep/08 ]

Alex and I decided there should really be a new JIRA issue, because it is really a new (albeit related) problem (CDV-907) that has been found. Tim's fix for this issue is fine and needs to be in 2.7 branch.

Comment by Hung Huynh [ 19/Sep/08 ]

test existed.





[CDV-243] ConcurrentHashMap blows up if the key is a java.lang.Class Created: 24/Apr/07  Updated: 04/Jun/07  Resolved: 26/Apr/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.4-stable0

Type: Bug Priority: 2 Major
Reporter: Steve Harris Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

Take a java.util.concurrent.ConcurrentHashMap and try to do a
put(MyClass.class, "this is a test");

you get this:

java.lang.ClassCastException: java.lang.Class
at com.tc.object.bytecode.ManagerImpl.shareObjectIfNecessary(ManagerImpl.java:548)
at com.tc.object.bytecode.ManagerUtil.shareObjectIfNecessary(ManagerUtil.java:132)
at java.util.concurrent.ConcurrentHashMap.__tc_hash(ConcurrentHashMap.java)
at java.util.concurrent.ConcurrentHashMap.__tc_hash(ConcurrentHashMap.java)
at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:848)
at com.tctest.ConcurrentHashMapTestApp.testPut1(ConcurrentHashMapTestApp.java:62)
at com.tctest.GenericTestApp.runMethod(GenericTestApp.java:144)
at com.tctest.GenericTestApp.runOp(GenericTestApp.java:138)
at com.tctest.GenericTestApp.doMutate(GenericTestApp.java:104)
at com.tctest.GenericTestApp.runTest(GenericTestApp.java:69)
at com.tctest.runner.AbstractErrorCatchingTransparentApp.run(AbstractErrorCatchingTransparentApp.java:29)
at com.tc.simulator.container.ApplicationRunner.run(ApplicationRunner.java:43)
at java.lang.Thread.run(Thread.java:613)

End error contexts.



 Comments   
Comment by Antonio Si [ 26/Apr/07 ]

Add a test case in ConcurrentHashMapTest.

Comment by Hung Huynh [ 30/May/07 ]

verified





[CDV-241] Make ManagerUtil a separate jar that can be compiled against Created: 24/Apr/07  Updated: 24/Sep/07  Resolved: 17/Sep/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: 2 Major
Reporter: Steve Harris Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones CDV-327 Jars that external implementations de... Closed
Dependency
Related
Fix In Branch:
trunk

 Description   

Would be nice if we moved out stuff that can be compiled against from the tc.jar ManagerUtil is an example



 Comments   
Comment by Juris Galang [ 17/Sep/07 ]

This belongs to the tc-compile API jar (see DEV-327)

Comment by Juris Galang [ 17/Sep/07 ]

A small correction: this issue relates to DEV-327
Marking it as resolve for now, the tc-compile API jar includes this class.

Comment by Juris Galang [ 17/Sep/07 ]

grrr... CDV-327!!!





[CDV-238] *..* include causes ClassCastException with jetty 6.1 Created: 23/Apr/07  Updated: 27/Jul/12  Resolved: 23/Apr/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.4.0

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Issue Review Board
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

Use .. include and fire up a DSO enabled Jetty, you'll get this

java.lang.ClassCastException: java.lang.String
at org.mortbay.xml.XmlConfiguration.set(XmlConfiguration.java:312)
at org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:237)
at org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:203)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:919)
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.mortbay.start.Main.invokeMain(Main.java:183)
at org.mortbay.start.Main.start(Main.java:497)
at org.mortbay.start.Main.main(Main.java:115)



 Comments   
Comment by Tim Eck [ 23/Apr/07 ]

This is because com.tc.object.bytecode.Manageable interface declares an accessible static field named "TYPE". It is not important to have this field declared on this interface and it should be moved (probably to BytecodeUtil)





[CDV-211] research isPhysicallyInstrumented() use and abuse in ConcurrentHashMap and others Created: 06/Apr/07  Updated: 12/May/08  Resolved: 27/Apr/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.6-stable4

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Severity: 3 Feature failure (but usable), workaround available

 Description   

ConcurrentHashMap$HashIterator, ConcurrentHashMap$Segment, RegularEnumSet$EnumSetIterator, CyclicBarrier, Collections$UnmodifiableList$1, java.awt.Rectangle all contains calls to ManagerUtil.isPhysicallyInstrumented.

My guess is that is happening because the regular DSO class instrumentation is trying to protect against NoSuchMethodErrors around field access in other classes. For these classes in the boot jar, I would think the field access doesn't need to be paranoid.

We have a report of this method showing up in profiling of ConcurrentHashMap



 Comments   
Comment by Geert Bevin [ 25/Apr/08 ]

Tim, is this something you have already addressed in all the CHM and HashMap changes that you have done over the last months?

Comment by Tim Eck [ 25/Apr/08 ]

Yeah, I did clean some of this stuff up recently, but it is yet to be checked in. I'll take this ticket





[CDV-205] Deadlock occur on lock upgrade Created: 02/Apr/07  Updated: 26/Sep/08  Resolved: 26/Sep/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: trunk-nightly

Type: Bug Priority: 2 Major
Reporter: Antonio Si Assignee: Issue Review Board
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Severity: 3 Feature failure (but usable), workaround available
Fix In Branch:
trunk

 Description   

The lock upgrade test, LockUpgrade1Reads1UpgradesTest, result in deadlock. Deadlock could occur if there is more than one threads within a single JVM, one doing a lockupgrade and another one acquiring a readlock as follows:

Thread 1 doing a thread upgrade as follows:

T1: DSO MonitorEnter with Read
T2: JVM MonitorEnter
T3: DSO MonitorEnter with Write
T4: JVM MonitorEnter

Thread 2 doing a read only:

T1.5 (between T1 and T2): Dso MonitorEnter with Read
T2.5 (between T2 and T3): JVM MonitorEnter

The test is currently disabled.



 Comments   
Comment by Antonio Si [ 11/Oct/07 ]

This is no longer an issue since lock upgrade is no longer supported.





[CDV-202] TCRuntime uses the 1.4 memory manager in IBM JDK 1.5 Created: 29/Mar/07  Updated: 27/Mar/08  Resolved: 22/Jun/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.6-stable0

Type: Bug Priority: 3 Minor
Reporter: Nathaniel Harward Assignee: Hung Huynh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
is dependency of CDV-201 Tuning and re-factoring for IBM JDK s... Open
Severity: 3 Feature failure (but usable), workaround available

 Description   

The 1.5 IBM JDK has different memory beans, and the 1.5 memory manager implementation needs to be adjusted or another instance created to support them.



 Comments   
Comment by Geert Bevin [ 22/Jun/07 ]

Fixed a while ago, created an IBM 1.5 specific memory manager.





[CDV-199] Problem With Subclass of HashMap Created: 28/Mar/07  Updated: 27/Jul/12  Resolved: 28/Mar/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.3

Type: Bug Priority: 2 Major
Reporter: Ron Bodkin Assignee: Tim Eck
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Sun Java 5 VM


Issue Links:
Related
is related to CDV-171 ArrayList subclass picks up extra ele... Closed
Severity: 1 Down/unusable, workaround available

 Description   

When I execute the constructor for this class in a TerraCotta-enabled JVM, it fails to add elements. The same code works as expected on a normal JVM without TerraCotta instrumentation:

public class IntArrayMapImpl extends HashMap<Integer, Map<Integer,int[]>> {

private int buckets = 100;

public IntArrayMapImpl() {
for (int i=0; i<buckets; i++)

{ put(i, new HashMap<Integer,int[]>()); // data is not added here if TC is involved }


}
}



 Comments   
Comment by Ron Bodkin [ 28/Mar/07 ]

A workaround here is to delegate to a synchronized private method in the constructor. This is a bit awkward (at least it breaks the expectations of the JMM where you don't need to synchronize during initialization):

public class IntArrayMapImpl extends HashMap<Integer, Map<Integer,int[]>> {

private int buckets = 100;

public IntArrayMapImpl()

{ init(); }

private synchronized void init() {
for (int i=0; i<buckets; i++)

{ put(i, new HashMap<Integer,int[]>()); }


}

Comment by Steve Harris [ 28/Mar/07 ]

can you look at this

Comment by Tim Eck [ 28/Mar/07 ]

I think this is already fixed in 2.3 branch and trunk.

In 2.2.1 stable 2, I don't think all of the put() calls ignored, I would think the there would be one mapping retained (99 --> HashMap())

I'll look into what was fixed in the recent branch and potentially back port the fix

Comment by Tim Eck [ 28/Mar/07 ]

I mispoke, there are to be no more 2.2.1 releases. The upcoming 2.3 release will resolve this issue

Comment by Tim Eck [ 28/Mar/07 ]

this is already fixed (thanks to Antonio)

Comment by Ron Bodkin [ 28/Mar/07 ]

Yes, we see one mapping not 100. Thanks for the update. At least we have a workaround for 2.2





[CDV-196] update ASM framework to the latest release Created: 26/Mar/07  Updated: 25/Jun/07  Resolved: 28/Mar/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1, DSO:L2, X-AspectWerkz, X-Common Code
Affects Version/s: None
Fix Version/s: 2.4-stable0

Type: New Feature Priority: 2 Major
Reporter: Eugene Kuleshov Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

LOE: .5

 Description   

Currently com.tc.asm.* packages are taken from ASM 2.x release. We need to update to ASM 3.x to pickup latest fixes, performance improvements and new API.



 Comments   
Comment by Steve Harris [ 26/Mar/07 ]

HOw much work is this? Can we squeeze it into noriega?

Comment by Eugene Kuleshov [ 26/Mar/07 ]

Should be few hours at most. I can do it this week if Nat isn't panning anything else for me.

Comment by Eugene Kuleshov [ 28/Mar/07 ]

Committed to trunk

Comment by Fiona OShea [ 11/Jun/07 ]

can you verify that this is indeed completed, then close out?





[CDV-195] Possible bug where on-load bean shell script does not execute, when object is faulted during the course of distributed method invocation, Created: 23/Mar/07  Updated: 27/Jul/12  Resolved: 28/Mar/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.3

Type: Bug Priority: 2 Major
Reporter: Sreenivasan Iyer Assignee: Alex Voskoboynik
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 1 Down/unusable, workaround available

 Description   

See http://forums.terracotta.org/forums/posts/list/177.page
especially the last portion of the thread that describes the issue.



 Comments   
Comment by Tim Eck [ 23/Mar/07 ]

Alex and can't seem to find anything wrong with on-load as it pertains to objects involved in DMI.





[CDV-176] reading outside the bounds of managed array fails to do use the resolveLock monitor correctly Created: 21/Mar/07  Updated: 27/Jul/12  Resolved: 21/Mar/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.3

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Issue Review Board
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available

 Description   

I actually don't know what is wrong yet, but running this code where "array" is a managed array, you'll get an IllegalMonitorStateException.

String[] array = new String[5];

try {
for (int i = 0; i < 10; i++)

{ System.err.println(i + ": " + array[i]); }

} catch (ArrayIndexOutOfBoundsException ia)

{ System.err.println("caught exception"); }

 Comments   
Comment by Tim Eck [ 21/Mar/07 ]

This appears to be the VM checking the balance of lock acquires/releases made a thread within the context of method invocation

We are causing a violation to rule (1) from the VM spec (http://java.sun.com/docs/books/jvms/second_edition/html/Threads.doc.html#22500):

Implementations of the Java virtual machine are permitted but not required to enforce both of the following two rules guaranteeing structured locking.

Let T be a thread and L be a lock. Then:

1. The number of lock operations performed by T on L during a method invocation must equal the number of unlock operations performed by T on L during the method invocation whether the method invocation completes normally or abruptly.

2. At no point during a method invocation may the number of unlock operations performed by T on L since the method invocation exceed the number of lock operations performed by T on L since the method invocation.





[CDV-171] ArrayList subclass picks up extra elements Created: 13/Mar/07  Updated: 27/Jul/12  Resolved: 14/Mar/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.3

Type: Bug Priority: 1 Critical
Reporter: Tim Eck Assignee: Antonio Si
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to CDV-199 Problem With Subclass of HashMap Closed
Severity: 3 Feature failure (but usable), workaround available

 Description   

There is a class like this one in weblogic, which if instrumented will make the server fail to start (DEV-511)

Add this class to GenericListTest (the assertion error will go off)

private static class AL2 extends ArrayList {

int i = 3;

AL2() {
Set s = new HashSet();
s.add("test");
new ArrayList(s);
if (size() != 0)

{ throw new AssertionError(); }

}
}



 Comments   
Comment by Tim Eck [ 14/Mar/07 ]

can you look at this?

Comment by Antonio Si [ 14/Mar/07 ]

Add a test case in GenericListTest.





[CDV-169] Using Array.set() (reflection) to set an array element to null throws IllegalArgumentException Created: 12/Mar/07  Updated: 27/Jul/12  Resolved: 12/Mar/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Tim Eck
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available

 Description   

It doesn't matter if the target array is shared or not. The check in ManagerImpl.set(..) is not correct for null values

java.lang.IllegalArgumentException
at com.tc.object.bytecode.ManagerUtil.set(ManagerUtil.java:249)
at java.lang.reflect.Array.set(Array.java)

The message could include some details too






[CDV-168] Add source to config modules... Created: 12/Mar/07  Updated: 15/Mar/07  Resolved: 15/Mar/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: 3 Minor
Reporter: Steve Harris Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Each config module jar could also contain the source to make it easier to make quick changes to a module and rebuild.



 Comments   
Comment by Fiona OShea [ 12/Mar/07 ]

How difficult (and time consuming) would this be?

Comment by Nathaniel Harward [ 12/Mar/07 ]

No idea, it involves working with the build system so I'm inclined to say unless we really need it for something to just not entertain this until the conversion to Maven is done.

Comment by Nathaniel Harward [ 14/Mar/07 ]

Jason, any comment on this as to how difficult it might be?

Comment by jvoegele [ 15/Mar/07 ]

Done in revision 1824





[CDV-167] Add ability to check for dso version in config modules. Created: 12/Mar/07  Updated: 27/Jul/12  Resolved: 13/Mar/08

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.6.0

Type: New Feature Priority: 2 Major
Reporter: Steve Harris Assignee: Issue Review Board
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to CDV-636 TC Version Check of TIM Closed
Fix In Branch:
trunk
Fixed In Revision: rev 7467 (trunk)

 Description   

When someone writes a config module it might rely on certain features of a given version of the dso platform. We should be able to check against that version.



 Comments   
Comment by Nathaniel Harward [ 14/Apr/07 ]

I think we should align the value of the "Bundle-Version" MANIFEST.MF header in "modules-common" to the DSO release version, so in trunk it should be 2.4.0.

Comment by Juris Galang [ 01/May/07 ]

This is a bit funky. We should be able to mix and match bundle versions with TC versions... Let's flesh it out some more.

Comment by Nathaniel Harward [ 02/May/07 ]

I respectfully retract my comment above about matching the modules-common version with the system release version. Perhaps we should have the following class (or something like it) in modules-common instead, which modules can interrogate (in addition to specifying version dependencies on modules-common itself):

package org.terracotta.modules;

public final class DsoSystem {

public static String getVersionString()

{ // Read a build-system-generated resource with this value, hard code it, whatever... return "...."; }

}

That way if I have a dependent module that works with releases 2.3, 2.4 and 2.5 but not 2.6 (say versions 1.0.0, 1.1.0 and 2.0.0 of modules-common respectively), but does something special for 2.4 I can do something like this:

META-INF/MANIFEST.MF:
Import-Package: org.terracotta.modules.DsoSystem;version="[1.0.0, 2.0.0)"

Config module code:
// At this point we know we are in the 2.3 - 2.5 release version because of the import statement in MANIFEST.MF
....
if (DsoSystem.getVersionString().matches("^2.4.*$"))

{ // Do something special for 2.4.... }

Just thinking/writing out loud here – any opinions or suggestions?

Comment by Nathaniel Harward [ 02/May/07 ]

A few corrections to my "code" above:

META-INF/MANIFEST.MF (should not have included specific class, only package):
Import-Package: org.terracotta.modules;version="[1.0.0, 2.0.0)"

Config module code:
....
import org.terracotta.modules.DsoSystem;
....
....rest of example above....

Comment by Steve Harris [ 02/May/07 ]

I can never make up my mind about what I think is best in this situation?
"Simplicity" by just returning a version string and leaving the logic in the app.
or
"Simplicity" by having the app pass the current version into a method in the module
and let it return whether it is compatible.
decisions decisions

Comment by Nathaniel Harward [ 02/May/07 ]

The problem with passing the version into a method in the module is that you still have the same versioning dependencies problem – the module has to implement some interface we create and would package up as part of modules-common. Also, the app still has to perform logic in the code, it would just be in a forced interface method (which might be awkward) rather than an external method call. It seems to me that since this is a style issue not in our code but in the config modules, that rather than complicate our code to look for some interface in some unspecified set of classes in every module (and force a potentially awkward interface on all module writers), the module can just ask for the version if it needs to do something special.

Ideally this would never happen anyway and the whole thing could be taken care of with the Import-Package (+version) property in MANIFEST.MF, but if you have the odd case like I described above you could resort to coding around something by calling DsoSystem.getVersionString() (or whatever it will be).

Comment by Juris Galang [ 13/Mar/08 ]

CDV-636: TC Version Check of TIM
CDV-167: Add ability to check for dso version in config modules.
DEV-1128: TIMs need manifest attribute specifying supported Terracotta version

Code and tests to check for required TC version for TIM's.
A new attribute named Terracotta-RequireVersion is added into the manifest of all TIM's that comes packaged with the kit. When TC installs a TIM at runtime, this attribute's vvalue is compared against TC's version number and appropriate action is taken (see CDV-636 for details)





[CDV-164] Non-portable object dumper feature (new in Moraga) susceptible to OutOfMemoryError Created: 06/Mar/07  Updated: 27/Jul/12  Resolved: 15/Mar/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.3

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Tim Eck
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The new object dumper buffers all of it's output in memory such that it can be logged as a single item (which means it will be contiguous in the log file). This implementation, coupled with the fact that it prints all literal values, and traverse already shared objects means that it can consume large amounts of heap (with large object graphs).

Perhaps the traversing policy should be updated, and/or the logging either done to separate file (and thus no buffering), or it should be logged line by line in the log file (allowing for the possibility of other log messages interleaved in the dump)



 Comments   
Comment by Tim Eck [ 15/Mar/07 ]

change this stuff to log each part of the graph as a single log line. This means the graph can be interleaved with other logging that happens concurrently. Luckily the thread name prefix should let one stitch it back together if need





[CDV-162] subclass of ArrayList w/ field being instrumented, produces VerifyError Created: 05/Mar/07  Updated: 27/Jul/12  Resolved: 05/Mar/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.3

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Antonio Si
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File GenericListTestApp.SubList.class    
Severity: 3 Feature failure (but usable), workaround available

 Description   

Including this class, produces this verify error:
java.lang.VerifyError: (class: com/tctest/GenericListTestApp$SubList, method: removeRange signature: (II)V) Bad access to protected data

private static class SubList extends ArrayList {
private Vector v;

public void removeRange(int fromIndex, int toIndex)

{ super.removeRange(fromIndex, toIndex); }

}



 Comments   
Comment by Antonio Si [ 05/Mar/07 ]

Add new test cases in GenericListTest.





[CDV-161] subclass of subclass of logical collection produces UnsupportedOperationException Created: 05/Mar/07  Updated: 27/Jul/12  Resolved: 06/Mar/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.3

Type: Bug Priority: 2 Major
Reporter: Tim Eck Assignee: Antonio Si
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File GenericListTestApp.SubList.class     File GenericListTestApp.SubSubList.class    
Severity: 3 Feature failure (but usable), workaround available

 Description   

adding in the following two classes to GenericListTest and try to use a shared SubSubList instance

private static class SubList extends ArrayList

{ // }

private static class SubSubList extends SubList { // }

java.lang.UnsupportedOperationException
at com.tc.object.TCObjectPhysical.logicalInvoke(TCObjectPhysical.java:116)
at com.tc.object.bytecode.ManagerImpl.logicalInvoke(ManagerImpl.java:205)
at com.tc.object.bytecode.ManagerUtil.logicalInvoke(ManagerUtil.java:131)
at java.util.ArrayList.add(ArrayList.java)
at com.tctest.GenericListTestApp.testAdd(GenericListTestApp.java:337)
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 com.tctest.GenericTestApp.runMethod(GenericTestApp.java:152)
at com.tctest.GenericTestApp.runOp(GenericTestApp.java:143)
at com.tctest.GenericTestApp.doMutate(GenericTestApp.java:112)



 Comments   
Comment by Antonio Si [ 06/Mar/07 ]

Add a test case in GenericListTest.





[CDV-160] org.apache.derby.iapi.services.io.FormatableProperties seems to be instrumented incorrectly Created: 05/Mar/07  Updated: 08/Jul/11  Resolved: 06/Mar/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 3.5.2

Type: Bug Priority: 2 Major
Reporter: Antonio Si Assignee: Antonio Si
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: 3 Feature failure (but usable), workaround available
Terracotta Target:
3.5.2

 Description   

This class is used by Geronimo. This class is a subclass of java.util.Property. It has a field defined and modify a protected field. This class seems to be instrumented incorrectly.



 Comments   
Comment by Antonio Si [ 06/Mar/07 ]

Add a test case in GenericMapTest.





[CDV-159] Dumphierarchy java option does not appear to dump needed stack trace in all cases. Created: 03/Mar/07  Updated: 27/Jul/12  Resolved: 05/Mar/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: 2 Major
Reporter: Sreenivasan Iyer Assignee: Issue Review Board
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Dumphierarchy java option does not appear to dump needed stack trace in all cases.


Severity: 3 Feature failure (but usable), workaround available

 Description   

the tc.dumphierarchy=true system property is invaluable to identify wht to mark as transient upon encountering a non portable exception. However in certain cases, it does not dump the object graph traversal making it quite hard to guess what needs to be transient.



 Comments   
Comment by Tim Eck [ 03/Mar/07 ]

this feature (in it's 2.2.1 form) has been removed for Moraga. The constraints and limitations of the previous version should be gone. Don't see too much value in hacking in 2.2.1





[CDV-153] Broad instrumentataion with Geronimo 1.1.1 causes issues (with 2.2.1 stable 2 at least) Created: 01/Mar/07  Updated: 27/Jul/12  Resolved: 05/Mar/07

Status: Closed
Project: Community Development (Terracotta Server)
Component/s: DSO:L1
Affects Version/s: None
Fix Version/s: 2.3