В Вт., 10/04/2012 в 21:10 +0200, Bernd Strieder: > Hi > > 1. A similar condition to the described one seems to be possible, when > halting > the server, when it is running on another machine, while a client process has > active connection and active registered events. > > In my example, the client process uses only events to start working, start > queries. If the server is being stopped, then I can observe from the two > connections one going away, the event connection, and the other one goes into > state TCP state CLOSE_WAIT. After that the client process has to be turned > off > manually, because it only waits for events, but event dispatching succeeds > without errors. So nothing stops it. > > Since IBPP is in between, it is hard to tell, whether some extra behaviour is > due to IBPP. But overall the issue seems to be very similar to the described > one in CORE-3718. > > The situation happens with a Linux client using FirebirdSS-2.5.0.26054- > ReleaseCandidate3.amd64, and a Win32 Firebird version 2.5.0 25784. >
No - it's not related to 3718. And yes - I've reproduced it with current FB3. Please add a new ticket to the tracker. > > 2. If client and server run on the same machine, then it seems to be working > fine. When turning down the server, an Exception is being generated, and the > client can stop working as nice as possible, as desired: > > Origin: EventsImpl::Queue: *** IBPP::SQLException *** > Context: EventsImpl::Queue > Message: isc_que_events failed > > SQL Message : -902 > Unsuccessful execution caused by a system error that precludes successful > execution of subsequent statements > > Engine Code : 335544856 > Engine Message : > connection shutdown > > Context: FB Client &Server version: > FirebirdSS-2.5.0.26054-ReleaseCandidate3.amd64 > Even more strange - I've reproduced it on a single host. Could it be classic that might be explained with embedded connection, but with super that's very strange that we have different behaviour. Anyway the problem requires fixing. > 3. IMO the event interface needs some overhaul. It is very unpleasant to use > without polling under Linux, though there are ways. It could be a lot > cleaner, > if there were an official way to receive the socket fds in use by Firebird > client libraries. In an application combining many event sources it is very > handy to have select(2) available, or something more fashionable like epoll, > to avoid polling, and avoid useless threads polling around. > We plan to change from poll() to epoll() in the future, but it's not even in plans for FB3. Or we will never release it... What about threads used to listen to incoming events - probably it's worth thinking about use of single thread for all sources, but telling true that also does not look like primary task for the near future. Just interesting - how many event sources do you monitor at once? > Sorry for using the rc versions, but this is no production environment, and > has been in use since it is available to have some nice 2.5 features > available. If it works for you - not a problem. One BIG user of firebird even sails software with embedded 2.5 rc2 :) I CC the answer to devel, that's preferred place to discuss such issues. ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
