Tamino 4.1.4.1.
Tried a method to Insert/Retrieve NON XML in/from ino:etc (see below). File is a 90KB “jpg”.
Operation typically works when executed once, but when trying the method for several times (e.g. in a loop) it fails with different types of exceptions:
System.IO.IOException or
System.Net.WebException (see attachment).
There are some more questions concerning NON XML:
Is there a preferred method for reading from TaminoDocument.NonXmlDocument? When working with Tamino 4.1.1.1 I got an exception when trying to read using Stream.ReadByte(); Stream.Read() worked. Did not try this with 4.1.4.
After a retrieve operation, how long can I read from the TaminoDocument.NonXmlDocument? When working with transactions I got an exception when trying to read after the transaction commit operation.
Is it necessary to close the TaminoDocument.NonXmlDocument stream after finished with reading?
public static void TaminoNonXMLBase(String fn, String toFn)
{
TaminoConnection connection = new TaminoConnection(TaminoDb);
connection.Open(TaminoConnectionMode.AutoCommit);
TaminoCommand command = connection.CreateCommand(“ino:etc”);
FileStream stream = new FileStream(fn, FileMode.Open);
TaminoDocument doc = new TaminoDocument(stream, “image/jpg”);
doc.DocName = Path.GetFileName(fn);
doc.DocType = “ino:nonXML”;
TaminoResponse response = command.Insert(doc);
stream.Close();
if (response.ReturnValue == “0”)
{
String id = “ino:nonXML” + “/” + Path.GetFileName(fn);
doc = command.Retrieve(new TaminoUri(id));
Stream istream = doc.NonXmlDocument;
FileStream oStream = new FileStream(toFn, FileMode.OpenOrCreate);
byte bytes = new byte[1000];
int numBytesRead = 0, cur;
while ((cur = istream.Read(bytes, 0, 1000)) > 0)
{
oStream.Write(bytes, 0, cur);
numBytesRead += cur;
}
oStream.Close();
istream.Close();
}
connection.Close();
}
ex.txt (1.39 KB)
I just tried this code in a loop a 100 times with no problem against Tamino 4.1.4.1 on my localhost. I use Apache as my web server. Are you using IIS?
The reason I ask is that we recently had a problem where IIS was issuing Connection: keep-alive headers that caused IIS to run out of resources. In this case we received HTTP 403 errors (not the same as yours though).
It would be good to see an HTTP sniffer log of the “protocol violation” HTTP responses.
I think it is generally good practice to close streams when you are finished with them. As to whether it is necessary only Microsoft can answer that!
Web Server is Apache 2.0.43 on localhost.
Seems to be some kind of timing problem ?!
When I execute the loop in the debugger with a breakpoint before calling the TaminoNonXMLBase method, the exception does not come up.
Do not know much about web-servers and HTTP. How can I produce an HTTP sniffer log of the “protocol violation” HTTP responses?
To be honest I’m not sure that a sniffer will show anything useful - especially as it seems to be timing related.
What .NET Framework are you running?
Did you say you have this problem running against Tamino 4.1.1? Have you tried it against Tamino 4.1.4?
What is the version of the .NET API you are using? [Though I doubt there are any changes that may affect this aspect of behavior].
[This message was edited by markk on 10 Jul 2003 at 10:50.]
[This message was edited by markk on 10 Jul 2003 at 10:55.]
.NET Framework 1.0 (1.0.3705)
Problem relates to Tamino 4.1.4.1;
my computer now holds Tamino 4.1.1.1 and 4.1.4.1; for using 4.1.4.1 I produced a new database and told to use 4.1.4 and from my .NET application I referenced to .NET API (TaminoApi.dll) delivered wit 4.1.4. OK?
Readme of Tamino .NET API says that this is version 4.1.4.2.
OK.
I tried a configuration similar to this. I used the same .NET API version 4.1.4.2 + .NET Framework 1.0 (1.0.3705). Unfortunately, this was against a remote DB and not as fast as a local one. However 1000 iterations went through without a problem. I will try and see what happens in a local configuration.
To check the .NET API version in future I would do a right click->Properties->Version in Explorer - I would trust that more than the documentation! 
Had some more tests concerning this issue and detected a kind of size relationship:
1000 iterations for a 19KB MS-Word file or for a 5 KB HTML file went through without problems.
For my 92KB JPEG-File or for a 121KB XML-File or for a 169KB PDF-File the exception comes up after 2 to 20 iterations.
I’m afraid that we are currently unable to reproduce this problem. Could you please report it to customer support?