TS6.7.1: default event subsystem

Hi all,

We are looking into upgrading TS6.5 SP2 to TS6.7.1, and I do not really find any information about whether or not the default event subsystem (flatfile) database problems are resolved OOTB in TS6.7.1.

Does anyone know and where can I find some confirmation/information on that?

Sara

Find more posts tagged with

Comments

Bill Klish

I wouldn't use it anyway. It is not meant for more than simple testing/confirmation. I am not sure they have spent any time on looking into it. Just throw the stuff into a mysql or database.

I have heard some interesting things about apache derby as well, but haven't used it.

We have run into issues with the event subsystem getting backed up, causing some of our workflows to not run to completion even though their end tasks were signalled.

Migrateduser

Flat file DB is NOT supposed to be used in the production as this is just the sample configuration for the sanity/basic functionality. In 6.7.1 TeamSite has might come up with the database shipped along with the installer, but for the older version you must use some RDBMS ( SQL server, Oracle). If you are looking for the freely distributed versions MySQL is the one which is officially supported, but any JDBC compliant DB is supposed to work with the eventsubsytem. Derby yet is not officially supported.

nipper

Flat file DB is NOT supposed to be used in the production as this is just the sample configuration for the sanity/basic functionality. In 6.7.1 TeamSite has might come up with the database shipped along with the installer, but for the older version you must use some RDBMS ( SQL server, Oracle). If you are looking for the freely distributed versions MySQL is the one which is officially supported, but any JDBC compliant DB is supposed to work with the eventsubsytem. Derby yet is not officially supported.

Interestingly enough, I just loaded 6.7.1 SP1 with search and it installed Derby as well.

Migrateduser

Interestingly enough, I just loaded 6.7.1 SP1 with search and it installed Derby as well.

Yes, derby was released as OOTB DB for the eventSubsystem with 6.7.1 SP1 and is NOT configured by default (also manual startup). This is a very light weight DB (4 mb package) and suits the small production environments/tests. But this is not in any way the replacement for the commercial Databases which are much more scalable and feature rich. So if one already has the commercial RDBMS running, they should not be switching to derby.

Frederik

It's good (to know) that Derby is finally OOTB standard!

I'm wondering about your comments on the "rich features" of commercial RDBMS. Obviously true in general, but...

I see the event db as a small temp storage for event information that is almost as quickly consumed as it is produced. So do any of those "rich features" actually matter *at all* for the case of the event db?

Migrateduser

It's good (to know) that Derby is finally OOTB standard!

I'm wondering about your comments on the "rich features" of commercial RDBMS. Obviously true in general, but...

I see the event db as a small temp storage for event information that is almost as quickly consumed as it is produced. So do any of those "rich features" actually matter *at all* for the case of the event db?

Ideally yes this should suffice, but the load (events publishing rate and the number of topics/subscribers) may be increased to a level where the smaller DB cannot persist. There are many other CPU intensive searvices running on TS server and all are linearly related in terms of load. I mean more TS activity, more the resource requirement for the various components. From the JDBC driven application standpoint this could lead to situations like timeouts in locks etc.

Adam Stoller

Yes, derby was released as OOTB DB for the eventSubsystem with 6.7.1 SP1 and is NOT configured by default (also manual startup). This is a very light weight DB (4 mb package) and suits the small production environments/tests. But this is not in any way the replacement for the commercial Databases which are much more scalable and feature rich. So if one already has the commercial RDBMS running, they should not be switching to derby.

Any idea why this would not be configured by default (for new installations)? and if configured, not started automatically with TS?

TestReport.rptdesign

Migrateduser

Any idea why this would not be configured by default (for new installations)? and if configured, not started automatically with TS?

This was released with the SP1 and hence the SP installers are no-question silent install. Installer cannot remove the current configuration for the RDBMS and point eventSubsytem to Derby on its own. Hence one needs to configure it and turn the derby service automatic.
Next full release might have the full installer support by default.

Adam Stoller

This was released with the SP1 and hence the SP installers are no-question silent install. Installer cannot remove the current configuration for the RDBMS and point eventSubsytem to Derby on its own. Hence one needs to configure it and turn the derby service automatic.
Next full release might have the full installer support by default.

Ah - good points - thanks.