Release 2.3.6 (6/22/11)

• Adding locale content on entry where locale is specified

Release 2.3.5 (2/28/11)

• Categories provided on an entry PUT are saved

Release 2.3.4 (11/16/10)

• As new revisions of an atom entry are published, trash is no longer created. Revisions are now hard deleted.

Release 2.3.3 (10/29/10)

• Added support for no-latency flag in getting feeds. When this flag is passed as an argument with the value true in the call, the latency will be skipped in the database sql queries. By default, the flag is false.

Release 2.3.2 (09/26/10)

• Fixed bug introduced into XPathAutoTagger in 2.3.1, where Terms could be tagged with "{2}". This bug only occurs in some XML Processors (i.e. the default one in Resin)

Release 2.3.1 (09/19/10)

• Improved XPathAutoTagger performance by ~68%. In doing so, added a new method to the EntryAutoTagger, which you will need to implement if use this interface. It should be self-explanatory. Also, fixed a bug in DeleteActionScheme which remarkably has never bitten us to date.
• Fixed a small bug in the workspace/collections cache introduced in 2.3
• Added/refined the performance logging considerably

Release 2.3 (09/08/10)

• Split the current single DataSource into 3 DataSources; a read-only, a read-write, and a Aggregate datasource. This is a good thing because it allows us to control them separately. In particular, (1) Different timeouts at the JDBC layer. This is critical, since a JDBC timeout signals the DB to stop (as well as the Server). This means that we actually remove the load from the DB. Note that today the timeout is based on Aggregate Feeds, so it is way long, and relatively useless. These new timeouts will be something like; Read-write = latency time, Read-only = 300s (or some such), Aggregate = 1200s. (2) Different pool sizes. This will provide throttling, particularly for Aggregates. Which will allow us a certain level of protection from Aggregates gone wild. Both JTDS and the newer Merlia have socket timeout settings. This change as backwards compatible as possible. I.e. we left around the original DAOs, which delegate to the Read/Write DAOs. See upgrading to 2.3 for details.

Release 2.2.1 (09/07/10)

• Explicit CASTs on all SQL parameters within WHERE clauses. This should not be necessary, but we've found that SQLServer will sometimes create horrendous query plans, and these hints help it immensely
• More extensive performance logging
• Attempting to DELETE a non-existent Entry is now logged as a WARN, instead of an ERROR
• Upgraded woodstox to 3.2.4 to fix occassional ArrayIndexOutOfBoundsException
• Upgraded iBatis to 2.3.4.726
• Added support for updating a single category using the Category document with an extension element (CategoryOperation) and additional extension attributes on Category.
• Cache collections and workspaces lists, instead of going to the DB for the lists The listCollections() DB operation was being called frequently, and was taking enough time (~50ms per), that we simply cached the results. Since Collections and Workspaces are basically fixed, there is little reason to go to DB for this list every time. Now it has a 60s expiry. And we can still add new Collections on the fly.
• Now trim() EntryIds before they are used. This fixes a bug where EntryIds with leading/trailing blanks were stored, and then used again in Feeds.

Release 2.2.0 (07/21/10)

• Significant improvement to the selectFeedPage query with respect to Category Feeds. Completely rewrote the query. From its current form, where it basically first gets the union of all Category matches, and then, later, SUMs across them in a HAVING clause to determine any matching Category AND/OR boolean logic. To a new form, which uses SQL set operands (INTERSECT and UNION) to do the Category boolean logic.

Release 2.1.20 (06/21/10)

• Correct a bug when forcing an explicit timeout for Transactions, where the timeout was enforced in the JUnit, but not in the real code

Release 2.1.19 (06/10/10)

