When eviction is configured in infinitispan, it's necessary set maxEntries. But I'm not sure how many entries fit in the memory of the machine where infinitispan is executing.
Is possible to configure infinitispan to evict when memory is full?
Thanks.
I think this is not (easily) possible yet. Here you can find tracking JIRA for this issue: https://issues.jboss.org/browse/ISPN-863
However this discussion is full of interesting ideas and maybe suitable workarounds for your case and it's definitely worth to look at: https://community.jboss.org/thread/165951?start=0&tstart=0
I'm afraid I can't give you anything more at this moment.
Hope that helps.
Related
I have been searching around and haven't found an answer. To give context in case it matters I am chasing down an error that may not have anything to do with this but since I'm tracing I'm trying to cover all things that I can think of. I have a method that was previously at some point using hashscanasync but after updating redis it's no longer available and it has been changed to just hashscan. Is there an alternative or anything because I want to make sure that this is not causing another issue? The error being reported in logging is "Sequence contains no matching element".
I'm very new to Apache ActiveMQ and still in learning phase so please bear with my silly or with not very precise questions. I would like to know is there is any possibility of message lost if we keep enablebatch property to true?
As per my knowledge enabling batch processing is always helpful and enhance your performance too in terms of processing transaction but I would like to know negative side of this property which may lead to message lost issue. Also if you can let me know whether there are some additional properties too which may need to set if we enable batch as true ?
Will appreciate your response
Regards,
Deepak Hardasani
Don't try to pre-tune! It only leads to de-tuning. Most Enterprise message flows are sufficiently handled with defaults on modern server systems without jumping through a lot of hoops and adding complexity.
Build up a representative test case.. run it. If the numbers meet your requirements, move on to more useful tasks. If not, then worry about tuning.
I'm looking for articles and references that give an overview of 'queueing' (I'm probably not even using the right term here). I'm hoping for an introductory styled guide through a world of Redis, RabbitMQ, Celery, Kombu, and whatever other components exist that I haven't read about yet, and how they fit together.
My problem is I need to queue up background tasks for issued by my Django website, and every blog and article I read recommend different solutions.
Lots of options available to you, and your choice will likely come down to personal preference and what dependencies you feel comfortable installing.
I'll give a vote for Redis. I evaluated RabbitMQ, ActiveMQ, HornetQ, and Redis and found Redis to offer the best mix of ease of installation, simplicity, and performance.
It's technically not a message queue, but the push/pop primitives for the list types provide atomic queue-like operations, so it can effectively be used as a queue. It has worked well for us.
One python specific project on top of Redis you might look at:
http://richardhenry.github.com/hotqueue/tutorial.html
Very simple. But again, all the other options, like Celery, are viable too.
RabbitMQ has a good introduction here: http://www.rabbitmq.com/getstarted.html There's examples in Python, even.
HornetQ has a very good documentation, and it's simple to install.
You can find the documentation at www.hornetq.org, and you would have several examples available with the distribution.
this maybe will be off topic, but I am preparing for an exam in real time. And I have been browsing the book and Internet for an answer for a problem.
Basically I wonder if by adding additional test code if it may change the real time behavior for an embedded system, and or also if it will introduce new errors.
Anyone who might know the answer for this, or refer me to some reading material for it?
Your question is too general.. So I guess the default answer would be it depends.. But considering the possibilities as an exercise of logic and thought, yes it surely can!
There are many schemes available to guarantee the 'real-timeness' of an embedded system. For example, one can have a pre-emptive timer based ISR to service the real-time task.. In such a case, your test code could possibly not affect the 'real-timeness'.. But if the testing takes too long, and the context switches are not pre-emptive, you could get into trouble..
But again it depends on what you're testing and how you're testing. Your test code can possible mess with the timers, interrupts or the memory of system. The possibilities to mess up stuff if you're not careful are endless..
Having an OS underneath will prevent some errors, but again depending on how it works, you may be saved from bad 'test code'..
Yes, when you add code (test, diagnostic, statistic) it may change the real time behavior. It depends on the design, the implementation and the CPU power if it will actually change the behavior. You also have more lines of code and the probability for errors may increase. But I wouldn't say, "it will introduce errors", since it can introduce errors.
Yes it can. See How can adding data to a segment in flash memory screw up a program's timing? for an example of how even adding non-executable code can adjust timing enough to screw up a system.
Yea, changing your code base could totally change its timing. Consider if you dumped some debug output to a serial port, it takes time to call that function, format the data, and if the function is synchronous, then for it to wait for data to go out. This kinda stuff definitely changes system timing behavior.
Thought I would throw this one out there and see what other people's experiences have been like.
I'm experiencing an issue with a system at work where it stops processing jobs in a queue and 'jams' so to speak. Once the services are restarted the software processes the queue and everything returns to normal.
In my experience so far, I cannot for the life of me figure out what is causing these stoppages. That, and I cannot reproduce the stoppage myself. The queue fails at all different intervals, sometimes running for a month straight, other times failing as close together as twice in 1 day. I have since involved two different vendors and various colleagues within the department and everyone is stumped, and has been for several months.
Since I started, we've isolated the processing to a single server and cranked up the logging which we've sent to the vendors. Neither have no idea what the problem is.
We've updated a few settings here and there, upgraded client and server pieces, but we have no idea if the things we are doing is contributing to an overall solution.
So I have a problem that appears to be unreproducible, random and untestable.
Has anyone been involved with any similar situations?
What are some of the ways to solve a situation like this?
Any shared input or experiences would be great.
Cheers,
EDIT:: Cranked up the logging, updated all of the components to the latest version, and made sure proper anti-virus exclusions were done and so far it has not jammed in over a month!
Use a logging framework that can be turned on in production. You might have to have too much logging initially but it should help narrow down the problem and as you get closer you can narrow the scope of the logging and at the same time increase the verbosity (is that a word) of the remaining log statements.
In addition to the logging as pointed out by Kelly there is the possibilty of a deadlock taking place since things seem to stop. One option if this is a Java application is to use jconsole and connect to the JVM instance. jconsole has a detect deadlock option which can provide very valuable information when the hangup occurs.
If this is not a Java application and perhaps a .NET application you could make use of this technique.