Those other ones are Information events however, not Warning events. ESE (as part of being "embeddable") has a couple of logging level controls (JET_paramEventLoggingLevel, and JET_paramNoInformationEvent). Each component is responsible for setting it's event logging level, the ESE default is ... let me call it, "fully diagnosable mode" (for us, not you ;).
Anyways, all events start like this:
"svchost (48984,R,98) TILEREPOSITORYS-1-5-18 .."
... the service exe name at beginning, and the "instance" name there at the end. If you get me a few of the noisier components, I will try to find the Windows component owners and suggest to them that they set the logging level higher.
Justin, that event you are talking about, I assume is ESENT event 642? If so, that was literally - MY fault. Not the ESE teams fault, but _MY_ fault. Feel free to reply here with your flame. ;-) I can handle it. Really. :)
In the server cloud business all the events streams (and we have several) are rolled up into optics web reports and analyzed and sifted for potential emergent issues and health metrics ... in this case, an event useful to our cloud server business leaked into the events of our Windows client business. This is (in my biased opinion;) less about being "server grade", and more about not being "properly embeddable" ... as generally embedded components should be quiet.
This is part of the challenge of making a DB engine that services two very divergent scenarios. This is the smallest of those challenges. How much memory we can allocate being the largest regular conflict ... Office 365 would not even notice if ESE allocated an extra 1 MB per process, but that would boost our Working Set numbers by 40% (from the last numbers I remember seeing) for each Windows Client Service using us.
Anyways, I have fixed the code to not log that event on Windows Client. It should clear up once that patch gets out.
Cheers,
Brett Shirley [MSFT]
P.S. - Oh and I am sorry if it caused you any stress. I know it sounds concerning, but it is truly innocuous. You can ignore it, and hopefully soon you won't see it.
This is good feedback for the project, thank you. I have lived with the naming convention, so long that it is second nature ... I didn't even think of documenting it ... I will write up something on the naming convention of ESE on the gibhub project's wiki soon!
Brett Shirley [MSFT]
(yes, the Brett Shirley contributor to the project ;-)
This engine was never storage for Outlook, nor I _think_ Visual Source Safe (but can't be sure of that). The JET Blue engine often gets confused with the JET Red engine, which were both completely different implementations of the JET API spec. See notes bottom of this page:
https://docs.microsoft.com/en-us/windows/win32/extensible-st...
I say "we" because I am one of the developers who has worked on the engine for the last 15 years (around half of it's existence).
Since I have worked on the engine, it has had a limit of slightly less than 2^31 database pages, which since it has a variable page size, has historically been 4 to 64 TBs.
Even before the 2nd rewrite in the 90s, I believe it had a 16 GB limit, so I really think the 2 GB is JET Red.
Those other ones are Information events however, not Warning events. ESE (as part of being "embeddable") has a couple of logging level controls (JET_paramEventLoggingLevel, and JET_paramNoInformationEvent). Each component is responsible for setting it's event logging level, the ESE default is ... let me call it, "fully diagnosable mode" (for us, not you ;).
Anyways, all events start like this: "svchost (48984,R,98) TILEREPOSITORYS-1-5-18 .." ... the service exe name at beginning, and the "instance" name there at the end. If you get me a few of the noisier components, I will try to find the Windows component owners and suggest to them that they set the logging level higher.
Thank You, Brett Shirley [MSFT]