• Added an explicit timeout for Transactions. The timeout was not being honored. Now the Transaction is spawned on a separate Future Thread, and explicitly timed out it it exceeds the maximum. This is critical for the latency period to work correctly. The default is 5 minutes.
• Added further perf logging, particularly around the getContent sections.
• Reorganized selectFeedPage SQL such that it is significantly simpler for the case of one Category. Also, it now avoids an AND clause when UpdatedMin is not specified
• Cleaned up the testing log4j.xml

Release 2.1.18 (04/12/10)

• Enabled rollup statistics on the perf4j collaescingstatistics appender
• Added heuristics to adjust MS SQL Server queries for getting feed pages and aggregate feeds based on the position of the index. When the index is near the tip, the query with index seek is used and when it is far, the query with index scan is used.
• Added a logger which tracks the files that were moved to the trash directories for removal and a shell script to clean up those files

Release 2.1.17 (03/02/10)

• Fixed ThrottledAtomServer. Since the addition of the v2 interface, ThrottledAtomServer has not worked. It is now turned on again by default.
• Added an option on the workspace to be able to turn off comparing old contents and new contents on entry update.
• Added back previously removed query hints to improve feeds query performance.
• Fixed category update so that it will handle case-sensitive values for term correctly when the new term has same value as the old one except for its case.

Release 2.1.16 (01/07/10)

• Added a new function to the Blocking Filter on JMX Management Console so that all write requests to the server can optionally blocked or allowed. By default write requests are not blocked.

Release 2.1.15 (12/29/09)

• On entry update, the new contents will be compared against old contents using a hash function, and if the contents and the categories are the same, the entry will not be updated and the revision number and timestamp will remain the same. Jmx EntriesMonitor page will display the number of PUT requests that are actually updated.

Release 2.1.14 (12/17/09)

• Workaround for a bug in SQLServer where Prepared Statements are taking an innordinate amount of time on very large datasets
• Added 2 statistics monitored on JMX console - Document-count and Max Index per Workspace-Collection.
• Bug fix for JMX obliterate function
• Check size based on database column size and return error code 400 if too large

Release 2.1.13 (8/14/09)

• Update a non-aggregate feed query that could take significant amount of time when the pulled feed is far from the tip due to an invalid query hint.
• Replaced built in logging with Perf4J to allow better performance monitoring.
• Added a blocking filter to block requests based on the authenticated user id, content size or uri paths

Release 2.1.12 (5/19/09)

• Removed scheme/term validation from deleteEntryCategoryBatch, which enables us to auto-tag entries that may have existing invalid Categories

Release 2.1.11 (5/7/09)

• Modified queries in SQL Server to cast parameters to the INT data type when necessary, which vastly improves performance in many cases.

Release 2.1.10 (5/4/09)

• Modified queries in SQL Server to cast parameters to the TIMESTAMP data type when necessary, which vastly improves performance in many cases.
• Fixed latency check to ensure that the feed latency is always greater than the transaction timeout, not the sql statement timeout. This allows you to set the sql statement timeout to very large values if necessary.

Release 2.1.9 (3/9/09)

• Modify StripingAutoTagger so that it is more easily extendable

Release 2.1.8 (2/26/09)

• Various fixes related to the "v2" API,primarilly in the DAO. In particular, fixes related to the updated-max.
• TestingAtomServer now makes the Spring Application Context available.
• TestingAtomServer now spins up both the V1 and the V2 Servlets
• Increase the VARCHAR size of EntryStore.EntryId in the postgres DDL from 32 to 36
• Made Spring ApplicationContext available to subclasses in AtomServerServlet

Release 2.1.7 (1/18/09)

• Fixed a bug in Aggregate Feeds where different localized entries with the same workspace/collection/entryId would not show up in an Aggregate
• Fixed a bug where multiple XML deletion elements were produced when multiple deletes occured
• Upgrade to commons-lang 2.4
• Moved most of the log statements in the StopWatches to trace level
• Added a constructor to TestingAtomServer that allows one to be created which does not erase the HSQL database so that more than one TestingAtomServer can be used simultaneously

