Re: [U2] Recommended 11.1.point release to upgrade to.

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