It is mostly out of caution with some amount of fatalism mixed in. We are working with a distributed databases that is synchronized back to a central database. In order to avoid key collisions we are partitioning the key space. We may have as many as 100 remote databases - reducing the key space for any one to ~21million. While I don't expect 21 million errors from a single instance (nor even all together), there are processes that can run every few seconds that can generate an error. Left unchecked/unnoticed for long enough and the volume of errors could add up over time. In my experience there is very little memory or disk space issues created by using a long instead of an int - although I recognize that logback is used in many different ways/environments, so my experience may not be as accurate in the context of logback. - Michael On Mon, Mar 22, 2010 at 12:52 PM, Ceki Gulcu (JIRA) <noreply-jira@qos.ch> wrote:
[ http://jira.qos.ch/browse/LBCLASSIC-198?page=com.atlassian.jira.plugin.syste... ]
Ceki Gulcu commented on LBCLASSIC-198: --------------------------------------
In java 'int' is 32 bits, ranging from approx -2Billion to 2billion. Why would you ever want 'long' (64bit) event_id values?
DBAppender: Support long event_id values in logging_event ---------------------------------------------------------
Key: LBCLASSIC-198 URL: http://jira.qos.ch/browse/LBCLASSIC-198 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.18 Reporter: Michael Lynch Assignee: Logback dev list Attachments: DBAppender.java, DBAppenderBase.java
Want to retain longer history of logging events.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev