[Logo] Terracotta Discussion Forums
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Messages posted by: hervbarr  XML
Profile for hervbarr -> Messages posted by hervbarr [29] Go to Page: 1, 2 Next 
Author Message
I have seen that ehcache is provided throught 2 kinds of packages.
The opensource and the enterprise one (-ee).

As I don't yet know if I will use the OpenSource or the Enterprise package, I would use Enterprise package as an open source version [without enterprise specifity]. By this way I already have the right packages and dependencies (moreover I am using OSGi so I have no need to create a bundle for both open source and enterprise version).

Is it possible to do this or should I need to prepare two different packages (one for OpenSource and one for Enterprise) ?
Ok, thanks for the answer.
I'll see how to handle it.
thanks for the link.
I'll look how to start the tcServer before running test and stopping it after these.

I have different kind of tests.
I have some tests where I will use directly the full functionality of terracotta and use a tc server. (I guess the connection to the TC Server will solve the classpath problem).

For some other tests, I would mock the terracotta API (using Mockito) in order to only test my code.
By this way I can check the parameters used to call Terracotta API (Mockito) and other methods which are not using terracotta, speed up the tests by avoiding deployment and connection to a TC server).
But it is in this second case where I don't know how to define correctly the class path.

I added in my maven project dependencies to :

Thanks for answers.

I have seen the documentation and use it to define "pre-defined" search attributes.
It explains how to add an index for a not living cache [before calling cacheManager.addCache(new Cache(cacheConfig));]

but after I haven't found a working way to update the configuration in order to add a new search attribute.
we have seen different performances between a ClusteredMap and the default distributed Ehcache configuration

In my use case, i have seen that terracotta map has better performance than ehcache [mainly write], so I guess that some configuration is slightly different.

I guess some configuration of ehcache allows to mimic the default terracotta map for example :
Is there a L1 when using a terracotta map ? (i have seen a parameter for this in ehcache)
The consistency, pinning, synchonous write, ... ?

I would know which configuration should I use to use Ehcache instead of ClusteredMap (and keep the behavior/performances).
I have used a searchable cache.

For a particular use case, I would add a new searchable attribute after the creation of the cache [this searchable has not been frozen].

I have seen that I could access to the cache configuration and modify the searchable object of the cache configuration.
When creating an index for an unknown attribute it seems working as no exception is thrown. If I try a new attribute with an already defined name, I have an exception [logical]

But if I create a query for the new search attribute, it fails as the new attribute is in fact not taken into account.

Is it possible to add a new search attribute for a living cache ?

Thanks for answers.
I have done another test by replacing the SimpleThreadPool by my own implementation using a ThreadPoolExecutor from java 1.5+.

It seems that for short running, it is more efficent than the SimpleThreadPool.

I guess that some more job is done in the SimpleThreadPool than simply running a thread. Is there some extra requirements (which are not documented in the interface) ?
Looking deeper in the documentation, I guess that org.quartz.scheduler.batchTriggerAcquisitionMaxCount can solve a part of a too much and fast trigger problem (I guess some refactoring in how i add job / trigger could be better).
thanks for the answer.

I don't really know the hardware/configuration as the software will be run under multiple environment (linux/windows different hardware ...).

Really it would be best to do a proof-of-concept on your system architecture to know for sure. Around 100/sec isn't out of the question.  

Thanks for the answer i'll do a POC to check that it is working.

We did a use case where :
Quartz with MemoryJobStore
One Scheduler with 1 job triggered 2 000 times every 5ms. Working with the right scheduling.
One Scheduler with 2 000 jobs triggered once with a delay of 5ms between each. The scheduler is exhausted. Can't respect frequency.

That's why i was worried about multiple fast triggers.

I have seen in the documentation

If you need to scale out to support thousands of short-running (e.g 1 second) jobs, consider partitioning the set of jobs by using multiple distinct schedulers. Using one scheduler currently forces the use of a cluster-wide lock, a pattern that degrades performance as you add more clients. 

In a clustered environment using TerracottaJobStore, what is a usual limit to avoid to scale out with partitioning (100 jobs per seconds) [my job will run less than 10 ms] for 2 or 4 clients?

As quartz is more adapted to long running, is it a good idea to use quartz in this case ?

Hi thanks for the anwser.

If i understand well strong consistency avoid reading and writing at the same time.

I thought it was the way the data where pushed to the different L1 [in my case i will remove the L1 storage].

By the way when using the Search API it seems that all search data are saved by L2 (so it should not be an issue or a performance loss to remove L1 in this case).
Yes i have read this documentation but i'm not really sure of the answer (mainly for the second one as I remove the L1 storage (which by default exists)).

With no L1, I expect that i read directly the TSA, so i could read the uptodate data [strong] (I guess).

By the way to have a synchronous writing, I need to use a consistency strong, as eventual and synchronous are not compatible.

i'm using EhcachE in distributed mode with a TSA.

I'm asking myself some questions about : should I use strong or eventual consistency ?

My first question is :
Does an eventual cache, provide a "strong consistency" when using explicit locks ?

My second question is :
I have one cache which is in a write-heavy case.
I have seen i should use : localCacheEnabled to false to improve performances.
In this case, can i stay only in eventual mode instead of strong mode as all is only stored by the TSA ?
If i do a reading is there a difference between eventual and strong ?

Thanks for answers
we are also using ClusteredMap but if ehcache can provide a configuration similar to this one it would be a nice news to avoid using both ehcache and terracotta toolkit.

By the way, it seems terracotta advises to use EhcachE instead of Terracotta Toolkit so they could provide a way to "migrate".

can somebody confirm nicolas assumption ?
is there some tools provided by terracotta to run some tests with junit and maven ?

I have seen that a page exist :
But i am not able to see it as I have the message :
You are not permitted to perform this operation.

I have also tried myself but I have some problems with the terracotta-toolkit-1.4-runtime.
The jar contains inner jars which not seem to be seen by the junit runtime.
java.lang.NoClassDefFoundError: com/tc/exception/TCRuntimeException

http://old.nabble.com/junit-runner-td28767800.html shows also that some annotation and utility tests exist but i'm not able to find exactly which depencies I need.
Profile for hervbarr -> Messages posted by hervbarr [29] Go to Page: 1, 2 Next 
Go to:   
Powered by JForum 2.1.7 © JForum Team