Dan,
Thank-you for responding. More generally, thank-you for monitoring
u2-list so closely. So, under the theory that no good deed should go
unpunished, I have a couple follow-up questions for you.
1. Your "*planning*" comment confuses me.
It can be taken 2 ways. Are you saying Rocket is (a) planning NOT to do
11.1.x bug fix releases; or (b) not CURRENTLY planning any such bug fix
releases because none have been identified yet?
For example, John Hester's localtime() / telnet problem surfaced in
11.1 (telnet handling changed dramatically at 11.1 to accommodate the
Date Replication changes), I would think you would offer an 11.1.x bug
fix so a user does not need to do a major jump to 11.2 to get the fix.
I suppose it depends on whether there is a good workaround, & Mr. Hester
seems satisfied with his.
Because 11.1 is still in "GA" status, and because 11.2 is still young,
I would think bugs that are found to be in 11.1 would still be fixed
with an 11.1.16, .17, etc.. At this late stage of 11.1 I would think
the only releases would be unplanned bug fixes. Yes, unplanned until
another 11.1 bug is found, but once found, let the planning commence.
If you've followed this thread, you'll recall my organization is
extraordinarily reluctant to make install major uv releases w/o
extensive regression testing due to past wounds. If we encounter a bug
in 11.1.15 will we be told, sorry, no fix unless you upgrade to 11.2.x?
That won't sit well. It even negates my reason for going to the highest
11.1.x instead of a point release with a plethora of current satisfied
users.
2. The version numbering scheme itself confuses me.
What sort of thing would call for a jump from 11.x to 12.1? (Or will it
be 12.0?) vs. 11.n to 11.[n+1] ? Why was it called 11.1 instead of 10.4?
The new Metadata Manager (U2 MDM) was introduced in 11.1.11, a minor
point release. To my way of thinking, that would have triggered
"11.2". And the existing new 11.2 would have been called 12.1.
I thought the minor point releases were generally for bug fixess, not
new functionality.
Maybe you could clarify the naming scheme?
Thanks in advance,
Chuck
On 2/28/2014 8:25 PM, Daniel McGrath wrote:
> Hi Charles,
>
> It does not affect Windows. At this point, we are not *planning* any
further 11.1.x releases so we can focus on the 11.2.x and .NEXT releases
of UniVerse and moving the technology forward.
>
> I also misspoke on 11.2.4 as it was a mistake in our issue system. It
is actually 11.2.3.
>
> Regards,
>
> Dan
>
> -----Original Message-----
> From: Charles Stevenson
> Sent: Friday, February 28, 2014 9:31 AM
>
> is this unix-, linux-specific or windows, too?
> Fix in 11.2.4, but in 11.1.16 too? That's the usual practice, isn't it?
>
> On 2/28/2014 6:50 PM, Daniel McGrath wrote:
>> As an FYI, I'm sitting in a meeting now were we are pulling a
check-in to use a re-entrant version of the function for our latest
build to fix this issue. You should expect a fix in 11.2.4 unless
something goes wrong.
>>
>> Regards,
>> Dan
>>
>> -----Original Message-----
>> From: John Hester
>> Sent: Thursday, February 27, 2014 4:59 PM
>>
>> We migrated from UV 10.2.7 on RedHat 5.1 x86 to 11.1.13 on RedHat
6.4 x64 last November. I've since run into a bug that can reveal itself
when tty processes are terminated. It could be unique to linux, but you
may want to watch for it. The symptoms are that terminated UV tty
processes disappear from LISTU and PORT.STATUS, but continue to exist in
the process table and consume a UV per-seat license. I discovered the
issue when we ran out of licenses after a couple of months of uptime and
I initially couldn't figure out where they went. Running the "ps"
command at the OS level revealed their existence. I'm guessing the
issue occurs on maybe 1 out of 200 or 300 tty sessions.
>>
>> The root cause of the issue is the localtime() function being called
from the signal handler. The localtime() function is not POSIX
async-signal-safe, which means it can't be safely called from there.
The function acquires a lock which may already be held by the process
that was interrupted by the signal if it too was in localtime(). When
this happens, a deadlock is the result and the process is in limbo
forever. I was able to easily work around the issue by having cron run
a script after hours every day to clean up any hung UV processes and
recover the licenses. I opened a ticket with Rocket, and they're
planning to include a fix for the issue in 11.2.4.
>>
>> I'm happy to provide my workaround script to anyone who runs into
this on a linux or unix box. Unfortunately, I'm not sure how one would
craft a workaround on Windows.
>>
>> -John
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
