I am trying to create an ignite service using aspnetcore background service functionality. When I start the service it works fine, but as soon as a client is attempting to connect I get the following exception:
[09:51:15,746][SEVERE][disco-notifier-worker-#75%ignite-instance-7b562b36-d203-4652-99ec-5fad30b09a3b%][] JVM will be halted immediately due to the failure: [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteException: Invalid array specification: Npgsql.TypeHandlers.TextHandler+<Npgsql-TypeHandling-INpgsqlTypeHandler<System-Char[]>-Read>d__7]]
I am using the below configuration for Ignition.Start():
{"IgniteInstanceName":null,"AutoGenerateIgniteInstanceName":true,"GridName":null,"BinaryConfiguration":null,"CacheConfiguration":null,"SpringConfigUrl":null,"JvmDllPath":null,"IgniteHome":null,"JvmClasspath":null,"JvmOptions":["-Xms1024m","-Xmx1024m"],"Assemblies":null,"SuppressWarnings":false,"LifecycleHandlers":null,"JvmInitialMemoryMb":-1,"JvmMaxMemoryMb":-1,"DiscoverySpi":{"IpFinder":{"LocalAddress":null,"MulticastGroup":"228.1.2.4","MulticastPort":47400,"AddressRequestAttempts":2,"ResponseTimeout":"00:00:00.5000000","TimeToLive":null,"Endpoints":["127.0.0.1:47500..47509"]},"SocketTimeout":"00:00:05","AckTimeout":"00:00:05","MaxAckTimeout":"00:10:00","NetworkTimeout":"00:00:05","JoinTimeout":"00:00:00","ForceServerMode":false,"ClientReconnectDisabled":false,"LocalAddress":null,"ReconnectCount":10,"LocalPort":47500,"LocalPortRange":100,"StatisticsPrintFrequency":"00:00:00","IpFinderCleanFrequency":"00:01:00","ThreadPriority":10,"TopologyHistorySize":1000},"CommunicationSpi":null,"EncryptionSpi":null,"ClientMode":false,"IncludedEventTypes":[12,22,45],"LocalEventListeners":null,"MetricsExpireTime":"10675199.02:48:05.4775807","MetricsHistorySize":10000,"MetricsLogFrequency":"00:01:00","MetricsUpdateFrequency":"00:00:02","NetworkSendRetryCount":3,"NetworkSendRetryDelay":"00:00:01","NetworkTimeout":"00:00:05","WorkDirectory":"D:\ApacheIgniteDataJr\","Localhost":null,"IsDaemon":false,"UserAttributes":null,"AtomicConfiguration":null,"TransactionConfiguration":null,"IsLateAffinityAssignment":true,"Logger":null,"FailureDetectionTimeout":"00:00:10","SystemWorkerBlockedTimeout":null,"ClientFailureDetectionTimeout":"00:00:30","PluginConfigurations":null,"EventStorageSpi":null,"MemoryConfiguration":null,"DataStorageConfiguration":{"StoragePath":null,"CheckpointFrequency":"00:03:00","CheckpointThreads":4,"LockWaitTime":"00:00:10","WalHistorySize":20,"WalSegments":10,"WalSegmentSize":67108864,"WalPath":"db/wal","WalArchivePath":"db/wal/archive","WalMode":1,"WalThreadLocalBufferSize":131072,"WalFlushFrequency":"00:00:02","WalFsyncDelayNanos":1000,"WalRecordIteratorBufferSize":67108864,"AlwaysWriteFullPages":false,"MetricsEnabled":false,"MetricsRateTimeInterval":"00:01:00","MetricsSubIntervalCount":5,"CheckpointWriteOrder":1,"WriteThrottlingEnabled":false,"WalCompactionEnabled":false,"MaxWalArchiveSize":1073741824,"SystemRegionInitialSize":41943040,"SystemRegionMaxSize":104857600,"PageSize":4096,"ConcurrencyLevel":16,"WalAutoArchiveAfterInactivity":"-00:00:00.0010000","CheckpointReadLockTimeout":null,"WalPageCompression":0,"WalPageCompressionLevel":null,"DataRegionConfigurations":[{"Name":"ProductName_Region","PersistenceEnabled":true,"InitialSize":104857600,"MaxSize":429496729,"SwapPath":null,"PageEvictionMode":0,"EvictionThreshold":0.9,"EmptyPagesPoolSize":100,"MetricsEnabled":false,"MetricsRateTimeInterval":"00:01:00","MetricsSubIntervalCount":5,"CheckpointPageBufferSize":0,"LazyMemoryAllocation":true}],"DefaultDataRegionConfiguration":{"Name":"Default_Region","PersistenceEnabled":false,"InitialSize":104857600,"MaxSize":429496729,"SwapPath":null,"PageEvictionMode":0,"EvictionThreshold":0.9,"EmptyPagesPoolSize":100,"MetricsEnabled":false,"MetricsRateTimeInterval":"00:01:00","MetricsSubIntervalCount":5,"CheckpointPageBufferSize":0,"LazyMemoryAllocation":true}},"SslContextFactory":null,"PeerAssemblyLoadingMode":0,"PublicThreadPoolSize":16,"StripedThreadPoolSize":16,"ServiceThreadPoolSize":16,"SystemThreadPoolSize":16,"AsyncCallbackThreadPoolSize":16,"ManagementThreadPoolSize":4,"DataStreamerThreadPoolSize":16,"UtilityCacheThreadPoolSize":16,"QueryThreadPoolSize":16,"SqlConnectorConfiguration":null,"ClientConnectorConfiguration":null,"ClientConnectorConfigurationEnabled":true,"LongQueryWarningTimeout":"00:00:03","PersistentStoreConfiguration":null,"IsActiveOnStart":true,"ConsistentId":null,"RedirectJavaConsoleOutput":true,"AuthenticationEnabled":false,"MvccVacuumFrequency":5000,"MvccVacuumThreadCount":2,"SqlQueryHistorySize":1000,"FailureHandler":null,"SqlSchemas":["PRODUCTNAME_MODELS"],"ExecutorConfiguration":null,"JavaPeerClassLoadingEnabled":false,"AsyncContinuationExecutor":0}
After starting the node, I am activating and setting baseline auto-adjustment flag.
What am I doing wrong here?
It is a bug in Ignite: https://issues.apache.org/jira/browse/IGNITE-15845,
fixed for 2.12 release, which is planned for next week.
You can try the release candidate and see if it works for you https://dist.apache.org/repos/dist/dev/ignite/2.12.0-rc2/apache-ignite-2.12.0-nuget.zip
Or use a workaround - register SQL types (wherever [QuerySqlField] is used) manually in BinaryConfiguration or with ignite.GetBinary().GetBinaryType(typeof(TValue));
Issue:
My java sprig-batch job runs fine in my development environment, but when I deploy it on the integration server, I get a date-formatting issue. This makes me think there is a configuration difference between my dev. env. and the integration server.
Context:
I am not a java or spring expert. This is rather an integration issue.
I call a MY.PROCEDURE piece of PL/SQL code, that in turn calls an Oracle view.
The below instruction in the Oracle view works fine in my dev. env., but on the integration server it is causing the issue:
T1.DATE between '01.07.2015' and '07.07.2020'
Giving an ugly
Caused by: java.sql.SQLDataException: ORA-01843: not a valid month
ORA-06512: at "MY.PROCEDURE", line 36
When I specify the date format with a TO_DATE, it vanishes. I know this is good practice, and should obviously be mandatory for our team to do. Anyway I would like to understand this configuration discrepancy we have between Dev and Int.
Help
Any idea where I should configure the locale when I deploy this thing?
I wish I could setup the local (or date format) locally, without modifying the java deliverable. Is it possible ?
It appears as though your NLS_DATE_FORMAT is different in your environments. Run the following in each environment:
select value
from nls_session_parameters
where parameter = 'NLS_DATE_FORMAT';
This is why you should always specify the format and not rely on implicit conversion. If necessary you may be able to run the following:
alter session set nls_data_format = 'mm.dd.yyyy';
or perhaps that should be 'dd.mm.yyyy'. That cannot be determined from the given information.
The environment difference between development and the integration server is the first is a Swiss(FR) setup OS. And... the server is a Linux with the default English's.
So you start to see where I have to go.
Tell Java you run your thing with 'fr' locale:
I had to complete the java command line with the below:
-Duser.country=fr -Duser.language=fr
Here is where I found inspiration: NLS_LANG setting for JDBC thin driver? (most upvoted answer).
I have a Java 9 app that I'm trying to package for the Windows Store. The strange thing is that it works as expected when I run the exe-launcher directly, but I get the following strange error when I run the launcher via the APPX package:
Exception in thread "Swing-Shell" java.lang.InternalError: Could not
initialize COM: HRESULT=0x80010106
at java.desktop/sun.awt.shell.Win32ShellFolderManager2.initializeCom(Native Method)
at java.desktop/sun.awt.shell.Win32ShellFolderManager2$ComInvoker$1.run(Unknown Source at java.base/java.lang.Thread.run(Unknown Source)
HRESULT=0x80010106 means RPC_E_CHANGED_MODE which I guess means that COM is somehow already initialized in MTA mode. But why is this only an issue in the Windows Bridge sandbox? Does the Windows Bridge somehow pre-initialize COM somehow for some reason?
I'm not sure if this is a Java 9 issue, or a Desktop Bridge issue, or both. Does anybody have any ideas on how to identify the cause of the issue or workaround?
I have made a minimal Sample Project to reproduce the issue
The application works when executed directly, but not when executed via the APPX launcher. Why?
Analysis
The JDK parts, that rely on COM being initialized (D3DPipeline, Sound and windows shellfolder access) all follow the same pattern:
the run the code in a separate thread
for this thread CoInitialize is called
at the end of the user level code CoUnitialize is called
This is in line with the documentation the MSDN holds for COM and the analysis is correct, the error indicates, that the COM subsystem is already initialized to be MTA threaded.
So I modified the java launcher (jvm.dll) and inserted
debugging statements into some of the native methods in os_windows.cpp.
I focused on the threading methods. What I found was this:
create_main_thread, create_os_thread, pd_start_thread all
run with COM not yet initialized
the native thread initializer (thread_native_entry) is already
running with COM initialized
I looked more into in _beginthreadex and indeed I finally found a lead
on stackoverflow. That pointed me to the sourcecode of threadex.c,
which is part of the Visual Studio 2013 Express Installation.
There you find, that _beginthreadex does not directly start the
supplied thread function, but runs a library initializer
(_threadstartex) first. Part of this initializer reads:
_ptd->_initapartment = __crtIsPackagedApp();
if (_ptd->_initapartment)
{
_ptd->_initapartment = _initMTAoncurrentthread();
}
_callthreadstartex();
_crtIsPackagedApp detects via a kernel function if the application is
run as a "PackagedApp" (i.e. AppX package) and if so, then the
RoInitialize function is called, which from my understanding acts like the big
brother of CoInitialize.
Long story short: If your application is build with Visual Studio 2013
and run as a packaged application, you get a broken environment.
It was confirmed, that the working versions of the Oracle JDK were build with VS2010 SP1 and the broken version was build with VS2013SP4.
Workaround
With the above information google finally found a reference, that supports the analysis:
https://blogs.msdn.microsoft.com/vcblog/2016/07/07/using-visual-c-runtime-in-centennial-project/
Quote from that article:
Note that the existing VC++ 12.0 libraries created during the
Windows 8 timeframe have runtime checks to determine whether the
app is running under the app container or not. When running
desktop apps as a packaged app, these checks might limit the
functionality of the desktop app or cause it to behave like a UWA
(Universal Windows Application) (limited file system access or
create thread initializing MTA etc.). We have fixed this behavior
in the VC++ libraries contained in these framework packages and
thus removing the modern app limitations from your desktop
applications.
So I see to options to fix applications, that shall be distributed as AppX packages:
either force the users to have the updates VC++ 12.0 binaries installed (by introducing the dependency cited in the blog post) or
replace the msvcr120.dll that is bundled with Java 9 (and I assume also Java 10) with the fixed version from the update packages
I would go with the second version and I tested this. Starting with a clean up-to-date Windows 10 System, I installed JDK 9.0.4, I cloned the supplied testcase, modified it use the locally installed JRE (not the JDK!) and build the appx package. Running this, I reproduced the problem. I then replaced the msvcr120.dll's in the JRE folder of my systems installation with the one contained in the APPX container from:
https://www.microsoft.com/en-us/download/details.aspx?id=53176
Hint: *.appx are just ZIP files with additional signatures, so you can
just rename them and extract the contents.
I rebuild the testcase and it is working as it should (no COM
initialization errors anymore).
I have installed Desktop App Converter from the Windows store.
When I try to run the app (literally just launch it), I get the message:
[Window Title]
C:\Program Files\WindowsApps\Microsoft.DesktopAppConverter_2.0.2.0_x64__8wekyb3d8bbwe\DACTileLauncher.exe
[Content]
C:\Program Files\WindowsApps\Microsoft.DesktopAppConverter_2.0.2.0_x64__8wekyb3d8bbwe\DACTileLauncher.exe
The data area passed to a system call is too small.
I have tried running the Troubleshooter for Windows Apps, it tells me that "Windows Store cache and licenses may be corrupt" and tries to fix them, but running the troubleshooter a second time gives the same issue.
Each time I try to run the Desktop App Converter, I get 2 errors in Event Viewer:
%1: Cannot create the Desktop AppX container for package %2 because an error was encountered configuring the runtime.
%4: Cannot create the process for package %1 because an error was encountered while configuring runtime. %5
... both from AppModel-runtime
Any ideas how I can troubleshoot from here?
If you have problems with the Microsoft DAC you try this new converter, it is much easier to use, it has a GUI (no command line), built-in support for digital signing and allows you to customize the list of files that get inside your AppX.
Also, you can generate AppX packages for applications which do not (cannot) install silently.
It runs on Windows 7 too, not just Windows 10 (recommended).
I have a strange issue. I build my Meteor app and run it on android device using -
meteor run android-device --mobile-server=<my_aws_ip>:3000
When the app deploys immediately it connects to the server (and my javascripts etc works). After a few seconds, the page refreshs and none of the javascript callbacks work. Please help me debug this issue.
More information: If I change the client (and not the server), and deploy it, for the first few seconds, the changed client gets shown on the phone. After the first few seconds, the version which is present on the server is shown. So I think Cordova or Meteor is trying to fetch the client code from the server, which is breaking the app. Is there a way to prevent this behavior?
Even more data points -
My aws code does NOT have android and ios platforms installed. Because of this, I think the cordova plugins are not installed, causing a JS break somewhere.
Easiest fix I can think of is remove cordova autoupdate. This is being added by meteor-platform package. If I clone meteor-platform and comment out the cordova autoupdate, the app doesn't load.
Is there another way of removing autoupdate?
This sounds like you have a different version of your app deployed at the mobile-server address.
The local code is run in development mode. Your AWS one is likely in production mode (and may contain a syntax error).
When you run your app it sees the code is different and fetches the new/old (different) version with a hot code reload - hence the page refresh/flash.
To fix this, you need to find the syntax error in your code. It's best to view the ADB logger or run with meteor run --verbose android-device ....
This will provide a bit more information such as an Uncaught exception: cannot read .. of null error type error.
It's hard to say what the error is. The error prevents the rest of your code from executing. In production mode the entire project is one JS file. If there is an error of any kind half way along the file, the rest of the file will not execute.
Also, try loading <my_aws_ip>:3000 in your browser and watch for JS errors in the JS console.
You can also run it locally with --production to simulate a production build environment locally.
Enabling autoupdate but without a page refresh:
Reload._reload = function (options) {
console.log("Next load will load new version");
};