Recently moved from Redhat 5.5 to Redhat 7.3 and the Relativity server 2.1.0 has become much more unstable. Clients are also at version 2.1.0 using 64 bit odbc to do queries and updates to MF Cobol files. We are controlling the server using supervisorctl to keep it running all the time and sometimes it will crash w/in 24 hours of being restarted. Seeing errors like
*** Error in `/opt/microfocus/relativity/2.1.0/bin/reldbsrv': double free or corruption (!prev): 0x09385060 ***
Anyone have any suggestions on what to do to be more stable?
Also noticing that the timestamp of the relativity catalog files change during the day appearing to indicate that something is writing to them other than the creation from Relativity Designer - I find this odd, is it normal?
Thanks.
#RelativityThe crashing seems to indicate a problem with the data server. The C runtime could be doing additional tests. I wonder if there isn't an option to disable this.
As to the time stamp changing, the Data Server will update the catalog from time to time as it learns information about the size of the tables. SQL calls this cardinality, and it allows the SQL engine to make informed choices about how it optimizes queries. So, the timestamp changing on the catalog doesn't surprise me.
Recently moved from Redhat 5.5 to Redhat 7.3 and the Relativity server 2.1.0 has become much more unstable. Clients are also at version 2.1.0 using 64 bit odbc to do queries and updates to MF Cobol files. We are controlling the server using supervisorctl to keep it running all the time and sometimes it will crash w/in 24 hours of being restarted. Seeing errors like
*** Error in `/opt/microfocus/relativity/2.1.0/bin/reldbsrv': double free or corruption (!prev): 0x09385060 ***
Anyone have any suggestions on what to do to be more stable?
Also noticing that the timestamp of the relativity catalog files change during the day appearing to indicate that something is writing to them other than the creation from Relativity Designer - I find this odd, is it normal?
Thanks.
#RelativityHi MIke,
I understand now about the time stamp change on the catalog files - thank you for the helpful information.
In regard to the Relativity Data Server crashing can you please elaborate on the possible fixes to make the server more stable and your thought about the C runtime testing option?
Of note yesterday when I did a Relativity Server Status prior to it crashing one of the connections displayed had information that was all corrupted. How do you get the command relserveradmin -sss tcp:localhost.1583 to show the "real" application instead of just "unknown"? Also can I tell how long a connection has been open and does Relativity crash if a connection has been open for too long? Does the server need to be restarted on any particular timing?
Thanks.
Recently moved from Redhat 5.5 to Redhat 7.3 and the Relativity server 2.1.0 has become much more unstable. Clients are also at version 2.1.0 using 64 bit odbc to do queries and updates to MF Cobol files. We are controlling the server using supervisorctl to keep it running all the time and sometimes it will crash w/in 24 hours of being restarted. Seeing errors like
*** Error in `/opt/microfocus/relativity/2.1.0/bin/reldbsrv': double free or corruption (!prev): 0x09385060 ***
Anyone have any suggestions on what to do to be more stable?
Also noticing that the timestamp of the relativity catalog files change during the day appearing to indicate that something is writing to them other than the creation from Relativity Designer - I find this odd, is it normal?
Thanks.
#Relativity<<I did a Relativity Server Status prior to it crashing one of the connections displayed had information that was all corrupted>>
Interesting.
<<How do you get the command relserveradmin -sss tcp:localhost.1583 to show the "real" application instead of just "unknown"? >>
When the connection is made, the Data Client sends across information about the application that is using it. If it doesn't have this information, then Unknown is displayed. I'm not sure why the Data Client doesn't have the information in this case. We'd have to investigate the situation further.
<<Also can I tell how long a connection has been open>>
I believe that the Data Server is aware of the length that the connection has been open and will disconnect clients that have been inactive too long. There's a timeout value in the reldbsrv.ini configuration file (I think that's where it is), that can control this. Putting the length of time that the connection has been open would have been useful information to put in the display, but for some reason we didn't.
<<does Relativity crash if a connection has been open for too long? >>
No, that would be very bad and unacceptable behavior. What's supposed to happen is that the client will just discover that the TCP/IP connection has been closed when it attempts to use it. And it's not really the length of time that it has been connected. It's a timeout, so it's the length of time since the last activity.
<<Does the server need to be restarted on any particular timing?>>
No. I've got test servers that have run happily for several months.
So, based on what you've told me, I'm beginning to think that this is an issue with the OS rather than the Data Server. I don't have any idea how to chase this problem at the moment. I'll need to do some research. Being able to reproduce the behavior in house I think is the first step.
Is there anyway that you can drop back to a previous version of the OS until we can sort this out?
Recently moved from Redhat 5.5 to Redhat 7.3 and the Relativity server 2.1.0 has become much more unstable. Clients are also at version 2.1.0 using 64 bit odbc to do queries and updates to MF Cobol files. We are controlling the server using supervisorctl to keep it running all the time and sometimes it will crash w/in 24 hours of being restarted. Seeing errors like
*** Error in `/opt/microfocus/relativity/2.1.0/bin/reldbsrv': double free or corruption (!prev): 0x09385060 ***
Anyone have any suggestions on what to do to be more stable?
Also noticing that the timestamp of the relativity catalog files change during the day appearing to indicate that something is writing to them other than the creation from Relativity Designer - I find this odd, is it normal?
Thanks.
#RelativityHere is the odd display yesterday prior to it crashing ...
Mike - thanks for looking into this
Here was the odd display results yesterday before it crashed
You say the data client sends over the info on its connection - how do you set this in the odbc connection. For example I am running dBeaver from my laptop and when I run the display it shows my machine name properly but application is Unknown.
The only setup ini file that I have is the odbc.ini and here are my settings - so I do not see a timeout value
I am not able to drop back on the O/S and I cannot cause the crash to happen but it does seem to happen more often the more traffic it has. I am running version 2.1.0 is there a new server version coming out soon that may have addressed this bug? Also I am moving soon to MF Cobol version 3.0.0 will it matter what version of Relativity is running?
Thanks.
Recently moved from Redhat 5.5 to Redhat 7.3 and the Relativity server 2.1.0 has become much more unstable. Clients are also at version 2.1.0 using 64 bit odbc to do queries and updates to MF Cobol files. We are controlling the server using supervisorctl to keep it running all the time and sometimes it will crash w/in 24 hours of being restarted. Seeing errors like
*** Error in `/opt/microfocus/relativity/2.1.0/bin/reldbsrv': double free or corruption (!prev): 0x09385060 ***
Anyone have any suggestions on what to do to be more stable?
Also noticing that the timestamp of the relativity catalog files change during the day appearing to indicate that something is writing to them other than the creation from Relativity Designer - I find this odd, is it normal?
Thanks.
#RelativityCliff, I've discussed this with customer support and we'd like you to escalate this issue. Can you contact customer support so that we can create an official incident of this problem?
Recently moved from Redhat 5.5 to Redhat 7.3 and the Relativity server 2.1.0 has become much more unstable. Clients are also at version 2.1.0 using 64 bit odbc to do queries and updates to MF Cobol files. We are controlling the server using supervisorctl to keep it running all the time and sometimes it will crash w/in 24 hours of being restarted. Seeing errors like
*** Error in `/opt/microfocus/relativity/2.1.0/bin/reldbsrv': double free or corruption (!prev): 0x09385060 ***
Anyone have any suggestions on what to do to be more stable?
Also noticing that the timestamp of the relativity catalog files change during the day appearing to indicate that something is writing to them other than the creation from Relativity Designer - I find this odd, is it normal?
Thanks.
#Relativity<<I am running version 2.1.0 is there a new server version coming out soon that may have addressed this bug?>>
There is nothing at this time because there aren't any problems that would require a release. This one would be the first.
<<Also I am moving soon to MF Cobol version 3.0.0 will it matter what version of Relativity is running?>>
No, but you may need to reinstall the Relativity so that it will find the new version of Visual COBOL.
<<The only setup ini file that I have is the odbc.ini and here are my settings - so I do not see a timeout value>>
Open the Relativity Data Client help file. In the Contents tab, open For Advanced Users\\Relativity-Specific\\Relativity Options. On that page, click on the Simba Server Options link. There you'll find instructions for EnableIdleTimeouts and ConnectionIdleTimeout. EnableIdelTimeouts are enabled by default, so you'll just need to add a ConnectionIdleTimeout keyword to the SimbaServer section of the odbc.ini and then set it to the value you wish. The default is 360 minutes (6 hours). (Of course, if you never want it to timeout, add EnableIdleTimeouts with a value of 0 to disable the timeouts completely.
Recently moved from Redhat 5.5 to Redhat 7.3 and the Relativity server 2.1.0 has become much more unstable. Clients are also at version 2.1.0 using 64 bit odbc to do queries and updates to MF Cobol files. We are controlling the server using supervisorctl to keep it running all the time and sometimes it will crash w/in 24 hours of being restarted. Seeing errors like
*** Error in `/opt/microfocus/relativity/2.1.0/bin/reldbsrv': double free or corruption (!prev): 0x09385060 ***
Anyone have any suggestions on what to do to be more stable?
Also noticing that the timestamp of the relativity catalog files change during the day appearing to indicate that something is writing to them other than the creation from Relativity Designer - I find this odd, is it normal?
Thanks.
#RelativityI have been reminded that there is already a Relativity 2.2 for Visual COBOL. I can not tell you that it addresses this problem, but it's worth getting a copy and installing it. I'm sure that when you contact Customer Support, that's going to be the first thing that they will ask you to do.
Recently moved from Redhat 5.5 to Redhat 7.3 and the Relativity server 2.1.0 has become much more unstable. Clients are also at version 2.1.0 using 64 bit odbc to do queries and updates to MF Cobol files. We are controlling the server using supervisorctl to keep it running all the time and sometimes it will crash w/in 24 hours of being restarted. Seeing errors like
*** Error in `/opt/microfocus/relativity/2.1.0/bin/reldbsrv': double free or corruption (!prev): 0x09385060 ***
Anyone have any suggestions on what to do to be more stable?
Also noticing that the timestamp of the relativity catalog files change during the day appearing to indicate that something is writing to them other than the creation from Relativity Designer - I find this odd, is it normal?
Thanks.
#RelativityThank you Mike. I saw the client update for 2.2 but not the server so I wanted to see if the server would be coming soon. I will go ahead and open a case with customer support. Appreciate your time.
