Morning! Here’s a quick tip on camel-http and proper retry logic within error handling. Under the hood, camel-http uses Apache’s HttpClient, which provides its own retry logic by default. Adding Camel’s onException redeliveries on top of that ends up multiplying the attempts.
While working with a new client on some Camel-based microservices, I’ve been trying my best to keep a list of caveats and potential issues that occasionally pop up. Camel’s integration patterns and components are extremely powerful and include many bells and whistles. But unfortunately, that flexibility can also get in the way…
Without further ado, here’s the running list. I’ll come back and update these, periodically!
I’ve been through my fair share of technical interviews. Typically, they’ll ask you to complete a live exercise, provide code samples, or answer mundane questions about a particular language or framework. Generally, those approaches are useless. Even the most talented software engineers do not always remember how to implement hashCode(), the differences between various search/sort algorithms, or the most appropriate data structure to use for a specific context.
In my stint as a software engineering manager, I set out with all the typical “I can do this better” mantras. I won’t ask the stupid technical bits — I’d rather have someone who knows the right questions to ask and how to use Google. I won’t ask for a live coding exercise, since that’s so far from reality and folks are often nervous. I’ll focus more on how they’ve used specific technologies to tackle problems, what they’re proud of, their hobbies, communication skills, blah blah blah.
All that is well and good, but I found it missed critical areas: how well can this candidate critically think about design patterns, component design, the composition of components, governance, and working effectively in a team? I’d argue those skills are the most important to have, but also the hardest to gauge and discover. We tried all sorts of tactics, but never really found the sweet spot.
Recently, I briefly went through a period of looking into next step options. I’ve worked remotely for years and have no intentions of ever changing that! We were blessed with an awesome opportunity that popped up, so the search is finally over. But before I completely turn to the next page, I thought I’d throw out some links that were incredibly helpful:
When it comes to interacting with relational databases, citizens of the Java world tend to be in one of two camps. Lately, the rift continues to widen.
- Use Hibernate ORM for all CRUD operations, all queries, and anything else that would otherwise touch SQL. SQL is icky. Abstract all the things.
- I got 99 problems and Hibernate ORM caused them all. Es el Diablo. Avoid it, no matter what. Use nothing but pure SQL, as God himself intended.
Folks miss an important point: ORM was never meant to be used for everything! It is a tool to be used where applicable. Can it be used as a complete abstraction or replacement for everything involving the database, shielding developers from ever having to learn SQL? For the most part, yes. Should it be? Definitely no. It often makes sense to combine ORM with other SQL approaches, marrying the best of both worlds.
If you have experience with Apache Camel, this one might sound a little obvious. But, it has recently come up a few times, so it’s worth mentioning. As an example, say you have a route that iterates over paged data and does something with it, and you therefore need to keep track of the pagination. You might use something like the following:
Imagine you manage a team of corporate event planners, responsible for overseeing each event and ensuring every single detail is arranged and executed. Your team consists of 8 individuals. The scale of each event is sufficiently large, requiring you to task each individual. If any of them fail, the event will be unsatisfactory (at best) or completely unsafe (at worst).
If you have a team developing OSGi applications for Apache Karaf, Vagrant provides an easy way to ensure everyone is testing local deployments in a consistent context. Vagrant is a little like Docker, using a layered approach to build up virtual environments. In this case, we create an Ubuntu “box”, running on a VirtualBox VM, and automatically set it up with everything necessary for Karaf testing. Continue reading Apache Karaf on Vagrant (example Vagrantfile)
By default, each Apache Camel route has its own error handler, meaning each independently catches and handles Exceptions thrown within it. But, what if a “parent route” needs to catch and handle Exceptions thrown by a sub-route? Here’s one approach: Continue reading Apache Camel: Throw Exception from Sub-Route to Previous Route
Here’s a quick tip: the easiest way to find transaction leaks in Wildfly/JCA. Continue reading Find Transaction Leaks in Wildfly and JCA