[Logo] Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
[Expert]
Messages posted by: tekkie00  XML
Profile for tekkie00 -> Messages posted by tekkie00 [55] Go to Page: 1, 2, 3, 4 Next 
Author Message
I understand that there is an outstanding bug related to using Jetty Continuations and built-in session clustering, as described here:

https://jira.terracotta.org/jira/browse/FORGE-430%3Bjsessionid=23CCA8A2118281A5D9831BDB6DAED96D?page=com.atlassian.jira.plugin.system.issuetabpanels%3Achangehistory-tabpanel

To the Terracotta folks -- would there be a reasonable workaround - perhaps a patch that I can make to get this working? We are in a critical stage and this is breaking our HTTP session cluster strategy...

Also, any thoughts as to why this is occurring in the first place?
oops, cometd/bayeux lives at the servlet context layer, not session .... so i think what is going on ..is that an object with a reference to the HTTPSession is being registered to the JSONRPCBridge, and attempted to be clustered.

i'll see if i can mark this attribute transient.
hmm, this is proving to be more difficult than I had thought.

i have instrumented the relevant JSONRPC classes ..and have seemingly moved on to issues dealing w/ clustering Cometd/Bayeux .... since this information is retrieved at the HTTPSession layer.

i've looked at http://blogs.webtide.com/gregw/entry/clustering_cometd_with_terracotta

but still haven't been able to run it successfully.

i get the following error:
Code:
 1) Reconfigure to include the unshareable classes
    * edit your tc-config.xml file
    * locate the <dso> element
    * add this snippet inside the <dso> element
 
        <instrumented-classes>
          <include>
            <class-expression>org.mortbay.jetty.servlet.Context$SContext</class-expression>
          </include>
          <include>
            <class-expression>org.mortbay.jetty.handler.ContextHandler$SContext</class-expression>
          </include>
        </instrumented-classes>
 
    * if there is already an <instrumented-classes> element present, simply add
      the new includes inside it
 


but something tells me that i might be going down a rat hole here...

any suggestions?
So, I basically need to set a JSONRPCBridge instance to the HTTPSession, although I am not aware of the portability of JSONRPCBridge. In the case that this object is not portable, how can I bypass this when session clustering is enabled?
Is it possible to mark a Session object as transient? I can't seem to get this behavior working.
Jetty version is 6.1.11
Code:
 <?xml version="1.0" encoding="UTF-8"?>
 <con:tc-config xmlns:con="http://www.terracotta.org/config">
   <system>
 	<configuration-model>production</configuration-model>
   </system>
   <servers>
     <server host="127.0.0.1">
       <dso-port>9510</dso-port>
       <jmx-port>9520</jmx-port>
       <data>${server-data}</data>
       <logs>${server-logs}</logs>
       <statistics>${server-stats}</statistics>
       <dso>
         <persistence>
           <mode>permanent-store</mode>
         </persistence>
       </dso>
     </server>
   </servers>
   <clients>
   	<modules>
   	  <module name="tim-apache-collections-3.1" version="1.0.2"/>
   	  <module name="tim-cglib-2.1.3" version="1.3.2"/>
   	  <module name="tim-annotations" version="1.3.2" />
   	  <module name="tim-concurrent-collections" version="1.1.2" />
   	  <module name="tim-hashtable" version="2.4.2" />
   	  <module name="tim-synchronizedcollection" version="2.4.2" />
   	  <module name="tim-synchronizedmap" version="2.4.2" />
   	  <module name="tim-synchronizedset" version="2.4.2" />
   	  <module name="tim-synchronizedsortedmap" version="2.4.2" />
   	  <module name="tim-synchronizedsortedset" version="2.4.2" />
   	  <module name="tim-pipes" version="2.0.0" />
   	  <module name="tim-masterworker" version="2.0.0" />
   	  <module name="tim-vector" version="2.4.2" />
   	  <module name="tim-jetty-6.1" version="1.3.0"/>
   	  <module name="tim-session-common" version="1.1.0"/>
   	  <module name="tim-map-evictor" version="1.1.2"/>
     </modules>
     <logs>${client-logs}</logs>
   </clients>
   <application> 
    <dso>
       <locks>
           <!-- proprietary lock definitions taken out -->
       </locks>
       <instrumented-classes>
           <!-- proprietary instr. definitions taken out -->
       </instrumented-classes>
       <roots>
           <!-- proprietary root definitions taken out -->
       </roots>     
       <web-applications>
       	<web-application>myWebApp</web-application>
       </web-applications> 
     </dso>
   </application>
 </con:tc-config>
 



