omniEvents 2.6.2 released

I’ve finally released the next stable version of omniEvents. This incorporates the huge number of bugfixes. Thanks mostly to Dirk Siebnich’s relentless testing, I’m confident that this version of omniEvents is by far the most stable and robust yet.

Full release notes: Version 2.6.2

Dirk wanted to use omniEvents as part of a CORBA framework he was developing for his employer. He wanted to use the (previously little tested) libomniEvents library, and he needed to be able to safely unload the library after he’d finished with it. He found crashing bugs that I tracked to numerous small memory leaks and incorrect cleanups. These errors had never been noticed before because omniEvents is usually used as a server, so shutdown didn’t need to be really clean.

Ironically, Dirk’s project was cancelled just as we were finishing the testing. He finished the work on his own time.

We did find one problem that is not fixed in this release. OmniEvents still uses the SINGLE_THREAD_MODEL which we discovered is not a good idea. I’ve already refactored the code to use the normal threading model, but the changes aren’t included in this release. Despite Dirk’s testing, I decided that they were too far reaching to be included in the stable branch. Consequently it is possible to get v2.6.2 to deadlock, but only by creating and destroying channels repeatedly for many hours!

Comment · RSS · TrackBack

  1. Roberto said,

    12 December, 2005 @ 14:00

    Hi Alex.

    First of all, thanks for the nice work You’re doing on OmniEvents.

    Now, a question:

    Is there a way to monitor the status of OmniEvents from the outside? I’m considering writing some kind of ESB based on a open source COSEvents service, and i wonder if someone has already dome something (via interceptors maybe) with OmniEvent.

    I’d like to define some kind of tree-based console ginving info on channels and events and allowing some admin operations on them.

    Has someone already written that? (i hate rediscover the wheel)

    Ciao,

    R

  2. alex said,

    12 December, 2005 @ 21:43

    Roberto:

    Is there a way to monitor the status of OmniEvents from the outside?

    I started on something like that, with a CORBA interface, using the CosPropertyService. Paul Nader continued to work on it, with the goal of producing and SMPT interface that would have provided exactly the sort of functionality you describe. Check out the ‘branch_SNMP’ branch in CVS, to see that work

    You might want to contact Paul, and ask him about the work he was doing. His e-mail is on Sourceforge.

    Personally, I’m a bit dubious about the benefits of instrumenting the application itself. The persistency database is constantly kept up to date. It contains all the information you want in an easily parsed text form. Why not just read that?

    Has someone already written that? (i hate rediscover the wheel)

    Great. You’re right – don’t reinvent the wheel.

    If you need help, then I’m available for contract work. If you want to do it yourself, then I’ll be happy to accept patches.

    -Alex

  3. Roberto said,

    14 December, 2005 @ 23:28

    Hi Alex,

    >> The persistency database is constantly kept up to date.

    That’s the way to go, at least for OMNIEvents and at least for monitoring. I’ll have a look.

    >> If you need help, then I’m available for contract work.

    CORBA projects today are rather rare. Anyway if something moves somewhere, I’ll keep Your name handy.

    >> If you want to do it yourself, then I’ll be happy to >> accept patches.

    I’ll be glad to contribute. Time permitting, (just like always)…

    Ciao,

    R

Leave a Comment

Sponsors