Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

FWIW I get the same build problem building that tag after deleting my ~/.m2

from that exception is sounds zabbix is configured to assume the terracotta jmx server speaks JRMP.

If you're inputting a jmx service url to zabbix you might want to try something like:

service:jmx:jmxmp://1.2.3.4:9520

Where 1.2.3.4 is your terracotta server. You might potentially also need the jmxremote_optional jar from our kit

good luck

Can you post the exception stacktrace? From your description alone it sounds like maybe the Element you are put()'ing to the cache has a null key (which is not legal in general and will also give an NPE evaluating the attribute expression which references the null key)

I could certainly believe the request wrapping done by the terracotta valve could interact poorly with the code referenced there.

Without fully understanding what's going on with the requests in this path it's hard to know what it would take to make everything "work" here.

About the best I can say is to file this as a bug/enhancement at https://jira.terracotta.org/jira/browse/CDV

What tomcat version is? Just curious

I'd guess you do not have a dso-boot.jar in your -Xbootclasspath

I don't know of anything like this built into the library. You probably realize this, but you could certainly provide this functionality with a wrapper/decorator class on top of the cache instance.

Looks related to this:

http://www.eclipse.org/eclipse/development/porting/4.3/jdt-incompatibilities.html

I can't give you an official statement on the terracotta eclipse plugin, but it hasn't been maintained for quite a while and my guess is that it will remain that way indefinitely.

In theory an older eclipse version would let you install this plugin.

Is this jdk 7 per chance? Terracotta 3.7.x does not work with jdk7 and higher

that particular exception I think is a symptom of not shutting down any clustered caches before either shutting down your web container and/or undeploying your application. Take a look to see if your application is calling CacheManager.shutdown(). You might want to hook this up in a servlet context listener

The exception isn't harmful though in my opinion. I don't understand that it would be "crashing" anything

FWIW, I entered a bug into our database for someone to look into. Lets see what comes of it

I agree that that example looks incorrect. The <terracottaConfig> element should not be nested in the <cache> element. I'll forward this along to someone who can correct the site. thanks

I don't remember what the choices were before to tell you the truth, but I suspect that method was removed since there is only one strategy now (what I think used to be called DCV2).

Don't know what that second exception is about (the SPI class one). Looking at the attribute extractor you wrote though, I think for your first configuration you want to add .expression("value.getZipCode()") to your SearchAttribute. I'm not entirely sure how case is handled when you want a javabean style definition (ie. "zipcode" vs. "zipCode")

hope that helps.

Yeah, you need the slf4j-api jar, as well as one "binding" jar. You can read all about slf4j on their site (http://www.slf4j.org/).

Sure looks like a bug to me. What version of ehcache is this?