From time to time we are asked by the users of MoSKito, how to do this or that, and how to implement a specific use-case with MoSKito. This is why we started a recipes section in our documentation and now also on the blog. A recipe will describe how to achieve a specific goal.
So the original question which led to this recipe: “Lets say I have a process, some kind of job, which is running every x seconds, and I want to monitor the number of successful and unsuccessful executions, with least possible effort”. And here how it goes.
Applications grow. At least successful applications. At some point your growing application will require a loadbalancer. It may be for scaling or availability purpose or something else. The day your application runs behind the loadbalancer first time will make you proud. And it will make you ask, how can I control what the loadbalancer thinks of my application availability? This is how.
About 10 years ago log4j was the logging framework for java. Years passed and many logging frameworks emerged. For many people, including myself, logback is the new log4j (and that is not only because of Ceki).
Unfortunately it is not possible to run logback as slf4j implementation OOTB in JBoss like in Tomcat. The following 5 steps explain you how to get it running.
Dear MoSKito-rians and those to become MoSKitorians in the next year!
This year was very successful for MoSKito: about 15 releases, multiple conference and press appearances, and a lot of user activity, especially by the end of the year. All of this makes us really proud of our project.
Looking back at our achievements, we are holding still for a moment to enjoy the Quietness of the next two weeks before the next year, which promises to be even more inspiring and exciting.
We would like to use this moment and wish you quiet, recreative and contemplative holidays and a very successful 2014.
Leon Rosenberg and the MoSKito Team.
Why do you need software architecture?
Since 2.1.0 version, configureMe provides the ability to view a list of configuration files, each config file separately, and its attributes, that used by default environment and content of this configuration.
For this functionality was used JMX API, namely managed beans, or MBeans and created MBeanRegisterUtil class. This class contains regMBean method, which doing registration of your mBean in MBean server. And also had been created mBeans for providing information about your configurations files:
WatchedConfigFilesMBean – provides list of config files.
This is a small sidekick for this post. People often complain that automating the deployment line is sooooooo hard. It isn’t. This post explains the simplest way to automate something with the less possible effort.
I have had 2 talks about DevOps@Runtime (here and here), I’ve also been talking to people about the topic and I’ve promised to write a blog post about it, which I’m doing now. But before I can start with the Runtime, I have to talk a bit about DevOps in general and what it is. Therefore, in the prologue I will explain DevOps in a NutShell 😉
I just came back from the DevOpsDays 2013 in Berlin earlier this week, and wanted to share my impressions.
Back in 2010 we were helping Parship to migrate their platform to a new provider and establish working application management. Migration to a new hosting provider and parallel re-architecturing of the platform is a funny combination and it actually rattled from time to time. Now imagine the situation were you have 4 different parties with at least 4 different tools and every tool shows something different.