I am seeing the error when Jetty is booted up. Again, the exception trace is

Code:
 java.lang.RuntimeException: java.lang.ClassNotFoundException: com.terracotta.session.WebAppConfig
 	at org.mortbay.terracotta.modules.jetty_6_1.adapters.SContextAdapter.addWebAppConfigMethods(SContextAdapter.java:67)
 	at org.mortbay.terracotta.modules.jetty_6_1.adapters.SContextAdapter.visitEnd(SContextAdapter.java:58)
 	at com.tc.asm.ClassReader.accept(ClassReader.java:1456)
 	at com.tc.asm.ClassReader.accept(ClassReader.java:420)
 	at com.tc.object.bytecode.hook.impl.DefaultWeavingStrategy.transformInternal(DefaultWeavingStrategy.java:344)
 	at com.tc.object.bytecode.hook.impl.DefaultWeavingStrategy.transform(DefaultWeavingStrategy.java:124)
 	at com.tc.object.bytecode.hook.impl.DSOContextImpl.preProcess(DSOContextImpl.java:168)
 	at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.defineClass0Pre(ClassProcessorHelper.java:665)
 	at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
 	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:316)
 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
 	at java.lang.Class.forName0(Native Method)
 	at java.lang.Class.forName(Class.java:164)
 	at org.mortbay.jetty.deployer.WebAppDeployer.class$(WebAppDeployer.java:190)
 	at org.mortbay.jetty.deployer.WebAppDeployer.scan(WebAppDeployer.java:212)
 	at org.mortbay.jetty.deployer.WebAppDeployer.doStart(WebAppDeployer.java:138)
 	at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
 	at org.mortbay.jetty.Server.doStart(Server.java:199)
 	at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
 	at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:977)
 	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:194)
 	at org.mortbay.start.Main.start(Main.java:512)
 	at org.mortbay.start.Main.main(Main.java:119)
 Caused by: java.lang.ClassNotFoundException: com.terracotta.session.WebAppConfig
 	at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
 	at java.security.AccessController.doPrivileged(Native Method)
 	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
 	at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
 	at java.lang.Class.forName0(Native Method)
 	at java.lang.Class.forName(Class.java:242)
 	at org.mortbay.terracotta.modules.jetty_6_1.adapters.SContextAdapter.addWebAppConfigMethods(SContextAdapter.java:65)
 


looks like its occuring during the WebAppDeployer phase.

any ideas?
I'm still getting a ClassNotFound on WebAppConfig. I have the tim-session-common module defined, so why is this not being picked up?
I am running into an error on Jetty bootstrap:

Code:
 Caused by: java.lang.ClassNotFoundException: com.terracotta.session.WebAppConfig
 	at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
 	at java.security.AccessController.doPrivileged(Native Method)
 	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
 	at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
 	at java.lang.Class.forName0(Native Method)
 	at java.lang.Class.forName(Class.java:242)
 	at org.mortbay.terracotta.modules.jetty_6_1.adapters.SContextAdapter.addWebAppConfigMethods(SContextAdapter.java:65)
 


I have this listed in my tc-config.xml

