I got "no matching type found for object" error when query cache keys from apache ignite cache.
Ignite server instance runs on Linux Server and my query runs on ignite client instance that started by Microsoft Server .Net Web Forms application. The dll for this type already exists in application's bin folder.
My Query:
List<string> cacheKeys = cache.Select(e => e.Key).Where(e => e.StartsWith(cacheItemKeyPrefix)).ToList();
Error :
Apache.Ignite.Core.Binary.BinaryObjectException: No matching type found for object [typeId=-274908056, typeName=System.Collections.Generic.Dictionary2[[System.Decimal],[CUST.CompositionTypes.PrivateBankingCustomer]]]. This usually indicates that assembly with specified type is not loaded on a node. When using Apache.Ignite.exe, make sure to load assemblies with -assembly parameter. Alternatively, set IgniteConfiguration.PeerAssemblyLoadingEnabled to true. at Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadFullObject[T](Int32 pos, Type typeOverride) at Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type typeOverride) at Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) at Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadBinaryObject[T](Boolean doDetach) at Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type typeOverride) at Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) at Apache.Ignite.Core.Impl.Cache.CacheEnumerator2.b__0(IBinaryStream stream) at Apache.Ignite.Core.Impl.PlatformJniTarget.OutStream[T](Int32 type, Func2 readAction) at Apache.Ignite.Core.Impl.Cache.CacheEnumeratorProxy2.MoveNext() at System.Linq.Enumerable.WhereSelectEnumerableIterator2.MoveNext() at System.Linq.Enumerable.WhereEnumerableIterator1.MoveNext() at System.Collections.Generic.List1..ctor(IEnumerable1 collection) at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
You can only run .Net closures remotely if the whole cluster is .Net cluster, including server nodes. If they already are, I suggest some mismatch between windows and linux assemblies.
Do you have PrivateBankingCustomer type in your linux nodes' assemblies? Note that cache key/value types cannot be peer assembly loaded.
Related
I have been attempting to use the SqlProvider type provider on several different databases where I work. In Visual Studio, intellisense for these different DBs (of types MS Access, SQL Server, and an ODBC connection) all work as shown below:
I've even tried it on the Northwind example database:
It does not matter the connection I actually choose, they seem to all result in 2 exceptions when the code is actually run:
System.TypeInitializationException
HResult=0x80131534
Message=The type initializer for 'Main' threw an exception.
Source=SqlProviderTest2
StackTrace:
at Main.main(String[] _arg1) in C:\Users\***\source\repos\SqlProviderTest2\Program.fs:line 29
Inner Exception 1:
TypeInitializationException: The type initializer for '<StartupCode$SqlProviderTest2>.$Main' threw an exception.
Inner Exception 2:
FileLoadException: Could not load file or assembly 'System.Data.OleDb, Version=4.0.1.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)
How is it possible that the intellisense can detect the DB but not work when the program is actually run? Is there a common fix for this?
(Using Visual Studio 2019 Professional, if that makes a difference.)
If I start a GFSH client and connect to Geode. There is a lot of data in myRegion and to check through it then I run:
query --query="select * from /myRegion"
I am getting the response:
Result : false
startCount : 0
endCount : 20
Message : Unknown pdx type=2140705
How does one troubleshoot / debug this problem?
UPDATE: The error in the Geode server log is:
[info 2018/07/04 10:53:07.275 BST IsGeode <Function Execution Processor1> tid=0x48] Exception occurred:
java.lang.IllegalStateException: Unknown pdx type=1318971
at org.apache.geode.internal.InternalDataSerializer.readPdxSerializable(InternalDataSerializer.java:3042)
at org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2859)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
at org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:90)
at org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1911)
at org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1904)
at org.apache.geode.internal.cache.PreferBytesCachedDeserializable.getDeserializedValue(PreferBytesCachedDeserializable.java:73)
at org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1269)
at org.apache.geode.internal.cache.LocalRegion$NonTXEntry.getValue(LocalRegion.java:8771)
at org.apache.geode.internal.cache.EntriesSet$EntriesIterator.moveNext(EntriesSet.java:179)
at org.apache.geode.internal.cache.EntriesSet$EntriesIterator.next(EntriesSet.java:134)
at org.apache.geode.cache.query.internal.CompiledSelect.doNestedIterations(CompiledSelect.java:837)
at org.apache.geode.cache.query.internal.CompiledSelect.doIterationEvaluate(CompiledSelect.java:699)
at org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:423)
at org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:53)
at org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:558)
at org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:385)
at org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:319)
at org.apache.geode.management.internal.cli.functions.DataCommandFunction.select(DataCommandFunction.java:247)
at org.apache.geode.management.internal.cli.functions.DataCommandFunction.select(DataCommandFunction.java:202)
at org.apache.geode.management.internal.cli.functions.DataCommandFunction.execute(DataCommandFunction.java:147)
at org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:185)
at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:374)
at org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:440)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:662)
at org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1108)
at java.lang.Thread.run(Thread.java:748)
You can tell the immediate cause from the stack trace.
A PDX serialized stream contains a type id which is a reference into a repository of type metadata maintained by a GemFire cluster. In this case, the serialized data of the object contained a typeId that is not in the cluster's metadata repository.
So the question becomes, "what serialized that object and why did it use an invalid type id ?"
The only way I've seen this happen before is when a cluster is fully restarted and the pdx metadata goes away, either because it was not persistent or because it was deleted (by clearing out the locator working directory for example).
GemFire clients cache the mapping between a type and it's type ID. This allows them to quickly serialize objects without continually looking up the type id from the server. Client connections can persist across cluster restarts. When a client reconnects it does not flush the cached information and continues to write objects using its cached type ID.
So the combination of a pdx-metadata losing cluster restart and a client that is not restarted (e.g. an app. server) is the only way I have seen this happen before. Does this match your scenario ?
If so, one of the best ways to avoid this is to persist your pdx metadata and never delete it.
NServiceBus.dll - Version 5.2.9 & NServiceBus.Host - Version 6.0.0
I am developing a workflow application with pluggable addins.
In my solution I have a NServiceBus host assembly which I host using the NServiceBus.Host.exe. To prevent scanning I have defined the EndpointConfigurationType in the NServiceBus.Host.exe.config.
<appSettings>
<add key="EndpointConfigurationType" value="Libra.Workflow.Host.EndpointConfig, Libra.Workflow.Host" />
</appSettings>
I have verified that this config is being used because if I put some unknown type I get an error and also because me EndpointConfig class is instantiated before any scanning happens.
In the Customize method of this class I have added
public void Customize(BusConfiguration cfg)
{
cfg.AssembliesToScan(AllAssemblies.Matching("Libra.Workflow.Messages.dll"));
...
}
Now when I run this project I get an error because NServiceBus is scanning all assemblies and do to the nature of System.AddIn some assemblies cannot be scanned!
This scanning happens right after Libra.Workflow.Host has been instantiated but before the Customize method is called. Here is the call stack for this scan:
at NServiceBus.Hosting.Helpers.AssemblyScanner.ScanAssembly(String assemblyPath, AssemblyScannerResults results) in C:\BuildAgent\work\3206e2123f54fce4\src\NServiceBus.Core\Hosting\Helpers\AssemblyScanner.cs:line 153
at NServiceBus.Hosting.Helpers.AssemblyScanner.GetScannableAssemblies() in C:\BuildAgent\work\3206e2123f54fce4\src\NServiceBus.Core\Hosting\Helpers\AssemblyScanner.cs:line 63
at NServiceBus.GenericHost..ctor(IConfigureThisEndpoint specifier, String[] args, List`1 defaultProfiles, String endpointName, IEnumerable`1 scannableAssembliesFullName) in c:\BuildAgent\work\a3de8759ee491634\src\NServiceBus.Hosting.Windows\GenericHost.cs:line 33
at NServiceBus.Hosting.Windows.WindowsHost..ctor(Type endpointType, String[] args, String endpointName, IEnumerable`1 scannableAssembliesFullName) in c:\BuildAgent\work\a3de8759ee491634\src\NServiceBus.Hosting.Windows\WindowsHost.cs:line 21
at NServiceBus.Hosting.Windows.HostServiceLocator.DoGetInstance(Type serviceType, String key) in c:\BuildAgent\work\a3de8759ee491634\src\NServiceBus.Hosting.Windows\HostServiceLocator.cs:line 31
at Microsoft.Practices.ServiceLocation.ServiceLocatorImplBase.GetInstance(Type serviceType, String key) in c:\Home\Chris\Projects\CommonServiceLocator\main\Microsoft.Practices.ServiceLocation\ServiceLocatorImplBase.cs:line 49
The error message I get is:
Could not enumerate all types for
'C:\msc\Trunk\Libra.Workflow\Build\Libra.Workflow.Host\AddIns\Libra.Workflow\Libra.Workflow.Processors.dll'
Why is NServiceBus scanning this DLL and how can I prevent it?
Note: Since this is an AddIn DLL, there isn't even a reference to it in the Libra.Workflow.Host nor any other related assemblies so there should be absolutely no reason for NServiceBus to have to touch it.
One way of limiting assembly scanning done by NServiceBus.Host is to use the /scannedAssemblies switch. One caveat is to pass NServiceBus.Core and NServiceBus.Host assemblies explicitly:
NServiceBus.Host.exe /scannedAssemblies:"NServiceBus.Core, Version=5.0.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c" /scannedAssemblies:"NServiceBus.Host, Version=6.0.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c"
This command will scan those NServiceBus assemblies and the assembly specified via EndpointConfigurationType app setting. If you want to specify additional assemblies (like your Libra.Workflow.Messages) you may add additional /scannedAssemblies switch.
Please see this documentation page for details: http://docs.particular.net/nservicebus/hosting/nservicebus-host/#configuring-the-endpoint-controlling-assembly-scanning-using-the-command-line.
I have the following vb.net code:
Imports IBM.WMQ
[...]
MQEnvironment.Hostname = hostName
MQEnvironment.Port = portNumber
MQEnvironment.Channel = channelName
queueManager = New MQQueueManager(queueManagerName) ' error here
which is throwing the following error:
System.IO.FileNotFoundException occurred
FileName=C:\Users\User\Documents\Visual Studio 2012\Projects\[...]\bin\Debug\mqclient.ini
HResult=-2147024894
Message=Could not find file 'C:\Users\User\Documents\Visual Studio 2012\Projects\[...]\bin\Debug\mqclient.ini'.
Source=mscorlib
StackTrace:
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
I am not using any ini files in the construction of my queue manager, so does anyone have any idea what's going on - why is it even looking for one, and why in the same directory as the program? I have installed the MQ client, and afaik I have all the environmental variables, etc. set up properly.
Thanks for any help you can give
Is that an unhandled or a first chance exception? Internally, the MQ .net layer will try to read a MQClient.ini but should function quite happily without it. It reads the file for compatibility with the C client, and can handle some of the MQClient.ini stanzas. I would not have expected an absence of such a file to cause problems, but it will try to open it internally. Was that the full callstack, as I'd have expected some MQ libraries on the stack otherwise.
I have a static class which loads a .NET assembly dynamically (using Assembly.LoadFile method)
I get the following error message:
Msg 6522, Level 16, State 2, Line 3
A .NET Framework error occurred during execution of user-defined routine or aggregate "MySQLCLRUDFFunction":
System.TypeInitializationException: The type initializer for 'MyClassName' threw an exception. ---> System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed
.
When I try assign CAS security using this declaration
[System.Security.Permissions.PermissionSet(System.Security.Permissions.SecurityAction.Demand, Name = "FullTrust")]
I instead get this exception
Msg 6522, Level 16, State 2, Line 2
A .NET Framework error occurred during execution of user-defined routine or aggregate "MySQLCLRUDFFunction":
System.TypeInitializationException: The type initializer for 'MyClassName' threw an exception. ---> System.Security.SecurityException: Request failed.
Note: I have given my SQL Server service account "Full Access" to my dynamic assemly file on disk. I copied my dyamic assembly using syntax:
create Assembly TestAssembly
From 'C:\MyTestAssembly.dll';
--Alter Assembly to copy dynamic assembly file
Alter Assembly TestAssembly add file from 'C:\mydynamicassembly.dll';
After turning TRUSTWORTHY ON and setting PERMISSION_SET = UNSAFE I now get this exception
Msg 6522, Level 16, State 2, Line 2
A .NET Framework error occurred during execution of user-defined routine or aggregate "MySQLCLRUDFFunction":
System.TypeInitializationException: The type initializer for 'MyClassName' threw an exception. ---> System.IO.FileLoadException: LoadFrom(), LoadFile(), Load(byte[]) and LoadModule() have been disabled by the host.
As the error message states, dynamic assembly loading is completely disallowed by SQL Server - even under unsafe. The only way for Assembly.Load calls to succeed is if the assembly is already loaded in the database via CREATE ASSEMBLY or in the GAC and on the list of supported ("blessed") assemblies. There is another post on this on the sqlclr blog.
I know this is a very old question now, but I have recently found a way to achieve what you want. When you try and using Assembly.Load(...) in a SQL CLR hosted assembly, it will explicitly fail, this is by design, even with PERMISSION_SET = UNSAFE. This is to ensure the stability of the database server.
The technique to loading your dynamic assemblies, is to register them first and then resolve the type using Type.GetType(...) passing in the fully qualified type name (including assembly version information.
Here are the steps:
1.Compile the type, and finalise on disk (i.e. do not create in-memory assemblies). The CompilerResults type will have a CompiledAssembly property and PathToCompiledAssembly property. Use the latter as accessing the CompiledAssembly property will attempt to use Assembly.Load.
2.Using the path, I call a stored procedure from my code (using new SqlConnection("Context Connection = true")) which I pass in the name of the assembly (which I have predetermined) and the compiled assembly path:
CREATE PROCEDURE re.CreateAssembly
#name VARCHAR(100),
#path VARCHAR(1000)
AS
BEGIN
DECLARE #sql NVARCHAR(2000)
SET #sql = N'CREATE ASSEMBLY [' + #name + '] AUTHORIZATION [DatabaseUser] FROM ''' + #path + ''' WITH PERMISSION_SET + SAFE';
EXEC sp_executesql #sql;
END
GO
3.Using your predetermined name, you can use Type.GetType(...), e.g.:
string typeName = "MyCompiledAssembly.MyClass, MyCompiledAssembly, Version=0.0.0.0, Culture=Neutral, PublicKeyToken=null, ProcessorArchitecture=MSIL";
Type type = Type.GetType(typeName);
When the SQLCLR attempts to resolve the type, it should find it, because in step 2 you've already registered the assembly with Sql Server.
I'm guessing you've got the PERMISSION_SET set to SAFE when you did CREATE ASSEMBLY (this will be the default if you didn't specify it). You'll need to change it to EXTERNAL_ACCESS or UNSAFE if you want to do this.
http://msdn.microsoft.com/en-us/library/ms189524.aspx
I was one the developers # Microsoft who worked on SQL-CLR integration, so I may be able to help.
To achieve what you want you need to do two things:
Mark data base as TRUSTWORTHY
Mark assembly as UNSAFE (database must be trustworthy)
The account under which SQL Server runs must have permissions to access the file on the the file system. Often times the file is on a network share but SQL Server is run under local account that has no permission to access network, so this is often a problem. SQL Express in itse default installation does not have rights to C:.
Note that doing all those things has several negative side-effects:
serious security implications - you are effectively ceding control over the instance to the code in unsafe assembly as it can now use raw pointers to access/change anything in the engine.
Stability - you're also ceding stability guarantees for the same reasons.
Portability and disaster recovery - if you database has to move elsewhere for load-balancing or is restored from backup after machine failure you will not have the mydynamicassembly.dll on the new machine.
If at all possible, consider redesigning your app so that all needed assemblies are pre-loaded into the database itself.
[EDIT: if none of the above helps it best to ask on MSDN forums].