Does sbmonitor use 32-bit integers

[László Tenki]

I was monitoring one of my apps earlier today and after about 12 hours of running I saw that the main stream was approaching 2.1 billion tuples. Then I worked on something else for a while and half an hour later the same stream showed N/A. The other streams continued counting, the app worked well without problems. I didn't see it happening and of course I can't support my suspicion with facts but I feel that it turned from a number to N/A when it passed 2,147,483,647, which is the highest positive number that can be represented by an int32. I checked the Linux binary and to me it seems that it's a 64-bit one. I hope I'm not wrong. (It's clear that the Windows version of sbmonitor is a 32-bit exe.) Is it possible that the Linux version is a 64-bit binary but uses int32 variables that can overflow

[Steve Barber]

Ugh. Yes. I just had a look at the sbmonitor source code. Even though the value that the StreamBase server is sending is created from a StreamBase long (8 byte value on the wire), sbmonitor is using a C++ int to hold it and then converts it to a string.

You don't say what platform you are using (Windows Linux MacOS) or StreamBase version. That would be helpful to know.

However, on Windows using Visual Studio, which we do, an int is 4 bytes, so yes, sbmonitor is going to get rollover there right where you speculated it would on Windows, at least. I didn't research the other platforms and my C++ knowledge is far less than encyclopedic.

Definitely worth opening a Product Support Case to report the bug if this behavior is going to be an ongoing problem for you.

I wouldn't be surprised if sbmanager handles this situation more gracefully. You might want to try that out.

[László Tenki]

We're using 7.6 and 7.7.3 here in the team, but I'm only working with 7.7.3. Dev is done on Windows, prod applications run on Linux, some of them using the Zing JVM (most is on Oracle though). I noticed the above phenomenon on Linux (RedHat, if that's important).

 

I'm not sure what you mean by Visual Studio not supporting 8-byte integers. It's not really the IDE, but C# definitely has an int64/long data type.

[Steve Barber]

Sorry, I was imprecise when I wrote "Visual Studio" -- I meant to say "Visual C++."  Whatever you want to call the C++ that Microsoft sells. (Not C#, as you wrote. No one was talking about C#. sbmonitor is written in C++.) C++ supports integers longer than 32-bits, too. It's just that sbmonitor explicitly uses the int datatype, and the int datatype is 32 bits even on 64 bit platforms when using Visual C++. Also, the int datatype on a 64-bit RHEL using g++ is also 32 bits. (Verified on RHEL 6.7.) (Usually on these platforms in C++ when you want a 64-bit integer you would specify a long datatype, unless you were using, for example, the Visual C++-specific datatypes like __int64, which sbmonitor does not use.) So as I mentioned before, I think we have a bug in this area in sbmonitor -- and it is almost certainly a bug that has been around for years and years. I went ahead a put in an engineering ticket about this issue. It is SB-46237. (Just entering a ticket doesn't promise a resolution or indicate any timeframe for a resolution.) If you want to escalate this issue further and have a current Maintenance agreement that covers TIBCO StreamBase, please enter a Support Case referencing ticket SB-46237 via support.tibco.com.

[László Tenki]

Thank you for the response, it was very helpful. We have support and we'll discuss in the team if we want to have a fast lane for this. It's not very often that an app passes the 2bn tuple limit so doesn't seem that urgent.