Re: [Firebird-devel] Statement-level read consistency and intermediate versions GC
22.10.2014 23:47, Nikolay Samofatov wrote: Dmitry, What should I do with the code described below? I'm not a Dmitry, but anyway... I, personally, have no time even to look at it until the conference end. So, don't hurry, please. Also, it will be great to have explanation of new snapshot's and how it (should) work. Comments in code is good but not enough to understand idea, rules and correctness of implementation. Thanks, Vlad -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] problem with connections to firebird -s
On 10/22/14 22:54, Michal Kubecek wrote: Hello, I noticed a problem when connecting to FB3 started as firebird -s (on Linux). As I was able to reproduce the issue with versions as old as April 2013 and I'm not completely sure relicts of my experiments can't cause it, I would like to ask if someone else could try to reproduce. What I do is start the standalone server with /usr/sbin/firebird -s and connect to it e.g. with echo 'show tables;' | isql -ch UTF8 '172.17.2.1:test' from another system. Without -s option everything works fine but with -s the connection hangs. From the network communication and strace output (can be found at http://www.mk-sys.cz/tmp/fb3-s/ both for good and bad case), it seems that in both cases, the connection is established and first data packet from client (428 bytes, looks like authentication) is read. While in the multithreaded case, server reads configuration (firebird.conf, databases.conf) and responds to the packet, forked child in standalone case just calls poll() on connected socket again so that from that moment on, both client and server wait for data from the other side. Please add a ticket to the tracker. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] API and classes upgrade
Hi! To not check class version in each method call, cloop-based interfaces implement class-upgrade at return and argument passing. If everything is simple, it (the mechanics) works. But not everything is simple. We have structs (Dtc::start - with DtcStart) with interfaces and pointers to classes (DbCryptPlugin::setKey), where a number of elements may be passed. It's not impossible, but I feel as a great level of complication to add to cloop things like IN/OUT parameters and instruction of how to decode length of buffers. And later we'll add another set of complication to deal. Also, I really don't believe that class-upgrade are going to work. There are various problems, like who allocate/deallocate memory for vtables, how to call a standard upgrade function (must be in IMaster/IUtl), but it's not always accessible (you can't just call fb_get_master, multiple client library may be dynamically loaded). I propose something different. Methods appeared in the first version of an interface must never be checked, as they will be always there. Methods added later are generally not core-methods and not very performance sensitive. I propose we check they versions (it's an if) when calling them. If you feel necessary, we can fill vtables with doNotImplemented method for 5 or so more methods than the initial method count of the first version, so the next 5 methods added in subsequent versions will not need the if-check and may be called directly. Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4586) connections to FB3 in standaloneClassic mode (firebird -s) hang up
connections to FB3 in standaloneClassic mode (firebird -s) hang up Key: CORE-4586 URL: http://tracker.firebirdsql.org/browse/CORE-4586 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0 Alpha 2 Environment: Linux - openSUSE 13.1 Reporter: Michal Kubeček When the standaloneClassic server is started with /usr/sbin/firebird -s and connection to it is created e.g. with echo 'show tables;' | isql -ch UTF8 '172.17.2.1:test' The query hangs up. Without -s option everything works fine, as well as in the usual classic mode (started via xinetd). From the network communication and strace output (I'll attach them in a moment), it seems that in both cases, the connection is established and first data packet from client (428 bytes, looks like authentication) is read. While in the multithreaded case, server reads configuration (firebird.conf, databases.conf) and responds to the packet, forked child in standalone case just calls poll() on connected socket again so that from that moment on, both client and server wait for data from the other side. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] API and classes upgrade
On 10/23/14 18:56, Adriano dos Santos Fernandes wrote: Hi! To not check class version in each method call, cloop-based interfaces implement class-upgrade at return and argument passing. If everything is simple, it (the mechanics) works. But not everything is simple. We have structs (Dtc::start - with DtcStart) with interfaces and pointers to classes (DbCryptPlugin::setKey), where a number of elements may be passed. It's not impossible, but I feel as a great level of complication to add to cloop things like IN/OUT parameters and instruction of how to decode length of buffers. And later we'll add another set of complication to deal. Also, I really don't believe that class-upgrade are going to work. There are various problems, like who allocate/deallocate memory for vtables, how to call a standard upgrade function (must be in IMaster/IUtl), but it's not always accessible (you can't just call fb_get_master, multiple client library may be dynamically loaded). Must say that we suggested in cloop fast version check (no virtual calls needed) there is no big difference between version upgrade and explicit version check. 2-3 additional machine instructions is nothing when doing virtual API calls. I.e. I agree that now version upgrade is not a requirement. I propose something different. Methods appeared in the first version of an interface must never be checked, as they will be always there. We should learn to distinguish what method is last. Not ot say it's too hard task but this must be done if we want to relay on it. Methods added later are generally not core-methods and not very performance sensitive. That's not always true. For example there are plans to add batch SQL API for DML operators. Methods needed for it will be added first of all for performance reasons. But once again - when we do not need virtual calls for version check it's not critical. I propose we check they versions (it's an if) when calling them. I want to point you to one detail. It should be possible to specialize (in some way) action to be taken when interface version does not match to caller requirements. Currently function to upgrade version is specialized for one interface in trace plugin. It's good idea to have same functionality when checking version. If you feel necessary, we can fill vtables with doNotImplemented method for 5 or so more methods than the initial method count of the first version, so the next 5 methods added in subsequent versions will not need the if-check and may be called directly. IMHO that's not a solution. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] API and classes upgrade
On 23/10/2014 13:42, Alex Peshkoff wrote: On 10/23/14 18:56, Adriano dos Santos Fernandes wrote: Hi! To not check class version in each method call, cloop-based interfaces implement class-upgrade at return and argument passing. If everything is simple, it (the mechanics) works. But not everything is simple. We have structs (Dtc::start - with DtcStart) with interfaces and pointers to classes (DbCryptPlugin::setKey), where a number of elements may be passed. It's not impossible, but I feel as a great level of complication to add to cloop things like IN/OUT parameters and instruction of how to decode length of buffers. And later we'll add another set of complication to deal. Also, I really don't believe that class-upgrade are going to work. There are various problems, like who allocate/deallocate memory for vtables, how to call a standard upgrade function (must be in IMaster/IUtl), but it's not always accessible (you can't just call fb_get_master, multiple client library may be dynamically loaded). Must say that we suggested in cloop fast version check (no virtual calls needed) there is no big difference between version upgrade and explicit version check. 2-3 additional machine instructions is nothing when doing virtual API calls. I.e. I agree that now version upgrade is not a requirement. Ok. I thought you were against it even with the if-check. I propose something different. Methods appeared in the first version of an interface must never be checked, as they will be always there. We should learn to distinguish what method is last. Not ot say it's too hard task but this must be done if we want to relay on it. I may add to cloop something to mark a set of methods for a version. I want to point you to one detail. It should be possible to specialize (in some way) action to be taken when interface version does not match to caller requirements. Currently function to upgrade version is specialized for one interface in trace plugin. It's good idea to have same functionality when checking version. I see it, but I really don't agree. I don't understand how one could call a method and just ignore if it's not called. This case must be for user to check the version before call. If we don't mess with the version field, it will be constant and the user may check it. Anyway, I think the police can deal with such cases. Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
