We have some legacy code that uploads strings to blobs in an Azure Storage Account, using the old Microsoft.WindowsAzure.Storage.Blob library. The new version of the code uses the newer Microsoft.Azure.Storage.Blob library. Both the library provide the CloudBlockBlob.UploadTextAsync method, that lets you to upload a string directly to a blob. The two different versions of our code (the legacy one and the new one), are exactly the same and use the following instruction:
await new CloudBlockBlob(new Uri(string.Format("[SAS]", "[blobName]"))).UploadTextAsync("[content]");
where [SAS], [blobName] and [content] are just placeholders; in production:
[SAS] is replaced by our Azure Storage Account’s SAS.
[blobName] is replaced by the name of the blob to create.
[content] is replaced by the content of the blob.
Running the legacy version (the one using the Microsoft.WindowsAzure.Storage.Blob library), everything works fine, but running the new version (the one using the Microsoft.Azure.Storage.Blob library) raises a Microsoft.Azure.Storage.StorageException, saying 'The specified resource does not exist.'. Nothing has been changed in the Azure Storage Account, the network we use is the same, and so the SAS. What could be the reason?
The issue was caused by the presence of & inside the SAS in the legacy project. The legacy code used cscfg files, since the old Azure Cloud Services technology was used. The new one, instead, uses appsettings.json and the new .NET Worker Services template. In this case, to read the configuration, I made it work removing the &.
Related
I'm quite new to android and I am currently working on a app which should utilize a Room database. Following the documentation a room database can be created through the following lines:
myDatabase = Room.databaseBuilder(appContext, MyDatabase.class, "MyDB")
.build();
Now where did room create the database file?
It can't be found in my project folder.
The documentation doesn't mention anything about it and -generally speaking- barely gives any information about how this thing works.
Where is the database?
Does DatabaseBuilder.build() manage, to open the existing database created from previous app launches?
The list of questions is long.
Any information about the .build() thing aswell as further information about Room (misconceptions etc.) are very appreciated, for the documentation doesn't really make things clear for me.
Thank you!
Now where did room create the database file?
The database (a file) will be placed at the default location on the actual device which is data/data/<the_package_name>/database/MyDB.
In your case, as you have coded :-
myDatabase = Room.databaseBuilder(appContext, MyDatabase.class, "MyDB")
.build();
Then the database files will be: -
data/data/<your_package_name>/databases/MyDB
data/data/<your_package_name>/databases/MyDB-wal
data/data/<your_package_name>/databases/MyDB-shm
It can't be found in my project folder.
The database file is not part of the project, it is a file that is created and maintained on the actual device on which the App has been installed.
However, you can use Database Inspector (now App Inspection) on Android Studio to view the database e.g. :-
You can also view the files, if whatever device you test on allows access, by using Device File Explorer. e.g.
Does DatabaseBuilder.build() manage, to open the existing database created from previous app launches?
Yes, if the file exists then it is opened otherwise the file is created. If you uninstall the App this effectively delete's the file. The whole idea of a database is that it persists.
The build() undertakes various tasks, primarily seeing if the underlying file exists and then opening the file. In doing so it
extracts the version number that is stored in the file and compares the number against the number coded within the App (via the #Database).
If the version number from the App is greater then an attempt is tried to find a Migration (recently AutoMigration's have been added to Room).
compares the expected schema (according to the entities defined as part of the #Database), against what is found in the file.
A mismatch will result in the app crashing, so fixes would have to be made.
Note references to file is a simplification, by default Room uses a loggin mode called WAL (Write-Ahead Logging). In WAL mode there will be an additional 2 files that the SQLite routines maintain (you don't need to do anything):-
the database file name suffixed with -wal is the primary wal file into which changes are written (they are applied to the main database automatically).
the database file name suffixed with -shm (this is a WAL file for the WAL file).
I have a network version where I fixed a small bug in the .js file and added a function. I would like to redeploy the network (on the same version).
I stop/teardown Fabric and restart it. Delete the card and .bna file, then re-create the card and .bna file. After that I install and start the network. Last step is to start the REST server.
Even after all these steps, the REST server does not list my new function, indicating it has not been updated?
Do I have to change the version number if I modify the script.js and model.cto files?
As david_k points out in 'comments' above - you should use composer network upgrade to upgrade the business network (no need to 'teardown' your Fabric environment) as well as stop the REST server as you've done. See https://hyperledger.github.io/composer/latest/reference/composer.network.upgrade.html and example of it in use in the tutorials https://hyperledger.github.io/composer/latest/tutorials/queries . Once you've upgraded your business network successfully, and pinged it successfully, you can stop/remove the old dev-* business network containers as indicated. You would then start the REST server again, use the same business network card (eg. an admin card) when prompted / as a parameter to the start command. Then in a new browser session, you can test your REST APIs (or as suits). If you're not seeing the new function (or it errors), you should check your decorators/naming in your logic.js file to see the right transaction function is being called for a named transaction.
I have stored some data in Session. When i try to access this data on different view files (*.cshtml), it works fine on localhost. But when I deploy it on "windowsazure.com", it results:
Object reference not set to an instance of an object.
Line 14: string imageurl = Session["imageurl"].ToString();
Fahad
This anwser is based on the assupmtion that you have moore than one instance of your web role running.
windows Azure uses load balencing based on a round robbin princeple. It also doenot support sticky sessions. The result is that the first en second requrest to your web site are, in general, processed on 2 differnt servers. This explains the empty state.
You can configure your deployment to use shared memory and use the Azure cashing pattern to solve this problem.
This patren is expliand in de windows Azure Training Kit.
Michiel
I have a problem connecting to oracle from within a java servlet running in Jetty (as part of Eclipse). The identical code runs fine from a standalone java app.
My entire development environment is on a single mac. I am using Eclipse and have included the ojdbc6.jar in the main 'Referenced Libraries' and have also dragged and dropped this file in the war/web-inf/lib folder.
As soon as the line
OracleConnectionPoolDataSource ocpds = new
OracleConnectionPoolDataSource();
is called (within the servlet) I get the exception:
java.security.AccessControlException: access denied
(javax.management.MBeanServerPermission createMBeanServer)
Am I missing some security policy or so? If so, exactly what do I do need to do to rectify this? And where does this BeanServer come in?
Thanks in advance.
Every web container has its own way of defining data sources, and making them available through JNDI. You should do that instead.
The native oracle connection pool seems to be creating an MBeanServer, and this is not probably not allowed by the security manager used by Jetty. See http://wiki.eclipse.org/Jetty/Feature/Secure_Mode and http://wiki.eclipse.org/Jetty/Tutorial/Jetty-Policy.
Worked it out - not entirely clear why but created a new GWT app in Eclipse but this time NOT included the Google App Engine (which is ticked by default). This seems to add some restrictions to the code when it is running in Jetty....
I now have copied the sample code over and all is working well!
Has anyone ever used Solrnet inside CLR Stored Procedures? I would really appreciate pointers to some good tutorials.
One problem I'm facing is that I can't find a way to include the SolrNet library as a reference to the VS (2008) Database (SQL Server) Project.
Update:
So it seems that when you have an SQL Server Project, and you want to add a reference to a library, it has to first exist in SQL Server itself, which makes sense. This is done by creating an assembly in SQL Server from the DLL itself with the following SQL:
CREATE ASSEMBLY SolrNet FROM 'C:\CLR_SP\SolrNet.dll'
WITH PERMISSION_SET = UNSAFE
(Note that UNSAFE might have some repercussions on the security of the database however it is ok for me for now)
However the SolrNet.dll requires other library dependencies such as Castle.Windsor.dll (which in itself requires System.Core.dll) and Ninject.dll. I found the required version of Castle.Windsor.dll (which is 2.5.1.0) and also System.Core.Dll (which was in the .Net folder of Windows), however I cannot find the required version of Ninject.dll (which should be 2.1.0.76). I have attempted to create assembly version 2.2 but, as expected, it did not do the job.
I searched for it on different repositories but could not find it. Does anyone know where I could find this version of DLL?
Update 2:
So after lots of searching over the net, I still didn't manage to find Ninject.dll v2.1.0.76. My next attempt was to use the next version of SolrNet (which is v0.4.0.2002). This version required Ninject.dll v2.2 which I had already found. So my current status is registering all other libraries in SQL Server which are dependencies of SolrNet.dll. I will leave this open to document my process just in case there will be someone having the same problem.
Update 3:
I have managed to register all required libraries (some of which I got from SolrNet source on GitHub). So now, SolrNet is registered as an assembly in SQL Server, and therefore I can reference it from the .NET SQL Server Project (for creating the CLR Stored Procedure). So I have written a very simple CLR SP which connects to SOLR and retrieves a piece of data. Code below:
[Microsoft.SqlServer.Server.SqlProcedure]
public static void PrintToday()
{
SqlPipe p;
p = SqlContext.Pipe;
p.Send("Helloooo");
// Open Solr instance
SolrNet.Startup.Init<ActiveProduct>("http://192.168.2.190:8983/solr");
// Get instance of ActiveProduct
ISolrOperations<ActiveProduct> operations = ActiveProduct.GetActiveProductSolrOperations();
// Prepare QueryOptions. This will be passed as a parameter into the query() method.
SolrNet.Commands.Parameters.QueryOptions qo = new QueryOptions();
qo.Start = 0;
qo.Rows = 20;
// Query Solr
SolrQueryResults<ActiveProduct> results = operations.Query(new SolrQueryByField("SearchDescription", "pants"), qo);
// Read results
String s = "Docs found: " + results.NumFound;
p.Send(s);
}
My next problem is that when I deploy and run the CLR SP, an error is popping stating that Solr is already registered in container. The exact output that I see in SQL Server Management Studio is the following:
Helloooo
Msg 6522, Level 16, State 1, Procedure PrintToday, Line 0
A .NET Framework error occurred during execution of user defined routine or aggregate 'PrintToday':
System.ApplicationException: Key 'SolrNet.Impl.SolrConnection.CLRStoredProcedures2.ActiveProduct.SolrNet.Impl.SolrConnection' already registered in container
System.ApplicationException:
at SolrNet.Utils.Container.Register(String key, Type serviceType, Converter`2 factory)
at SolrNet.Utils.Container.Register[T](String key, Converter`2 factory)
at SolrNet.Startup.Init[T](ISolrConnection connection)
at SolrNet.Startup.Init[T](String serverURL)
at StoredProcedures.PrintToday()
PrintToday is the name of the CLR StoredProcedure
CLRStoredProcedures2 is the name of the .NET SQL Server project and default namespace in VS 2008
ActiveProduct is the name of the document in Solr, and the cs class with Solr annotations
As can be seen from the output, the first Pipe.send("Hellooo") is doing its job therefore the SP works fine until there.
When I searched for the above error, I found out that it will show when one tries to register Solr instance twice in the same application. Now I don't see where I am registering the instance twice. Am I missing something here?
Note that the above cs function worked fine when executed in a cs console application developed on my machine. Another detail which might be important is that the SOLR Server is being hosted on my machine which is on the same network of my SQL Server 2005.
Update 4:
For starters, the error I mentioned above (in update 3) does not fire when the SP is executed the 1st time just after deployment (let's assume that the 1st time works for now since I have another error which I'm currently working on fixing), the error fires when the SP is executed again afterwards. So it seems that whatever SolrNet.Startup.Init<ActiveProduct>("http://192.168.2.190:8983/solr"); is doing (creating some sort of session that has to do with a container I think) when called from the SP it is not releasing the "session" therefore the 2nd time (and each time afterwards) the SP is executed, the error is fired. Is there a way to sort of stop the session or releasing from the container. What I can do as a workaround is to try - catch the SolrNet.Startup.Init part, however this is not clean.
Thanks.
I'll try to summarize the steps / requirements with explanations whenever possible:
For some reason SQL Server seems to trigger the "hidden" dependencies of the merged SolrNet. Usually you can just use the merged SolrNet (which includes all integration modules) and if you ignore the integration classes the dependencies won't trigger. But in this case the unmerged SolrNet is necessary.
SolrNet does HTTP requests to the Solr server, so the DLL must be registered with UNSAFE permissions in SQL-CLR.
SolrNet Initialization (Startup.Init) must happen only once per application, but you don't have a 'root' context in SQL-CLR to place this initialization. A workaround is to use a singleton or a Lazy type. SQL-CLR doesn't run .NET 4 yet, but you can backport the Lazy type or use FSharp.Core.dll's implementation (I blogged about this some time ago)