Re: [U2] uv v ud
Brian and Symeon, since mv.NET is wrapping UO.NET, the issues you mention don't apply: - Bill isn't managing the UO.NET API calls, so he has no control over them. - Once the connection is established, only one client process has access to any given server connection. Therefore, no multi-threading. - mv.NET actually does interface through a BASIC call as described. Regarding large items, I'm not sure what's happening at that level but I believe it's handled properly. I would comment that a return value should not cause a component like UONET.DLL to log a vague error without throwing an exception, and that if this is a recognized issue that it should have been addressed a long time ago. If there are function calls that are known to be flaky outside of subroutine calls, I would also hope that these have been documented and passed to RS for resolution. The next step in the diagnostic for anyone with these mystery logs would be to put Symeon's trace flags into web.config. That information can then be sent to RS for comment. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] uv v ud
All good advice Brian, we do the same with points 1 and 2 re just calling
subroutines and doing logging if needs be to file, i also have a simple php
interface to the backend so we can test the backend standalone without
uniobjects or .net - which is very usefull. The data size is interesting and
something I shall certainly be investigating is 32k the actual limit ? Where
did you glean this information ?, also point 4 intrigues me - i don't think
this is required in an asp.net environment, where i have a webservice, with
an open connection, call, close connection? For both pooled and non pooled
...
Rgds
Symeon.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: 06 May 2011 09:13
To: 'U2 Users List'
Subject: Re: [U2] uv v ud
Bill
Four things architecturally have helped me when using UO - the first couple
may be too late but the fourth may be useful:
1. I only use UO to call subroutines. These have a common calling interface
so there is a single dispatch point in the client where I can add logging
and a despatch routine on the server where I can also add logging. It means
some constraints but they can be got round. Also, I've learned the hard way
to cut large strings being passed back - the despatch method checks the
length of the outgoing argument and has a 'more' flag set to get the rest of
it. Cutting to 32k is safest.
2. This approach also means I can use a test rig to check the subroutines
independently of the client, which can help identify issues.
3. If I need to watch stuff in real time, I have a global logger that acts
as a socket client. I can therefore send stuff to it from both the client
and the server to get a complete end to end trace, which saves a lot of time
otherwise spent trying to line up client and server logs.
4. Remember that UO.Net calls are single threaded.. so ensure you are using
lock{} structures (VB SyncLock) around your calls. .Net may have events
interfering with each other.
Brian
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1325 / Virus Database: 1500/3618 - Release Date: 05/05/11
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] uv v ud
Bill
Four things architecturally have helped me when using UO - the first couple
may be too late but the fourth may be useful:
1. I only use UO to call subroutines. These have a common calling interface
so there is a single dispatch point in the client where I can add logging
and a despatch routine on the server where I can also add logging. It means
some constraints but they can be got round. Also, I've learned the hard way
to cut large strings being passed back - the despatch method checks the
length of the outgoing argument and has a 'more' flag set to get the rest of
it. Cutting to 32k is safest.
2. This approach also means I can use a test rig to check the subroutines
independently of the client, which can help identify issues.
3. If I need to watch stuff in real time, I have a global logger that acts
as a socket client. I can therefore send stuff to it from both the client
and the server to get a complete end to end trace, which saves a lot of time
otherwise spent trying to line up client and server logs.
4. Remember that UO.Net calls are single threaded.. so ensure you are using
lock{} structures (VB SyncLock) around your calls. .Net may have events
interfering with each other.
Brian
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] uv v ud
Hi Bill I ran into a funny like that. The application was compile with an old version of uniobjects .Net and had an issue with the new version of universe. I recompiled with the new version of uniobjects and the issue went away. Other area to look for - I have had issues where a subroutine returned an unsigned variable, make sure all variables are assigned when being returned back. - Check the size of strings being passed back, a program may be passing back a long string as the result of a program bug. It may be a corrupt record. The problem with pick is we look at fld 10 and don't care what is after. You can have a corrupt record with garbage on the end and it will not impact data quality in the application but it will impact on performance. I have found uniobjects to be quite robust, but really only use it to make calls to subroutines, I don't use other functionality. Whilst you can write business logic in the .Net client, there is a question if that does not breach good practice in relation to client server. You should keep your business rules in a central place where you can change it once. You cannot afford to update a 100 desktop applications every time you need to change business logic. David Jordan ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] uv v ud
David: First off, this isn't a "reproducible" problem. If it were, we'd all have a solution. I have a hard time submitting something to UO support that they can't reproduce. Their support is good, but what can they do? For instance, several years ago one of our hosted clients would produce a spooler entry that increased in size until the partition UD was on ran out of disk space, and our hosted environment came crashing down! UD support (aka Wally) was very good at getting back with me but we couldn't reproduce the problem. It was a single page report loading over, and over, and over again until the spooler entry ended up being 20Gb. The solution was to move the "_HOLD_" file off the UD partition and off the O/S partition (luckily we build all machines with a C: - O/S, D: - win apps, and E: - UD and data). But we never did find out what the problem was caused by. It occurred again a couple of times but we never could come close to reproducing it. Regarding UO, I've got some Windows event logs and I have no idea what in the world I'm looking for. Secondly, our resources are always strained with the multi-layered technology environment we find ourselves in these days. Our employees don't wait for their paychecks while we try to track down UO problems. So, we spend our time monitoring if anything bad percolates through to our clients accounts. If we can't find anything we move on, but keep monitoring. What more can we do? Finally, when someone on this list asks if anyone knows of problems about...yada, yada, yada, we try to be helpful, and often reply off-list. We aren't casting aspersions toward RS support, we're just trying to answer users questions and discuss common themes that thread themselves throughout our technology environment. HTH, Bill - Original Message - *From:* dwolv...@flash.net *To:* 'U2 Users List' *Date:* 5/4/2011 1:08 PM *Subject:* Re: [U2] uv v ud SO... what does Rocket say when you ask for Support on UO? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Wednesday, May 04, 2011 1:15 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] uv v ud Since I'm mentioned here... As Bill's vendor and support provider for mv.NET I feel bad when underlying technologies fail. Metaphorically speaking, the auto mechanic can't fix potholes, only help to improve the shock absorbers to make the bumps less painful. As Bill's friend, we frequently discuss the issues of multi-tier development and I get as frustrated as he does. With UO.NET, exceptions are sometimes thrown which log errors with no detail. The exception is not passed up to the client. The net result is that "something" has failed, we don't know what it was, we don't have any way to control it, and we don't know if it has adversely affected our transaction processing. It "looks" like everything is OK, except for these mysterious logs. Symeon posted some great info here many months ago about setting tracking info for UO.NET in web.config. I passed that to Bill a while back but haven't heard back. In line with Bill's comments, error tracking like this is just another tier of time consuming aggravation. The burden of debugging issues like this is shared amongst many people, including those who don't know and should not have to know about the underlying technologies. When UO/UO.NET works, it's great. But frankly, over the long term, UO/UO.NET has been a chronic source of low-level pain, and it's Extremely difficult to get anyone to help diagnose or remedy related issues. Developers and end-users are left to scratch their heads for months wondering how to diagnose the black box. It would really be nice for Rocket to step up with a UO Trauma Center to quickly diagnose and resolve chronic, nagging communications issues. As Bill's mv.NET vendor I can't continue to spend hours trying to debug UO potholes - I have no code and can't interpret logs. Bill shouldn't have to do that either. The people with the code should be supporting that component. Regards, T From: Bill Haskett An interesting side note is debugging. When technologists suggest we use a "black-box" technology approach, all this does is create massive investigation problems in a "layered" environment; which most are today. For not-easily-reproducible problems, logging exacerbates the problem because now where we're looking for a needle problem located somewhere in these large haystack logs. :-) ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] uv v ud
SO... what does Rocket say when you ask for Support on UO? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Wednesday, May 04, 2011 1:15 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] uv v ud Since I'm mentioned here... As Bill's vendor and support provider for mv.NET I feel bad when underlying technologies fail. Metaphorically speaking, the auto mechanic can't fix potholes, only help to improve the shock absorbers to make the bumps less painful. As Bill's friend, we frequently discuss the issues of multi-tier development and I get as frustrated as he does. With UO.NET, exceptions are sometimes thrown which log errors with no detail. The exception is not passed up to the client. The net result is that "something" has failed, we don't know what it was, we don't have any way to control it, and we don't know if it has adversely affected our transaction processing. It "looks" like everything is OK, except for these mysterious logs. Symeon posted some great info here many months ago about setting tracking info for UO.NET in web.config. I passed that to Bill a while back but haven't heard back. In line with Bill's comments, error tracking like this is just another tier of time consuming aggravation. The burden of debugging issues like this is shared amongst many people, including those who don't know and should not have to know about the underlying technologies. When UO/UO.NET works, it's great. But frankly, over the long term, UO/UO.NET has been a chronic source of low-level pain, and it's Extremely difficult to get anyone to help diagnose or remedy related issues. Developers and end-users are left to scratch their heads for months wondering how to diagnose the black box. It would really be nice for Rocket to step up with a UO Trauma Center to quickly diagnose and resolve chronic, nagging communications issues. As Bill's mv.NET vendor I can't continue to spend hours trying to debug UO potholes - I have no code and can't interpret logs. Bill shouldn't have to do that either. The people with the code should be supporting that component. Regards, T > From: Bill Haskett > An interesting side note is debugging. When > technologists suggest we use a "black-box" technology > approach, all this does is create massive > investigation problems in a "layered" environment; > which most are today. For not-easily-reproducible > problems, logging exacerbates the problem because now > where we're looking for a needle problem located > somewhere in these large haystack logs. :-) ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] uv v ud
Since I'm mentioned here... As Bill's vendor and support provider for mv.NET I feel bad when underlying technologies fail. Metaphorically speaking, the auto mechanic can't fix potholes, only help to improve the shock absorbers to make the bumps less painful. As Bill's friend, we frequently discuss the issues of multi-tier development and I get as frustrated as he does. With UO.NET, exceptions are sometimes thrown which log errors with no detail. The exception is not passed up to the client. The net result is that "something" has failed, we don't know what it was, we don't have any way to control it, and we don't know if it has adversely affected our transaction processing. It "looks" like everything is OK, except for these mysterious logs. Symeon posted some great info here many months ago about setting tracking info for UO.NET in web.config. I passed that to Bill a while back but haven't heard back. In line with Bill's comments, error tracking like this is just another tier of time consuming aggravation. The burden of debugging issues like this is shared amongst many people, including those who don't know and should not have to know about the underlying technologies. When UO/UO.NET works, it's great. But frankly, over the long term, UO/UO.NET has been a chronic source of low-level pain, and it's Extremely difficult to get anyone to help diagnose or remedy related issues. Developers and end-users are left to scratch their heads for months wondering how to diagnose the black box. It would really be nice for Rocket to step up with a UO Trauma Center to quickly diagnose and resolve chronic, nagging communications issues. As Bill's mv.NET vendor I can't continue to spend hours trying to debug UO potholes - I have no code and can't interpret logs. Bill shouldn't have to do that either. The people with the code should be supporting that component. Regards, T > From: Bill Haskett > An interesting side note is debugging. When > technologists suggest we use a "black-box" technology > approach, all this does is create massive > investigation problems in a "layered" environment; > which most are today. For not-easily-reproducible > problems, logging exacerbates the problem because now > where we're looking for a needle problem located > somewhere in these large haystack logs. :-) ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] uv v ud
I was just pondering that problem as you wrote that Bill. :0) On Wed, May 4, 2011 at 12:30 PM, Bill Haskett wrote: > Isn't that the truth. An interesting side note is debugging. When > technologists suggest we use a "black-box" technology approach, all this > does is create massive investigation problems in a "layered" environment; > which most are today. For not-easily-reproducible problems, logging > exacerbates the problem because now where we're looking for a needle problem > located somewhere in these large haystack logs. :-) > > Bill > > > - Original Message - > *From:* cwn...@comcast.net > *To:* U2 Users List > *Date:* 5/4/2011 8:59 AM > *Subject:* Re: [U2] uv v ud >> >> Hi Bill, >> >> A little off-topic, but it seems that whenever you get 2 or more vendors >> involved in anything, they automatically start blaming the other, and >> nothing gets done. >> >> Charlie Noah >> Charles W. Noah Associates >> cwn...@comcast.net >> >> The views and opinions expressed herein are my own (Charlie Noah) and do >> not necessarily reflect the views, positions or policies of any of my >> former, current or future employers, employees, clients, friends, enemies or >> anyone else who might take exception to them. >> >> >> On 05-04-2011 10:49 AM, Bill Haskett wrote: >>> >>> Symeon: >>> >>> We use mv.NET with "uodotnet" and have seen various Windows errors. Tony >>> G. indicated that mv.NET is just a wrapper for UO.NET, at this level, and >>> the problem is with "uodotnet". We're running UD V7.1.9 in our production >>> environment and "uodotnet.dll" v2.1.1.7211. >>> >>> I'm not a rocket scientist, :-) , but I tend to think Tony is correct. >>> I have no idea how to correct this and neither does Tony. It seems to be a >>> classic case of layering technology and the fingers start pointing in >>> opposite directions! :-) >>> >>> Let me know if the U2 guys find out anything. Thanks, >>> >>> Bill >>> >>> >>> - Original Message - >>> *From:* syme...@gmail.com >>> *To:* 'U2 Users List' >>> *Date:* 5/4/2011 2:16 AM >>> *Subject:* [U2] uv v ud >>>> >>>> Hi >>>> >>>> I seem to recall someone stating recently that uniobjects works much >>>> better >>>> with uv rather than ud, something to do with connection times etc. >>>> >>>> We are on ud71 on redhat ES 4 and do have problems with uniobjects.net >>>> with >>>> regard speed and stability. >>>> >>>> Does anyone have any experience / confirmation on this at all ?? >>>> >>>> Thanks >>>> >>>> Symeon. > > ___ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] uv v ud
Isn't that the truth. An interesting side note is debugging. When technologists suggest we use a "black-box" technology approach, all this does is create massive investigation problems in a "layered" environment; which most are today. For not-easily-reproducible problems, logging exacerbates the problem because now where we're looking for a needle problem located somewhere in these large haystack logs. :-) Bill - Original Message - *From:* cwn...@comcast.net *To:* U2 Users List *Date:* 5/4/2011 8:59 AM *Subject:* Re: [U2] uv v ud Hi Bill, A little off-topic, but it seems that whenever you get 2 or more vendors involved in anything, they automatically start blaming the other, and nothing gets done. Charlie Noah Charles W. Noah Associates cwn...@comcast.net The views and opinions expressed herein are my own (Charlie Noah) and do not necessarily reflect the views, positions or policies of any of my former, current or future employers, employees, clients, friends, enemies or anyone else who might take exception to them. On 05-04-2011 10:49 AM, Bill Haskett wrote: Symeon: We use mv.NET with "uodotnet" and have seen various Windows errors. Tony G. indicated that mv.NET is just a wrapper for UO.NET, at this level, and the problem is with "uodotnet". We're running UD V7.1.9 in our production environment and "uodotnet.dll" v2.1.1.7211. I'm not a rocket scientist, :-) , but I tend to think Tony is correct. I have no idea how to correct this and neither does Tony. It seems to be a classic case of layering technology and the fingers start pointing in opposite directions! :-) Let me know if the U2 guys find out anything. Thanks, Bill - Original Message - *From:* syme...@gmail.com *To:* 'U2 Users List' *Date:* 5/4/2011 2:16 AM *Subject:* [U2] uv v ud Hi I seem to recall someone stating recently that uniobjects works much better with uv rather than ud, something to do with connection times etc. We are on ud71 on redhat ES 4 and do have problems with uniobjects.net with regard speed and stability. Does anyone have any experience / confirmation on this at all ?? Thanks Symeon. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] uv v ud
As Tony says MV.NET just uses the uodotnet dll as a pipe to the u2 server, the errors will be with the uodotnet, What type of errors do you get? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: 04 May 2011 16:49 To: U2 Users List Subject: Re: [U2] uv v ud Symeon: We use mv.NET with "uodotnet" and have seen various Windows errors. Tony G. indicated that mv.NET is just a wrapper for UO.NET, at this level, and the problem is with "uodotnet". We're running UD V7.1.9 in our production environment and "uodotnet.dll" v2.1.1.7211. I'm not a rocket scientist, :-) , but I tend to think Tony is correct. I have no idea how to correct this and neither does Tony. It seems to be a classic case of layering technology and the fingers start pointing in opposite directions! :-) Let me know if the U2 guys find out anything. Thanks, Bill - Original Message - *From:* syme...@gmail.com *To:* 'U2 Users List' *Date:* 5/4/2011 2:16 AM *Subject:* [U2] uv v ud > Hi > > I seem to recall someone stating recently that uniobjects works much better > with uv rather than ud, something to do with connection times etc. > > We are on ud71 on redhat ES 4 and do have problems with uniobjects.net with > regard speed and stability. > > Does anyone have any experience / confirmation on this at all ?? > > Thanks > > Symeon. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1325 / Virus Database: 1500/3613 - Release Date: 05/03/11 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] uv v ud
Hi Bill, A little off-topic, but it seems that whenever you get 2 or more vendors involved in anything, they automatically start blaming the other, and nothing gets done. Charlie Noah Charles W. Noah Associates cwn...@comcast.net The views and opinions expressed herein are my own (Charlie Noah) and do not necessarily reflect the views, positions or policies of any of my former, current or future employers, employees, clients, friends, enemies or anyone else who might take exception to them. On 05-04-2011 10:49 AM, Bill Haskett wrote: Symeon: We use mv.NET with "uodotnet" and have seen various Windows errors. Tony G. indicated that mv.NET is just a wrapper for UO.NET, at this level, and the problem is with "uodotnet". We're running UD V7.1.9 in our production environment and "uodotnet.dll" v2.1.1.7211. I'm not a rocket scientist, :-) , but I tend to think Tony is correct. I have no idea how to correct this and neither does Tony. It seems to be a classic case of layering technology and the fingers start pointing in opposite directions! :-) Let me know if the U2 guys find out anything. Thanks, Bill - Original Message - *From:* syme...@gmail.com *To:* 'U2 Users List' *Date:* 5/4/2011 2:16 AM *Subject:* [U2] uv v ud Hi I seem to recall someone stating recently that uniobjects works much better with uv rather than ud, something to do with connection times etc. We are on ud71 on redhat ES 4 and do have problems with uniobjects.net with regard speed and stability. Does anyone have any experience / confirmation on this at all ?? Thanks Symeon. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] uv v ud
Symeon: We use mv.NET with "uodotnet" and have seen various Windows errors. Tony G. indicated that mv.NET is just a wrapper for UO.NET, at this level, and the problem is with "uodotnet". We're running UD V7.1.9 in our production environment and "uodotnet.dll" v2.1.1.7211. I'm not a rocket scientist, :-) , but I tend to think Tony is correct. I have no idea how to correct this and neither does Tony. It seems to be a classic case of layering technology and the fingers start pointing in opposite directions! :-) Let me know if the U2 guys find out anything. Thanks, Bill - Original Message - *From:* syme...@gmail.com *To:* 'U2 Users List' *Date:* 5/4/2011 2:16 AM *Subject:* [U2] uv v ud Hi I seem to recall someone stating recently that uniobjects works much better with uv rather than ud, something to do with connection times etc. We are on ud71 on redhat ES 4 and do have problems with uniobjects.net with regard speed and stability. Does anyone have any experience / confirmation on this at all ?? Thanks Symeon. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] uv v ud
Hi I seem to recall someone stating recently that uniobjects works much better with uv rather than ud, something to do with connection times etc. We are on ud71 on redhat ES 4 and do have problems with uniobjects.net with regard speed and stability. Does anyone have any experience / confirmation on this at all ?? Thanks Symeon. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