Code:
 <clients>
   	<modules>
   	  <module name="tim-apache-collections-3.1" version="1.0.2"/>
   	  <module name="tim-cglib-2.1.3" version="1.3.2"/>
   	  <module name="tim-annotations" version="1.3.2" />
   	  <module name="tim-concurrent-collections" version="1.1.2" />
   	  <module name="tim-hashtable" version="2.4.2" />
   	  <module name="tim-synchronizedcollection" version="2.4.2" />
   	  <module name="tim-synchronizedmap" version="2.4.2" />
   	  <module name="tim-synchronizedset" version="2.4.2" />
   	  <module name="tim-synchronizedsortedmap" version="2.4.2" />
   	  <module name="tim-synchronizedsortedset" version="2.4.2" />
   	  <module name="tim-pipes" version="2.0.0" />
   	  <module name="tim-masterworker" version="2.0.0" />
   	  <module name="tim-vector" version="2.4.2" />
   	  <module name="tim-jetty-6.1" version="1.3.0"/>
   	  <module name="tim-session-common" version="1.1.0"/>
   	  <module name="tim-map-evictor" version="1.1.2"/>
     </modules>
     <logs>${client-logs}</logs>
   </clients>
 


am i missing anything?

also - from the documentation, i'm not clear on what I need to do enable HTTP Session clustering.

is it required to have dso web-applications element defined in tc-config?
after successfully deploying my WAR within spring dmServer against a terracotta v2.7.3 server, i am hitting the dreaded named classloader error.

the server error is:
Code:
 java.lang.IllegalStateException: Classloader name not set, instances defined from this loader not supported in Terracotta (loader: com.springsource.server.osgi.framework.equinox.ServerBundleClassLoader)
 


however, i DO have the following in my bundle activator:
Code:
 static {
 NamedClassLoader ncl = (NamedClassLoader) ServerActivator.class.getClassLoader();
 ncl.__tc_setClassLoaderName("Tomcat.Catalina:localhost:/mywebapp");
 ClassProcessorHelper.registerGlobalLoader(ncl);
 }
 


is there anything that I am missing? it is worth noting here that the tomcat container within spring dmServer is managed as an osgi bundle - this may be the x-factor here, but i am not entirely sure since i don't quite know what Terracotta is doing under the hood for registering tomcat classloader integration.
hmm, looks like there is a missing autolock pattern that isn't declared for fillCapInfo(..) - i wonder if this can be related
Code:
Caused by: java.util.ConcurrentModificationException:
 *******************************************************************************
 Requested Object is missing : ObjectID=[1674402] Missing Oids = [ObjectID=[1674402]]
 *******************************************************************************
 
         at java.util.HashMap.lookUpIfNecessary(Unknown Source)
         at java.util.HashMap.lookUpAndStoreIfNecessary(Unknown Source)
         at java.util.HashMap.get(Unknown Source)
         at com.temboo.arcturus.capabilities.CapabilityFactoryImpl.__tc_wrapped_getChild(CapabilityFactoryImpl.java:245)
         at com.temboo.arcturus.capabilities.CapabilityFactoryImpl.getChild(CapabilityFactoryImpl.java)
         at com.temboo.arcturus.capabilities.CapabilityFactoryImpl.__tc_wrapped_getChildNames(CapabilityFactoryImpl.java:252)
         at com.temboo.arcturus.capabilities.CapabilityFactoryImpl.getChildNames(CapabilityFactoryImpl.java)
         at com.temboo.arcturus.capabilities.CapabilityFactoryImpl.fillCapInfo(CapabilityFactoryImpl.java:206)
         at com.temboo.arcturus.capabilities.CapabilityContainerImpl.fillCapInfo(CapabilityContainerImpl.java:370)
         at com.temboo.arcturus.capabilities.CapabilityFactoryImpl.fillCapInfo(CapabilityFactoryImpl.java:234)
         at com.temboo.arcturus.capabilities.CapabilityContainerImpl.fillCapInfo(CapabilityContainerImpl.java:370)
         at com.temboo.arcturus.capabilities.CapabilityContainerImpl.recursiveLookupCapInfoByElemType(CapabilityContainerImpl.java:425)
         at com.temboo.arcturus.capabilities.CapabilityContainerImpl.recursiveLookupCapInfoByElemType(CapabilityContainerImpl.java:436)
         at com.temboo.arcturus.capabilities.CapabilityContainerImpl.lookupCapInfoByElemType(CapabilityContainerImpl.java:417)
         at com.temboo.arcturus.capabilities.CapabilityContainerImpl.lookupCapInfoByElemType(CapabilityContainerImpl.java:410)
         at com.temboo.arcturus.web.twyla.jsonrpc.ProcessHelper.getRunningChoreoInstances(ProcessHelper.java:82)
         ... 24 more
 
 


