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.
|
|
|