Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for new Firebird 2.5 Services API features [JDBC148] #190

Closed
firebird-automations opened this issue Oct 6, 2009 · 7 comments

Comments

@firebird-automations
Copy link

Submitted by: Thomas Steinmaurer (tsteinmaurer)

The Firebird 2.5 Services API offers new enhancements like using NBackup, Trace, ... via the Services API.

Commits: f22abb9

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Mail from Thomas in Firebird-Java:

Hello Mark,

I have added some Firebird 2.5 Services API enhancements to HEAD in
2009, which I guess are now included in the 2.2.0 Snapshot.

While things went smooth, there was one problem left (see below; my Java
knowledge is a bit limited compared to Delphi), which I hoped Roman can
have a look. Don't know if he had time at that time. I haven't the
environment for working on Jaybird anymore, so I would need to start
from scratch. Not sure if this can happen any time soon, although I
would like to have a recent Jaybird dev. environment.

Just letting you know, that there might be an outstanding/unfinished issue.

Regards,
Thomas

> I'm almost done. This includes:
>
> * Support for specifying the security database when working with
> UserManager/FBUserManager
> * Support for SET/DROP AUTO ADMIN MAPPING for the new role RDB$ADMIN in
> security database added to UserManager/FBUserManager
> * Support for (incremental) backup and restore via NBackup (new classes
> NBackupManager, FBNBackupManager)
> * Support for new shutdown/online modes in existing
> Maintenance/FBMaintenance
> * Support for Trace/Audit API (new classes TraceManager, FBTraceManager)
>
>
> There is one problem left, where I'm stuck.
>
> When starting a trace via the Services API, the trace session gets
> registered successfully (I can see the trace session when listing all
> registered trace sessions). The caller (my test application)
> automatically waits for incoming data from the service query (pretty
> much the same when e.g. listing on the verbose output of a backup).
>
> Although I've registered System.out in my test class as logger, there is
> nothing streamed to System.out, even if events took place, which can be
> inspected in the written log file by the Firebird engine.
>
> When stopping this particular trace session from an external
> application, my test application gets terminated correctly, so beside
> starting a new trace session, this gets recognized as well.
>
> I've tried executing executeServicesOperation(...) in the main and in a
> separate thread. No luck with both.
>
> I'm stuck here.
>
>
> Regards,
> Thomas

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

assignee: Roman Rokytskyy [ rrokytskyy ] => Mark Rotteveel [ avalanche1979 ]

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Need to investigate this before Jaybird 2.2 release

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 2.2 [ 10053 ]

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Trace does work, but I think its implementation may need an overhaul to make it more usable. I think the current implementation requires a lot of effort from its users and I don't feel comfortable with the way data is being read and sent to the user and how sessions can be tracked and stopped (this also applies to some of the other service manager implementations). The fact that it creates a separate thread for every trace session might swamp a computer *if* a lot of sessions are traced.

I don't think I will make drastic changes for Jaybird 2.2, but I will consider a reimplementation for Jaybird 2.3 or 3.0.
Some rough ideas I have:
* Builder object for creating a trace request
* Use executor framework with a bounded thread pool and schedule individual reads instead of using threads per session (might be a bad idea if a trace read blocks if no info is available)
* Encapsulate trace information (might be hard to do, need to investigate trace further)
* Use queues and/or events for communicating with user of trace session instead of streams (might not be easier though)

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 2.2 [ 10053 ] =>

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Using a NIO implementation might be an option as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants