We have noticed that with the 2012 NetSuite Web services (and perhaps all other versions), when we make a call from a .NET 2.0 64-bit application, if the response does not come back quickly, then intermittently our application will hang however in the NetSuite application logs it appears the SOAP call was successful. The hang eventually times out (timeout) after 5 minutes (!) because NetSuite (or something) keeps the socket open, it just stops sending packets.
We ran a Network Trace and noticed packets coming out of order, being dropped, inexplicable duplicate acks - etc. Essentially, it "freaks out". Microsoft techs have never seen anything like it - least the ones I talked too.
We ran a simple test app that does nothing more than passport in, then do a query for Accounting Periods. It's the search method that hangs as it's parsing the SOAP response - always gets about 10s in.
As soon as we target a 32-bit environment, everything works like a charm, even though the 32-bit binary is running on a 64 bit OS. Clearly, running as a 64-bit app sets some network protocol configuration that NetSuite really doesn't like.
We tested on Azure, Amazon and on a local (to our corporate network) Windows 2008 R2 SP1 64 bit servers - physical and VM's.
We don't have hard evidence of the "why" this is happening, but after a month of pulling our hair out (we're all bald now) we think we've stumbled upon an issue. This one is so weird, however, I'm not willing to go out and claim that it's still not something we're doing. So, if you don't believe:
Open Visual Studio 2010 and create an .NET 2.0 console application targeting "Any CPU".
Do a "Add Web reference..." and add the NetSuite WSDL.
Create a simple passport login and do a search that returns something with some volume.
Run the EXE on a 64-bit OS, several times (this bug is intermittent), during peak working hours (i.e. appears around 7am - 2pm PST).
That's exactly what we did. If you go back and create a new x86 target and rebuild the project, it works fine.
Related
I am facing a strange issue. I have a UWP app published in store. When I deploy this app to my Lumia 930 through the store, it runs very slowly. However, the same app when I deploy to the same device in debug mode from VS 2015, it works fast. To be specific, I am relying on heaving caching in a Sqlite database for displaying the results, plus I also have lot of List processing done in my logic. In debug mode, one specific page with particular set of data takes around 3 seconds to load and show the results. The same page with same data takes 8-9 seconds when running on the same device but downloaded from the store.
Any idea, what I am doing wrong, or is there something which I am missing. The particular app in question is: https://www.microsoft.com/en-us/store/apps/series-tracker/9nblggh3slj9
Appreciate your help.
This one is too bizarre for me. In my Framework 4.0 WinForms app, FileSystemWatcher recently started giving me a null for OldName and only the parent folder for OldFullPath, not the full path of the old filename. However, some of the Windows 7 computers do this while others do not. I tried uninstalling our company anti-virus program temporarily but that didn't make any difference. I rolled back my code but it didn't make any difference.
I tried switching my application from Framework 4.0 to 4.5.2 but the problem persisted. In fact, I believe the problem is at a lower level than .NET because I wrote a test C++ program that uses ReadDirectoryChangesW() and a similar problem occurs: the problem computer never receives the FILE_ACTION_RENAMED_OLD_NAME notification, only the FILE_ACTION_RENAMED_NEW_NAME one.
I compared running processes and ended ones that are running on the problem computer but not on the non-problem one. Both computers are up to date with Windows Updates; I am hoping not to have to start uninstalling them.
I have one Windows 8 computer and the problem is not there; however, upgrading from 7 to 8 is not an option for several other deployments.
It just occurred to me to look at kernel32.dll on the respective machines, since that is where ReadDirectoryChangesW() lives. It's different.
Worky: v6.1.7601.18798
No worky: v6.1.7601.18869
Was there a recent change to the API that I need to accommodate?
Update: I found a non-working machine with v6.1.7601.18409 so that's not the problem.
In a word, Kaspersky.
To elaborate, I thought I had already tested removing KAS but maybe I didn't reboot after or something, and it's odd because it is also installed on a computer at work that does not present the problem--same version of KAS.
Note that this version is a corporate version, which installs:
Kaspersky Endpoint Security 10 for Windows
and
Kaspersky Security Center Network Agent
A central policy is pushed out to each client computer and enforced. It has control over settings, like trusted applications (a whitelist). When IT pushed out a whitelist entry for my specific application, it fixed the problem.
Note that there are several checkboxes to select for each trusted application entry. This fix only needed one of them.
Under Settings | Anti-Virus protected | Exclusions and trusted applications | Settings, there is a list that can be added to.
Do not scan opened files
X Do not monitor application activity
Do not inherit restrictions of the parent process (application)
Do not monitor child application activity
Allow interaction with application interface
Do not scan network traffic
Honourable mention must go to my co-worker, Arti Chauhan, who suggested more than once that KAS might be the problem. I thought I had fully tested when I guess I hadn't.
Windows 8.1 Pro, Visual Studio 2012 Update 4, MVC4 Umbraco site using SQL Azure (have also tried with a local SQL 2008 R2 db). Running through IIS.
Site runs perfectly while not debugging. However, when debugging the site is extremely slow. The default page takes nearly a minute and a half to execute. Subsequent requests take the same amount of time.
I thought this may be environmental (Surface Pro 3, i5), so went over to a MacBook Pro (i7)...issue still occurs on that PC as well.
At my wits end trying to figure out what could be causing it.
Thank you so much!
There are several thing that could be happening here. Using an Azure SQL db would cause slower initial loading of pages (compared to a local db) because of the data transfer time. However, subsequent page loads should be quick because everything would be loaded into the site cache.
If subsequent page loads are still extremely slow then this could be because the XML cache isn't being generated. Check that the settings are correct in the web.config in debug configuration.
Also, check where you are writing your debug logging to. Umbraco will write log messages to a log file in App_Data/Logs/ and also separate logs to the database. Using a remote database would make these writes slower.
Without knowing what else is happening in your project it's difficult to know what other factors may be playing a part. But you need to step through the application in debug mode in VS and you can check the event viewer for swallowed errors like timeouts. Finally, you can use a profiler to pin point exactly where your issue is.
This is not directly a question about code, but FileSystemWatcher/OS behavior. I have an app, which monitors thousends of logfiles. The app
runs since years without any problems. It was running on a Server 2003 against shares hosted on Server 2003.
If it runs on Server 2008 (R2) and the store is on Server 2008 (R2) not much events are generated. I made a simple repro which show the difference [but as I told: The long running old proggi does work properly]. The apps, generating the logs are not under my code control.
In my repro - writing such log with pauses - even a flush for the writer and/or the underlaying stream does not help].
On Server 2003 each update [write operation from the logging app] causes the FSW to fire Size changed events. On Server 2008, this happens only, when the app starts to write the logfile and when the logfile closes. No events in the middle any more. Settings the REG keys to write NTFS timestamps brought no changes to this behavior.
I am not in a position to open a call at MS, but probably, someone has seen this behavior and knows a workaround.
The workaround coming to my mind are: Downgrade to Server 2003 or to Linux. Both works as expected.
Any ideas are really very welcome.
Best regards,
++mabra
[Net 2.0 => 4.0; No question: All patches, OS also]
[edit]
Sorry, there were faults in my analyzis .... Together with the move of my
app to Server 2008, a new app came to the set of files to monitor [Change
never two things at the same time....]. The new app has another behavior,
then the apps which's logs I've read before ....
(1)The old apps use: Open/append, write, close.
(2)The new app uses: Open/create, write, sleep, write, sleep, write, close.
The FSW gives me the changed event for the old apps behavior, but not
for the new one. The FSW Notifyfilters.Size does not work like I have
expected. So, the new app's log cannot be monitored with FSW.
I found no workaround to make the chnaged event fire for size changes
alone.
But this keeps: The is Windows Server 2008 ! Windows Server 2003 and
Linux with mono even gives you the changed event for (2) !!!!! So,
my "title" was not that bad ;-)
Unhappy with .Net now ....
If someone has probably an idea, please let me now !!
And sorry for my sloppy first-time analyzis ... ;-)
br,
++mabra
Just for the case, that someone is watching this ....
I opened an Issue at MS.Connect - some weeks ago - and they
directed it to the VS team.
The bad news are from today, where they first set the issue
to "Won't Fix" and then to close.
I see this as in indirect confirmation of a bug, which
will not be fixed.
I am completely disappointed.
Anyway, best regards,
++mabra
=> MS Connect Issue
We are starting with Sharepoint development with a team of three and are currently setting up our development environments. We would like to avoid installing a Server 2008 for each developer, thus a single terminal server has been setup, using Remote Windows to start a VS2008 instance on each developer's machine. Now we would like to separate developers' testing environments (i.e. a different site colletion per developer), but have realized that the assemblies would need to be installed into GAC to show properly on the site. But since there is AFAIK only one GAC, developers wouldn't be able to test their stuff independently.
Is there any way we could create separate testing environments without installing a bunch of 2008 Servers?
So you're all going to remote in an fire up Visual Studio and be compiling stuff and restarting IIS, etc?
You're going to be stamping on each other's toes.
A wiser choice nowadays is to use Hyper-V (or some other virtualisation).
We use Windows Server 2008 on our laptops, and use Hyper-V to run our dev environments. We then have a dev environment (sandbox) each, and these have VS2008, SVN, Nunit, etc.
Our code is tested against each other thanks to CruiseControl on the only shared Hyper-V.
This has been great for us... we distribute the load, we can work on the move, we don't step on each others toes and if we need to do a demo we can switch Hyper-Vs and demo from the demo Hyper-V (branched from the dev one early on so that the environments are known).
Go virtual and don't look back.
PS: I've just seen your comment about one server... just put Hyper-V on that and run 3 instances. That's also what we do ;)
I don't know about installing the server on everything, but this sounds like an ideal task for Virtual Machines rather than physical ones- where I work we using VMWare a whole lot for this kind of work and it does very well.
It's also useful to be able to roll back to a snapshot when it comes to testing installation processes and so on.
No. In addition to the GAC there are all the SharePoint files in the 12 hive, such as features and site templates. It's not worth what you save on server costs.
(Of course if you don't use the GAC, but deploy to the bin folder, and you don't touch anything in the 12 hive, you can give each developer their own web application on the same server. But this approach puts a lot of restrictions on what they can do. It's still not worth it.)
Virtual machines will work, but they can be slow to develop on. For instance, you'll need to restart the application pool for every GAC deploy - which means a pause of maybe 15-60 seconds to reload the application, (depending on the hardware). This will become annoying.
Virtual machines work better for test and production, where you don't restart the application so often.
I recommend a physical server for each developer. This will minimize the code-deploy-test cycle time, and make sure they don't have to worry about stepping on each others toes.
You are on the wrong track with Terminal Services - its just not going to give you any separation.
A lot of people do recommend developing on W003/2008 server directly, and it does simplify some things like remote debugging.
I prefer the more traditional method of using VMWare to run virtual machines. These can be running on a local or remote host. Remote debugging is a little more complex to setup but still possible.
Finally - if possible then deploy to the bin dir rather than the GAC. This will make it much easier to deploy automatically after compilation.
The contributors are right that there are lots of stumbling blocks to multi-developer single server environments.
Number one developers will be trying to attach to the same Web Application process w2ps.exe so creating separate Web Applications on different ports is a must unless you are prepared to share time debugging. How to setup a development environment for sharepoint 2013
The second problem is when you try to collaborate and use shared components/features. Having a desire to work separately is debatable, I believe that the team developers should be collaborating and sharing so combing work is desirable to ensure seamless integration into a single final solution and that no work is duplicated. The multi-developer single server environment works perfectly until you try to collaborate 'One common mistake is to have one “development server” used by all team developers. Unless team members are working on totally unrelated components and never need to do common things such as restart IIS or attach a debugger to an IIS process, this type of environment generally doesn’t work well.' http://technet.microsoft.com/en-us/magazine/dn145990.aspx We made this mistake through lack of experience and knowledge, but once you make it it's possible to work round it.
My first attempt to share features was to copy developer 1's project into developer 2's solution and add a reference to it in developer’s 2's project and add all the features to developer 2's package. Deploying this works fine for developer 2, until as I discovered if developer 1 detaches their solution from the debugger it retracts the solution based on the duplicated solution id from the farm and therefore from each developer's web application. Therefore developer 2 has the rug pulled out from underneath them. Although this is a part solution and seemed to work for a while, it took me a while to work out what was happening and what combinations of dev 1 and 2 deployments make each other’s work and not work.
So I found a better solution. Under the project properties in Visual Studio under SharePoint tab there is a combo box called 'Auto-retract after debugging'. This by default retracts the solution when the developer stops the attached debugger and pulls the features out from underneath the other developers. Unticking this box prevents the retract and leaves each developers individual solutions deployed at farm level and on reattaching to the debugger just replaces the solution with minimal fuss.
In my experience recycling the IIS application pool is so fast other developers don't even notice, but with a larger team than 2 this might become more prevalent, so perhaps someone else could add their experiences. I also guess unless the other develops try to attach at exactly the same time that the recycle is happening it'll be fine, so is a really small chance of having a cross over time, and simply detaching and reattaching will fix this if it is ever experienced.