I have been working with SF for a while now. Recently, I began having a problem when I do a Start to debug. The service shows in error and I get the infamous Partition is below target replica or instance count.. The strange thing is that I can deploy to local or remote SF provision and attach debug with no problem
I thought that something was wrong with my code, but it turns out that when I create a brand new test project, without any custom code, the same thing happens.
Note, this does not happen if I create a .net core service, only the ole .net service..
This is very strange, and I speculate that it possibly caused by the environment or VS.
I am running the latest updates on VS2017, latest SF on Windwoes 10 with latest updates..
PS: I also get the a 64-bit debugging operation is taking longer than expected when I exit the debugger
Related
I have created a shiny app on my computer that runs with no error. Now, I deployed the same app to the shiny server we have in our organization, and i cannot initiate the app. I receive the following error message:
transpose listening on http://127.0.0.1:43202
Warning: Error in tabPanel: argument "tabName" is missing, with no default
65: tabPanel
Execution halted
here are my questions:
(1) I do use shinydashboard and shinydashboardplus libraries in my app and both are installed on the shiny server as well so this shouldnt be a problem since tabsetPanel and tabPanel are in these libraries, correct?
(2) tabPanel and tabSetPanel do NOT have a tabName argument. so what is this error specially because the app does work on my computer with no issue.
I know probably I need to provide the code but I cannot at the moment unless i significantly take stuff out of it (government property) but I was hoping someone can help considering the fact that it works on my computer but it doesnt when i deploy it.
Just a quick note that the R version installed on my laptop is 3.5.2 but the one on the server is 3.6! can this be an issue?
Thanks!
I think a library bs4Dash was masking tabSetPanel which is quite confusing because i didnt have that problem running the app on my laptop...
After upgrade to sdk 2.5.216 and runtime 5.5.216 Test-ServiceFabricApplicationPackage command works only for complete package. In case of partial app upgrade (some Pkg are removed) it results in "Windows PowerShell has stopped working". I have tested on several computers and several apps. to reproduce:
create test app with 2 services and deploy.
change app version and particular service version.
create package and remove Pkg folder from it for the service without modifications.
connect to Service Fabric and test like Test-ServiceFabricApplicationPackage -ApplicationPackagePath "..path" -ImageStoreConnectionString "fabric:ImageStore"
Maybe somebody was able to overcome this issue? or at least has similar behavior so I'm not alone in Universe.
Thanks!
Alex
Take a look at https://github.com/Azure/service-fabric-issues/issues/259
This is a bug in our code. It happens when a compressed package was uploaded and provisioned in the cluster. Testing a new version of the application fails because settings file was not found in the provisioned version.
We fixed the issue and it will become available in one of our next releases.
Meanwhile, you can skip compression or test the version 2 application package without passing in the image store connection string.
Apologies for the inconvenience!
I used to be able to do upgrade, and it suddenly wont work, not to cloud and not locally.
And there is no error message, so I have no clue what to do.
Publishing a new application works fine.
There seems to be something corrupt with the solution, but I have no idea where I should be looking for this.
In a brand new project, publishing and upgrading a stateful service from template, works without problem.
Things I have done:
Cleaned solution.
Rebuilt solution.
Deleted Debug folders in bin and obj folders.
Restarted Visual Studio.
Cleared MEF Component Cache.
Restarted machine.
Restarted cluster.
The brand new project is deployed to same cluster and upgrade it is working, so I have not deleted the cluster to deploy a new one.
There is no error being thrown so enclosing the script in a try catch seems pointless.
What else can I do here, what can I do to try find out what is going wrong, any suggestions?
I found out it might be a bug. It is reported here:
https://github.com/Azure/service-fabric-issues/issues/240
Summary: When deployed with compression, further upgrades require config version bump, even though config has not changed.
I noticed this afternoon that my Bluemix IoT Application was in the 'Unknown' state. When I mined into the app to see what the problem could be, I got the following pop-up:
App staging failed in the buildpack compile phase
I haven't made any changes to my NodeRED flows in months, and if I spin up a new IOT Foundation app, it starts just fine.
Any ideas on what is going on here?
A recent update to the underlying application stack has caused an incompatibility with older versions of the IoTF boilerplate.
The fix is to edit your application's package.json file and remove the 'mqlight' entry under the dependencies section. New instances of the boilerplate already have this entry removed - hence why they work.
Perhaps check the bluemix server status at https://developer.ibm.com/bluemix/support/#status
There were some issues reported around scheduled maintenance. There are also buildpack updates scheduled.
We are trying to migrate from our on-premises TFS 2010 to Visual Studio Online (VSO). We did it a first time just to test it out. The OpsHub application stopped a couple of times, but we finally succeeded. We did our testing and deleted the project from VSO.
The second time dident go so well. It gives the following error after migrating a lot but not all of our change sets:
com.opshub.eai.config.exception.ConfigServiceException:
OH-CONFIG-0101: Exception while calling service, underlying cause :
could not execute query.
We can press OK and navigate into another view in the application but the same error occurs on every view. We have restarted the application, the service and even the server. We always get the same error. We decided to uninstall the application and reinstall it. That solved the problem, but it appears again after we have migrated about 60% of our source code (a day or so).
So, after 3 re installations we are about to give up. It doesn't crash on the same change set every time.
Does anyone know a way around this? Is there any way we can see the real cause of the problem and fix it?
We are using version V1.3.000B000 (latest version).
Not sure if this is the proper place to post the question, but OpsHub is referring to stack overflow for support.