Release 2.1.6 (12/3/08)

• Changed aggregate feeds query to reflect column being added to view. Removed an unnecessary join.
• Make default max number of Entries in an Aggregate Feed; 1000 link and 100 full
• Add perf logging around aggregate feed DB query
• Upgrade to iBatis 2.3.4

Release 2.1.5 (12/3/08)

• Fix bug in Feed paging when endIndex is set and latency=0
• Added error handling for truncation of Category attributes (scheme, term, label) to the size prescribed for the database columns. This defaults to 120 for all, but is configurable in the EntryCategoriesHandler
• Moved log4j.properties from the Classpath base (the log4j default) to the org/atomserver. This fixes a problem when using the AtomServer JAR where AtomServer's log4j sometimes overrides that of the local application
• Added an optional time to live (TTL) to AtomServerIsAliveHandler, which caches the AliveStatus for an some Spring-configured TTL. Default is no expiration (0L).
• Make DB latency setting controllable via JMX
• Make default max number of Entries in an Aggregate Feed; 1000 link and 50 full
• Added "v2" AtomServer - expose possibly backwards-incompatible API changes at a different URI
• v2 only changed behavior of "NOT MODIFIED" for feed to return an empty feed document instead of a 304

Release 2.1.4 (11/10/08)

• Add updated-max and end-index query parameters, which allows one to query for Feeds or Entries within a bounded range -- updated-min to updated-max (inclusive to exclusive) or start-index to end-index (exclusive to inclusive). Check outthis AtomServer documentation. for further info
• Fixed the DBPurger so that it instantiates abderaBeans, and includes Spring Beans from "/org/atomserver/spring/ext/*.xml". This allows you to properly override Spring Bean definitions, and thus, the capability to avoid DB foriegn key constraints when deleting rows

Release 2.1.3 (10/13/08)

• Add the ability to add a forced latency to DB reads (Paging GETs), which allows us to remove the global page locking (APPLOCK) from the write transactions. This yields much better throughput from the system for writes (PUTs) at the expense of real-time reads. Note that this APPLOCK was introduced for the rare (~1 in a million) race condition on writing/reading timestamps when there were 2 writers and one reader, where a reader could miss Entries. This latency must be slightly higher than the SQL statement timeout. There is a new property; "db.latency.seconds" to set this value, where 0 equals no latency. Note that this option is not available in all DBs.
• Add ability to delete all DB-based Entry Content by workspace and collection to ContentDAO
• Fix DBPurger to delete rows in Content and CategoryLogEvent tables
• Add XML namespace to all "pets demo" example Entries

Release 2.1.2 (09/22/08)

• Fixed race condition bug when creating Virtual Workspaces
• Entry Category Log Events are now ordered by their CreateDate, in ascending order
• The default for the Workspace option; defaultProducingEntryCategoriesFeedElement is now "true"

Release 2.1.1.1 (09/09/08)

Release 2.1.1 (09/08/08)