and although the code is quite complex, it boils down to the following 3 methods ....

Code:
 public synchronized List<CapabilityInfo> fillCapInfo(...) {
      Set<String> names = getChildNames();
      for (String name : names) {
 	   Capability cap = getChild(name);
            ... //other logic here
       }
 
        return list;
 }
 
 protected synchronized T getChild(String name) {
 	return map.get(name);
 }
 
 protected synchronized Set<String> getChildNames() {
 	Set<String> filter = new HashSet<String>();
 	for (String s : map.keySet())
 		if (getChild(s) != null)
 			filter.add(s);
 	return filter;
 }
 



map is just an internal HashMap - and methods are synchronized.

anything obvious here?
thanks for the link. looks similar, but not sure if this is the same codepath. we're not using any caches.

i peeked into the HashMapTC impl and found the following code:
Code:
   private static Object lookUpIfNecessary(Object o) {
     if (o instanceof ObjectID) {
       try {
         return ManagerUtil.lookupObject((ObjectID) o);
       } catch (TCObjectNotFoundException onfe) {
         throw new ConcurrentModificationException(onfe.getMessage());
       }
     }
     return o;
   }
 


Looks like the CME is from this block.

When or how is it possible for a ManagerUtil.lookupObject to fail? Does this mean that objects aren't being persisted somehow? What is actually going on behind the scenes in this method?
Hi, upon upgrading to terracotta 2.7.3, i've run into a ConcurrentModificationException:

Code:
 Caused by: java.util.ConcurrentModificationException:
 *******************************************************************************
 Requested Object is missing : ObjectID=[1674402] Missing Oids = [ObjectID=[1674402]]
 *******************************************************************************
 
         at java.util.HashMap.lookUpIfNecessary(Unknown Source)
         at java.util.HashMap.lookUpAndStoreIfNecessary(Unknown Source)
         at java.util.HashMap.get(Unknown Source)
 


the version upgrade might just be pure coincidence, but i cannot spot any obvious fail-fast behavior that would throw such mod exception in the area of code where this is thrown. TC synchronized locks are also defined in the right places - as this code base has been working for a while now.

are there any known issues w/ tc hashmaps and CME? i've seen a few bug reports in JIRA regarding CME, but about more particular issues like transactionbatchwriters and lists.

any thoughts?
alas, i have figured it out.

thanks to your suggestion from your last post, i was able to experiment with the following setting (FRAMEWORK_SYSTEMPACKAGES_EXTRA didn't seem to fix it), but configMap.put(Constants.FRAMEWORK_BOOTDELEGATION, "sun.*,com.sun.*,com.tc.*") did the trick;

now, my bundles load successfully and i can actually share data from a terracotta shared root - all within an embedded Felix.

bootdelegation is noted in the felix documentation as a property to be modified with care, but this seemed to be the only way of getting things to work -- since it specifies a list of packages that should be made implicitly available to all bundles from the environment.

 
Profile for tekkie00 -> Messages posted by tekkie00 [55] Go to Page: 1, 2, 3, 4 Next 
Go to:   
Powered by JForum 2.1.7 © JForum Team