On my Logout Post method I am seeing
Exception Reading protected message
JSON Value could not be converted to IdentityServer4.Models.LogoutMessage. Path: Line 0, BytePos 170
It's IS4.0.2 running on Core 3.1.5
Any immediate thoughts as to what is causing this? Upgraded from 3 to 4 and it started. Seems to be working however!
Turns out it the SeriLog logging, reflecting the parameter
Log.Verbose("model={#LogoutInputModel}", model);
When verbose logging on, no error and no output
When verbose logging off, error
Related
We implemented Dependency-check-maven and this was working fine up till now. But suddenly getting this error now,
[WARNING] An error occurred while analyzing 'oldui/includes/ckeditor/lang/no.js' (Sonatype OSS Index Analyzer).
Not sure where this is originating from?
I think the reason is due to https://ossindex.sonatype.org/ certificate is expired on 25th May. When you go to that website, you can see that you get the SSL error.
I have been trying to upgrade SQL server 2017 to run Python 3.7. We have installed CU28 and the product version is 14.0.3430.2 which includes the C:\Program Files\Microsoft SQL Server\MSSQL14.INSTANCENAME\PYTHON_SERVICES.3.7.
I have made sure all permissions are granted to the INSTANCENAME directory and pythonlauncher.config working directory is pointing to C:\Program Files\Microsoft SQL Server\MSSQL14.INSTANCENAME\MSSQL\ExtensibilityData and launchpad service account has permissions to this directory.
I have done all this as an upgrade twice and got various errors, and a clean install. The error I am getting is
Msg 39004, Level 16, State 20, Line 0
A 'Python' script error occurred during execution of 'sp_execute_external_script' with HRESULT 0x80004004.
Msg 39019, Level 16, State 2, Line 0
An external script error occurred:
Invalid BXL stream
error while running BxlServer: caught exception: Error communicating between BxlServer and client: 0x000000e8
HRESULT 0x000000e8 looks like INVALID_CANCEL_OF_FILE_OPEN
HRESULT 0x80004004 looks like E_ABORT
So no real clues what is wrong here. pythonlauncher.log does show the error;
[Error] Process::TryTerminate failed with error code: 5
Session 0E93E9D1-07A7-448A-8B1A-FCA5263A5F53 TryTerminate(1067) failed with 5
Error code 5 is ERROR_ACCESS_DENIED
Also got this warning
[Warning] StaleDirectoryCleaner() failed to delete C:\Program Files\Microsoft SQL Server\MSSQL14.INSTANCENAME\MSSQL\ExtensibilityData\FAMSQL17UAT01\8B97815A-E9EA-4FA0-98F3-0440D4180522 after 5 retries
So all up this looks there are still permission issues. Extremely frustrating as there is next to no help on this. Any help would be greatly appreciated.
UPDATE:
After another clean install - first checked Python 3.5.2 worked and it did. Upgraded to 3.7, and again got the same issue. A bit more digging around I find this...
The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/SERVERNAME.domain_name.com:INSTANCENAME ]
Login failed for user 'DOMAIN\SERVERNAME$'. Reason: Could not find a login matching the name provided.
We have a service account that is not part of the domain which is NT Service\MSSQL$INSTANCENAME. Why on this implementation expecting a windows authenticated user the same name as the server??? How can I go about remedy this?
I think what has happened is that MS have left debug code in their production release.
FURTHER UPDATE:
In the event log we are seeing
Faulting application:Python.exe: 3.7.1150.1013 Faulting module name:
pylink.pyd Faulting module path:c:\Program Files\Microsoft SQL
Server\MSSQL14.INSTANCENAME\PYTHON_SERVICES.3.7\lib\site-packages\revoscalepy\rxLibs\pylink.pyd
Microsoft have confirmed that this is a bug. Their work around is below.
It's CU27 and CU28 that 3.7 is broken in - so you could use CU26 and still use Python 3.7. That version started at CU22... so CU22-26 work fine.
Or - it's only the pylink.pyd that is broken - you can simply grab the pylink.pyd from a CU22-26 installation for Python 3.7, and swap it into your CU27/CU28 files. This workaround will work now, and will also not cause any issues going forward once the fix does come. That is, on your next update, it shouldn't interfere and it should all go smoothly.
Unable to perform analysis with sonarqube-5.6.5 and sonar-scanner-msbuild-2.2.0.24.
System Config: 64 bit, Win 7
Java: JAVA 8 U 60/64 bit
Getting error in last step while performing analysis:
call C:\TestTools\SonarSetup\sonar-scanner-msbuild- 2.2.0.24\SonarQube.Scanner.MSBuild.exe end
MSBUILS SONAR
Facing one more error prior to this step: while Trying to start sonar services from below path
C:\####\SonarSetup\sonarqube-5.6.5\bin\windows-x86-64\
please refer to snap shot
sonar service
I am deploying Solr 4.3.0 in Tomcat 7.
Everything works fine but DataImportHandler. I can go to the
http://localhost:8080/solr/#/collection1/dataimport//dataimport
screen and see the dataimport options load at the UI.
Still, I can see any of my entities load in the "entity" combo box. Inside the configuration box, at the right side I can see the error below.
Apache Tomcat/7.0.41 - Error
report
525D76;}--> HTTP Status 500 - Filter execution threw an exception
noshade="noshade">type Exception reportmessage
Filter execution threw an exceptiondescription
The server encountered an internal error that prevented it from
fulfilling this request.exception
javax.servlet.ServletException: Filter execution threw an
exception root cause
java.lang.NoClassDefFoundError: org/apache/log4j/spi/LoggingEvent
org.apache.solr.logging.log4j.EventAppender.append(EventAppender.java:35)
org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
org.apache.log4j.Category.callAppenders(Category.java:206)
org.apache.log4j.Category.forcedLog(Category.java:391)
org.apache.log4j.Category.log(Category.java:856)
org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:498)
org.apache.solr.common.SolrException.log(SolrException.java:119)
org.apache.solr.servlet.ResponseUtils.getErrorInfo(ResponseUtils.java:58)
org.apache.solr.servlet.SolrDispatchFilter.sendError(SolrDispatchFilter.java:691)
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:380)
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:155)
note The full stack trace of the root cause is
available in the Apache Tomcat/7.0.41 logs.Apache Tomcat/7.0.41
Problem is that I have the "log4j-1.2.16.jar" loaded in the classpath (it's on Tomcat lib dir).
Anyone have stepped in this problem?
Try following the steps outlined in Using the example logging setup in containers other than Jetty. I have encountered this same error when running Solr 4.3 until I followed these steps to configure logging.
After changing the directory, did you change the directory path in solrconfig.xml file.
I just want to make sure after the making changes in configuration file, did you restart the tomcat and solr server?
You need to copy the slf4j-log4j12-1.6.6.jar from the ext of Solr into the lib folder.
You also need to put the logging.properties file there.
Does logging work on the dev server? This code doesn't raise an exception, but I can't see where to view the logs in the devserver console. Perhaps I'm looking in the wrong place?
logging.error("error has occurred")
Make sure you create your logger. This should work.
Code
import logging
logging.getLogger().setLevel(logging.DEBUG)
logging.error("uuu")
logging.info("ggg")
Launching from the CLI
$dev_appserver.py ~/workspace/helloworld/
The logs I got on the CLI...
ERROR 2012-11-26 03:02:25,467 helloworld.py:89] uuu
INFO 2012-11-26 03:02:25,467 helloworld.py:90] ggg
Note that this also works for me in Tornado.
Yes, logging works on the dev server. When dev_appserver.py is run from the command-line, you should see output from logging calls such as the one you mentioned whenever they are called.
By default, only logging messages of INFO level and higher are printed.
Also, logging.error() does not raise an exception when called. It simply logs the string you pass at the "error" level - on the development server, this basically just means it will print "ERROR" as part of the logging message on the development server.
You can configure the default logging level when starting the development server:
dev_appserver.py --log_level=debug ...
From dev_appserver.py command-line arguments:
--log_level=...
The lowest logging level at which logging messages will be written to the console; messages of the specified logging level or higher will
be output. Possible values are debug, info, warning, error, and
critical.