• Added updateIndex and revision as Atom extensions to entry elements
• Added diagnostic code to detect errors in our SQL Server queries (or potentially in SQL Server itself

Release 2.1 (08/24/08)

• The Spring configuration has changed somewhat. The wiring of XPathAutoTaggers for a workspace has slightly changed; the categoriesDAO property should be replaced with a categoriesHandler property. This change plugs a leaky abstraction, and allows all Category operations to happen through the CategoriesHander.
• All calls to PUT or DELETE now require that you send the next revision as opposed to the current revision. And likewise, the "edit" link within an Entry XML has been corrected also to point at the next revision.
• Calls to GET for an Entry usingany revision number, including the current revision, now produces a 400 BAD REQUEST, instead either being legal or producing a 409 CONFLICT.
• You will need to update your database to reflect the new table and views that came in as part of both the Agggregate Feed and Categories event logging changes described below. Note that the DB changes are indicated in the DDLs in org/atomserver/schemas, and that no data migration is required

1. Better performance for Aggregate Feeds. The queries were completely rewritten. The performance boost is huge (it is many times faster), and essentially made Aggregate Feeds usable. As a byproduct, all Category query performance also significantly improved
2. Added tests for DB-based ContentStorage, and began using this feature in earnest on a project
3. AtomServer now produces a Jar artifact as well as a War, and includes this Jar within the War. Cleaned up the code to consistently use resources from the Jar. Added new documentation on deployment options for AtomServer
4. Added a setenv.sh script for Tomcat, which may be called from catalina.sh. Cleaned up the Jars that get included in the War's WEB-INF/lib. Created new top-level /lib dir in the standalone version to house Jetty and Servlet API Jars, which fixes Tomcat deploy issues
5. The "edit" link for an Entry XML has been corrected, as mentioned above. Also fixed some bugs related to Optimistic Concurrency and initial Entry creation.
6. Cleaned up the API to remove RequestContext from the abstract methods of AbstractAtomCollection
7. Added a very simple standalone AtomServer (TestingAtomServer) for Atom client unit testing, which makes writing unit tests for Atom clients much simpler. Made HsqlBootstrapper restartable, and made TestingAtomServer do so on each construction
8. Refactored the code to handle generic "virtual workspaces". Consolidated all DB-based Category handling into the EntryCategoriesHandler, including all DAO access. Consolidated to an AtomService level CategoriesHandler, referenced through a VirtualWorkspaceHandler Map. Added access to the Abdera ServiceContext from AtomService
9. Added an optional ability to "log" (to the metadata DB) all changes to Categories. This ability is critical to applications that use Categories to manage a State Machine for a given Workspace, and want a log of all State changes for a given Entry. This is enabled by setting the "loggingAllCategoryEvents" to true in the "org.atomserver-entryCategoriesHandler" Spring Bean
10. Fixed unneccessary failure for a possible race condition on the creation of new collections
11. Corrected a problem when using SQLServer's sp_getapplock stored procedure. First, sp_getapplock can fail silently, which could cause an applock to not be released, so we now properly check the return code. Second, it appears that sp_getapplock interacts oddly with some JDBC drivers (JTDS), such that you must call SQL against a Table to get the transaction started, otherwise sp_getapplock returns a -999 error and doesn't take out a lock at all
12. Added a StripedAutoTagger, which tags each Entry with a unique identifier (per stripe) that can be used to balance load when processing Feeds. Because a Feeds may contain repeated instances of the same Entry, they must be handled by the same Feed processor, and thus, one must resort to schemes such as striping

Release 2.0.2 (8/7/08)

1. Added TestingAtomServer - spin up a complete atomserver, running in Jetty, all through a java API. Makes writing unit tests for Atom clients MUCH simpler.

Release 2.0.1 (6/23/08)

1. Added a "throttled" AtomServer. This AtomServer throttles all PUTs, POSTs, and DELETEs using a ThreadPool front-ended with a Blocking Queue. When all Threads in the Pool are in use, incoming requests are queued up. The theory is that, because we serialize all writes to the DB, when it is overloaded its performance degrades significantly, and that by throttling DB input to some optimum threshold we can maximize performance. This theory was proven out in performance testing. We saw a 220% decrease in average response time for PUTs for the throttled AtomServer, with a relatively constant TPM, and smooth behavior. In contrast the "normal" AtomServer saw spiky behavior, and significant performance degradation.
2. Aggregate Feeds were completely rewritten.
3. Added "sharded paths" file-based ContentStorage.
4. Gzipping for file-based ContentStorage.
5. Cleaned up the Junits significantly. The tests no longer use a local "var" directory.
6. Google Analytics for the site

Release 2.0 (5/13/08)

1. This is the initial open source release. It is numbered 2.0 because the code behind AtomServer has been around as an internal application for about 1 year, and over that time went through many revisions