GDPR Architects Executive Summary Architects Plans Testing

	Tracking (Logging-Exceptions-Errors-Debugging Handlers) Introduction Handling Errors, Exceptions, Logging and Debugging as a real-time tracking system is a serious development feature. There is a lot of Java logging such as Java Util Logging, Log4j or any vendors logging tools. What are the advantages of building our own logging framework? Use Case:               Real Time Tracking (Logging-Exceptions-Errors-Debugging Handlers) Description: Tracking Errors, Exceptions, Logging and Debugging is a "have to have" and not a "nice to have" system development feature. We believe our approach and Logging Framework have a number of advantages and our architect would demo these features and their advantages. Briefly Describe This Use Case Any architect must address the following: Performance, Security, Errors, Scalability, Flexibility, Transparency, Latency and loosely coupled components. How can these features can be gauged. Real Time Tracking is the best way of gauging such performance and architecting them needs both real world experience and knowledge of system detail. Primary Actor: The IT community Goals: We are architecting a framework which handles Errors, Exceptions, Logging and Debugging. Our architect should provide options to turn On/Off of each without any system interruptions. It would give the system admin the control of such options. Running Logging or debugging may have serious impact on the system performance and may result in system crashing or freeze. Our framework should eliminate such impacts. The framework would have a GUI admin interface which controls the framework with On/Off in real-time. Analysis We need to ask the following questions:        How to run each of the framework features independently?        How to eliminate IO calls to dump files from slowing or freezing the running system?        What would the admin GUI interface have as options?        How would it handle web service interfaces and security? Architect Our answers to the analysis questions is developing two main threaded Tracking Java objects with the other threaded subcomponents. Tracking Architect Diagram Tracking Architect Diagram is our architect showing the layout of each of the tracking components and their interfaces. Also security is addressed in the following sections. On/Off Switch: Java gives the option of disable java.util.logging. In our case we have Errors, Exceptions, Debugging plus we need to track all them. We choose Java threaded Singleton classes or objects. Our Tracking main method or object runs a number of synchronized threaded objects which they can be started or killed within the main tracking method or object. Also the calls for our tracking methods which are similar logging calls. The calls may or not be executed based on the status of the running thread. Therefore, if for example, the Debugging thread is killed, calls to this thread would be similar to call a dummy method with no code or returns no value.The overhead of calling these killed object should architect-designed and coded for refactoring and should not take time. The use of "if-else" statement within the calling methods should brainstormed with the team and tested for other options. Main Thread: • Errors Handles errors and writes the to Buffer (not to files) • Exceptions Handles exceptions and writes the to Buffer (not to files) • Logging Handles logging and writes the to Buffer (not to files) • Debugging Handles debugging and writes the to Buffer (not to files) • Remote Handler Handles remote calls and write the to Buffer errors, exceptions, logging and debugging (not to files) It also handles security. • Buffer This is a linked List object or objects with a number of flags include available memory • Disk Writer This is a disk write with the same tasks employed by the Buffer. It has the same number of flags including IO performance issues. Data Size: The size and number of items logged or stores or running in The system memory must be predetermined, monitored and flagged. The system admin should be looking for our Tracking Frameworks Flags and recommendations. GUI Admin Interface (Status-Display) Thread: The main objective is to build timeline of the running system status and performance. It also can be used to track security issues or breaches. The GUI interface is a window to a number of things including following:        • Errors        • Exceptions        • Security Monitoring        • Latency        • Availability        • System Status        • Throughput        • Tiers Status        • History of Issues and Status        • Web, Mobile, Cloud and Desktop Access Logged Data: The development team and clients need to brainstorm the logged data. We recommend that each data item should a string of Logger ID, timestamp, tokens and values. Developers should also give their ideas and feedback on how they would code and calls the Track Framework's features. The string length should be as short and as precise as could be. Tokens Maps: The tracking strings should contain tokens. There should be mopping processes or code translating these tokens into data, actions and sequence of execution of certain processes. Logging Levels: java.util.logging.Logger has log levels define the severity of a message. Our approach to logging levels is a bit different since we have Log, Errors, Exceptions and Debugging combined into string of data. We are using Integer values and tokens for handling a number of tracking options. Every team or project may use our concept and build their homegrown tracking framework that would fit their application requirement. We also like to add that the Tokens Mapping is another way to logging levels as well as shorten the tracking data string length. History and Statistics: Our Tracking Framework is an excellent tool for tracking history and running statistics and reports Rules For All the threaded components: • Must be a Singlet Java Object • Admin have the GUI option to kill each thread independently as needed. • Their methods must be synchronized • Use local fields-parameters-properties and no static methods or objects • Developers have the option to select which feature would need to run by passing a parameter with constants. For example, a developer can code a private method by passing the "DEBUG_EXCEPTION_ERROR" for debugging, exception and error dumps only and nothing else. The main Singleton thread would parse the passed-parameter and run each of passed option. In case these options threaded object is killed, the main thread would do nothing and it could be programmed to flag such thing. • All threads must be well tested to prevent any conflicts, lock or hanging too long in memory • Memory available flag should be used • Call Java Garbage Collector to free objects • Disk is full flag should prompted to admin to handle and check if there are issues • Documented procedures on what-how and when-who of coding and calling each of errors, exceptions, logging, debugging Security: There is a number of ways to implement security including firewalls, ID and Token authentications and security flags. We also need to address what clients would be implementing such HTTPS, firewalls, server security, sockets security (SSL), encryption-decryption, Authentication, Authorization, application security, third party security, other security, database security, plus whatever we did not mention.

	About us Contact Site Map Support Privacy Terms All rights reserved