I'm currently have a Firebird Super Server 2.1 x86 installed at my Ubuntu Server 11.0.
From time to time the server stops accept connections... resulting the error msg above (for clients)
"Connection not established. Connection rejected by remote interface."
To solve the problem, I need to restart the firebird service, and everything becomes OK!
The firebird.log does not tell me anything...
Any ideas about what is happening?
I had a similar instalation stack, and a similar problem.
I upgraded my firebird to version 2.1.4 after reading this bug fix that was backported from 2.5.
At the time, I also had to upgrade my hardware. The problem has not repeated since, but I'm not 100% sure that the upgrade solved the problem
Hope this helps.
Alejandro
Related
I have a situation where, after upgrading to the most recent version of Windows 10, I'm only able to log into my Azure VM once. After I log in the first time, if my connection drops for whatever reason (which it's liable to do as my connection here is very unreliable) then I can't reconnect. I have to reboot the machine. I'm able to get past the login, however when I'm on the welcome screen it freezes and then I'm unable to do anything.
After a reboot, I can then connect successfully again until the connection drops, and then I have to reboot the machine.
The Windows version is "Windows 10 Pro N", build is 10.0.18362.
Previous to the upgrade I was able to connect multiple times with no issues.
Does anybody have any ideas what I could look for?
Thanks very much in advance,
Dave
In this case, I suggest installing the latest hotfix on https://support.microsoft.com/en-sg/help/4517389/windows-10-update-kb4517389
Or resize your Azure VM.
Hope this could help you.
I need to get a 64-bit ODBC driver for a Windows 2008 r2 server to connect to an RDB database (v7.2). I downloaded the Oracle ODBC Driver for RDB 3.3.2.0 but I can't get it to connect.
Has anyone used this? Should I be able to connect using this?
The error I get at the moment is
recv() unexpected close ret ) err#0 unknown
I don't see any tnsnames or listener file with this driver are they required?
I've seen this error before and it normally relates to a server side SQL Services error.
Try restarting SQL Services on your VMS box.
There are no tnsnames files etc - you should be able to just setup a 64bit ODBC connection via control panel -> odbc as normal.
In practice though I have found the 64 bit ODBC drivers to be buggy, and have experienced much pain using them. Ditto for the .NET drivers.
(32bit has worked fine though. )
I remember seeing a roadmap from Oracle which stated that they were releasing a new (written from ground up) set of ODBC drivers for RDB 64 bit, so perhaps they do have an underlying issue. I just search for the link, but couldn't find it. If I do come across it again I'll make sure I add it here.
Oracle ODBC Driver for RDB is only for Oracle RDB Database.
Please raise a service request to Oracle Support.
This question is a bit tricky and I don't really think I'll find an answer but I'll try anyway.
I'm writing a C++ program using gloox for XMPP transfers. My problem , which is happening only on my computer, (Linux Mint 13 MATE 32bits) is that the "onConnect()" handler is never called. This was not a problem when we were using the jabber.org server (actually, I didn't even know it was not called...) but problems started occuring when we installed a LAN ejabberd server.
Using jabber.org server, even though "onConnect" was not called the application was able to send/receive messages fine. But not on ejabberd. At first I thought it was a problem with the certificate or something but then we tried on our other Linux boxes (Ubuntu 12.04 x64, Arch x64 and Debian 6.0 32(the server is running on this machine)) and it works fine on any of those computers. Plus, the sister application using Python-Twisted can connect fine on the problematic computer.
The validation function, onTLSConnect() is called everytime and it returns true. On the problematic computer, when using our ejabberd server, the connection isn't established after that and the socket closes it self after about 25 seconds ( and onDisconnect() is called...)
So, my question: Could there be an internet setting (like a firewall?) that is preventing Gloox to terminate the connection. OR has anyone experienced a similar issue?
Thanks!
EDIT: I made a VM of Mint 13 MATE 32bits on my laptop and the same problem arises. I can now conclude it's bug somewhere in mint.
EDIT2: Works fine on Mint 64 bits....I opened a ticket on Mint's bug page
i meet this problem last week, it seems a bug of gloox.
it happened on 32 bit linux.
see this https://bugs.launchpad.net/linuxmint/+bug/1071416
in fact.you are "online" on the server, but your "presence" state is unknown. you can simply send a "Chat" state to the server to continute your work.
like this
#ifdef GLOOX_ON_CONNECT_BUG_PATCH
Poco::Thread::sleep(3000);//休息3秒，然后连接成功,哎，该死的bug
this->is_connected = true;
client->setPresence(Presence::Chat, 0);
#endif
I have a new tomcat application server running on tomcat 6, java 6 (openjdk), centos 6.2. The server is a virtual machine running under qemu-kvm on a centos 6.2 host. Both host and guest are 64-bit.
I have a case where a connection is opened, (from a connection pool) then a "long computation" occurs for about 4 hours, during which the connection is not used. Finally, a "commit" is issued, and the server gives a "connection reset" exception, specifically:
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:185)
at oracle.net.ns.Packet.receive(Packet.java:282)
at oracle.net.ns.DataPacket.receive(DataPacket.java:103)
at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:230)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:175)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:100)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:85)
at oracle.jdbc.driver.T4CSocketInputStreamWrapper.readNextPacket(T4CSocketInputStreamWrapper.java:122)
at oracle.jdbc.driver.T4CSocketInputStreamWrapper.read(T4CSocketInputStreamWrapper.java:78)
at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1179)
at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1155)
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:279)
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:186)
at oracle.jdbc.driver.T4C7Ocommoncall.doOCOMMIT(T4C7Ocommoncall.java:75)
at oracle.jdbc.driver.T4CConnection.doCommit(T4CConnection.java:558)
The database server and the client are on the same subnet, except the server is a real physical host, and obviously the app-server is a guest running inside a physical machine on the same subnet.
The host used "bridged" networking.
This may not be a software problem at all but rather a linux os configuration (iptables?) issue, but I really don't know.
I have run into this a couple of times. Almost always caused by a network timeout (load balancer or firewall). But you have clearly mentioned that your servers are on the same subnet, so not really sure what is going on. Since you suspect iptables, can you turn it off, run the test and see if it works (too easy huh :)
Regardless, assuming you are connecting to an Oracle db, the following tweak helps
http://raibledesigns.com/rd/entry/tomcat_oracle_connectivity_problems
If you use a different db (say mysql) the setting might be different but the logic is the same. Setup a keepalive value to prevent the connection from being idle for too long. This way the firewal/load balancer/iptables software will not terminate it.
As you can see in this post in Oracle Forums, this can have more than one problem / solution.
Check if your JDBC driver version is correct
Check your ORACLE_HOME environment variable
try add the argument -Djava.security.egd=file:///dev/urandom
Your logic use a singleton to get the connection? In the post this are mentioned too
Hope this helps you.
#user is referring to a good workaround, by configuring "SQLNET.EXPIRE_TIME=10" in sqlnet.ora.
However, this workaround is only applicable if your application is using thick OCI (jdbc:oci), not thin (jdbc:thin) driver.
Linux has software firewall, i.e. iptables, which can drop idle network connection, so even you are in the same subnet, you have iptables software firewall. This is activated by default in all modern Linux, and up to Linux administrator to disable it.
By default, Linux iptables does not drop idle TCP/IP connections (jdbc belongs to TCP/IP protocol), so the Linux administrator must configured iptables to do so. Following is the detail explanation for any reader who are interested to know more:
http://www.digitage.co.uk/digitage/software/linux-security/cutter
Business users, security team, or architect often suggest network/OS admin to abort idle connection using firewall, as well as router. This is always a "recommendation" in the anti-hacking community, but it is not properly discussed, and causing application instability. Eventually, you should discuss with the team to find a balance
I'm exploring porting a .NET C# application from Windows to Linux using Mono. The problem I'm stuck with is that asynchronous TCP socket calls do not work. This means that I can send data with no problems but I'm only seem to be able to receive the very first response from the socket (via Socket.BeginReceive()). The next BeginReceive() puts the thread into a wait state.
In it possible in principle that our socket code contains a bug but as it's been working flawlessly in Windows for years.
Thank you
This works fine with the mono-2-10 branch (soon to be released as Mono 2.10) and master.
The Mono 2.6.7 shipped with ubuntu fails and so does Mono 2.8. I've found the problem and I am testing a fix.. The next releases in the 2.6.x series will have the fix (also 2.8.x if there's any, since we are moving to 2.10 in a few days).
Btw, you should report problems in Mono following http://mono-project.com/Bugs instead of here.
If you use a synchronous socket, do things work as expected? That's a quick way to help narrow down the issue.