I have a site running MVC and Nhibernate (not fluent) using standard session per request in an http module, runs fine locally (also with mysql) but after a move to a hosting provider no update statements are being issued.
I can insert but not update, no exceptions are raised, I have the 'show_sql' option switched on which locally shows the update statements being issued but on the server no update statements are logged.
I don't think NHProf is an option for me as I can only run asp.net apps on my shared server, are there any other methods of diagnosing NH issues like this ?
Anyone had a similar issue ?
Cheers,
A
The issue was that I had moved from my local dev environment with IIS5 to a shared server with IIS7, IIS7 has a different syntax for registering http modules so my NHibernate session module was not firing which caused the behaviour originally described.
To fix this problem I added the modules section in the web.config under system.web to system.webServer, you can add the validation validateIntegratedModeConfiguration="false" key to the system.webServer section which will allow your config to have the module registered under both sections so you can have the same config for IIS5/IIS7.
NHProf is an option for you!
You can have it log to a file, then pick that file up later. This is the log4net config you need:
<log4net>
<appender name="NHProfAppender"
type="HibernatingRhinos.Profiler.Appender.NHibernate.NHProfOfflineAppender,
HibernatingRhinos.Profiler.Appender" >
<file value="nhprof_output.nhprof" />
</appender>
<logger name="HibernatingRhinos.Profiler.Appender.NHibernate.NHProfAppender.Setup">
<appender-ref ref="NHProfAppender"/>
</logger>
</log4net>
Alternatively, if you don't have an NHProf license, you can log the NHibernate stuff to a file in order to see what's happening.
Related
I followed the following configuration for wildfly10:
https://developer.jboss.org/thread/237094
So to be able to use slf4j and logback in my application I disabled the logging subsystem:
<jboss-deployment-structure>
<deployment>
<!-- exclude-subsystem prevents a subsystems deployment unit processors running on a deployment -->
<!-- which gives basically the same effect as removing the subsystem, but it only affects single deployment -->
<exclude-subsystems>
<subsystem name="logging" />
</exclude-subsystems>
</jboss-deployment-structure>
With this configuration my application uses correctly my logback configuration: the problem is that the server does not use anymore its own logging, so the general information are not written anymore to server.log, but they are written to my application appender.
This sounds very strange to me: I tried a lot of other configurations like excluding directly the modules (i.e. org.slf4j and org.slf4j.impl) on my jboss-deployment-structure.xml file but with no effect.
Could someone provide a few details on how to configure Tomcat to access MySQL?
In which directory within Tomcat do I place mysql-connector-java-5.1.13-bin? Should I place it under Tomcat 6.0\webapps\myapp\WEB-INF\lib?
Do I need to add configuration to context.xml or server.xml?
Should I create a web.xml file and place it under Tomcat 6.0\webapps\myapp\WEB-INF? If so, then what should the contents of this file look like?
1: Where to place mysql-connector-java-5.1.13-bin in Tomcat directory? Should I place it under Tomcat 6.0\webapps\myapp\WEB-INF\lib?
That depends on where the connections are to be managed. Normally you would like to create a connection pooled JNDI datasource to improve connecting performance. In that case, Tomcat is managing the connections and need to have access to the JDBC driver. You should then drop the JAR file in Tomcat/lib.
But if you're doing it the basic way using DriverManager#getConnection(), then it in fact don't matter if you drop it in Tomcat/lib or YourApp/WEB-INF/lib. You however need to realize that the one in Tomcat/lib will apply for all deployed webapps and that the one in YourApp/WEB-INF/lib will override the one in Tomcat/lib for only the particular webapp.
2: Do I need to confirgure context.xml or server.xml files?
That depends on where the connections are to be managed. When using a JNDI datasource, it suffices to configure it using YourApp/META-INF/context.xml like follows (just create file if not exist):
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Resource
name="jdbc/yourdb" type="javax.sql.DataSource"
maxActive="100" maxIdle="30" maxWait="10000"
url="jdbc:mysql://localhost:3306/yourdb"
driverClassName="com.mysql.jdbc.Driver"
username="yourname" password="yourpass"
/>
</Context>
and the YourApp/WEB-INF/web.xml as follows:
<resource-env-ref>
<resource-env-ref-name>jdbc/yourdb</resource-env-ref-name>
<resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
</resource-env-ref>
If you're doing it the basic DriverManager way, then it's all up to you. Hardcoded, properties file, XML file, etcetera. You should manage it youself. Tomcat won't (and can't) do anything useful for you.
Noted should be that the YourApp/META-INF/context.xml is specific to Tomcat and clones. Each servletcontainer/appserver has its own way of defining JNDI resources. In Glassfish for example, you'd like to do that through the webbased admin interface.
3: Should I write web.xml file and need to place under Tomcat 6.0\webapps\myapp\WEB-INF? If Yes, then what should be the contents of file?
You should always supply one. It's not only to configure resources, but also to define servlets, filters, listeners and that kind of mandatory stuff to run your webapp. This file is part of the standard Servlet API.
See also:
Is it safe to use a static java.sql.Connection instance in a multithreaded system?
How should I connect to JDBC database / datasource in a servlet based application?
Where do I have to place the JDBC driver for Tomcat's connection pool?
DAO Tutorial - basic JDBC/DAO tutorial, targeted on Tomcat/JSP/Servlet
The answer to your questions:
One option is what you've mentioned: place the driver under WEB-INF/lib directory in your WAR file. The other would be in $TOMCAT_HOME/lib directory. The advantage of the latter would be that you don't need to copy the connector jar into every single project you deploy on that application server. Disadvantage is you will need to remember to put the jar file in place before deploying your application in a different application server.
If you need to change something in the default configuration, yes. Otherwise, there are context.xml and server.xml files with default options shipped with tomcat installations.
Your application's (WAR) web.xml should be under WEB-INF directory in your deploy file. You can look at the accepted content to that file in Java EE's servlet container specification. Usually, you place your servlet, filter and their corresponding mappings in that file.
I have two Spring MVC applications that share a commons.jar library. This library includes logback logging library (logback 1.2.3 and slf4j 1.7.25) and the logback.xml file.
Both wars include this line in their web.xml file:
<env-entry>
<env-entry-name>applicationName</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>nameOfApplicationA|nameOfApplicationB</env-entry-value>
</env-entry>
Each application generates its own log file including hostname, for example: HOST1-nameOfApplicationA.log. Logback configuration is as follows:
<insertFromJNDI env-entry-name="java:comp/env/applicationName" as="APP_NAME" />
<appender name="ROLLING_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${LOG_PATH}/${HOSTNAME}-${APP_NAME}.log</file>
...
</appender>
Everything was working OK (Spring MVC 4.3.7.RELEASE, Hibernate 4, C3P0 latest), but we decided to upgrade to Hibernate 5.2.10 and change to HikariCP 2.6.1. After that, logback was no longer able to resolve java:comp/env/applicationName:
ERROR in ch.qos.logback.classic.joran.action.InsertFromJNDIAction - [java:comp/env/applicationName] has null or empty value
Resulting in both applications using the same file name HOST1-APP_NAME_IS_UNDEFINED.log.
As we changed at the same time Hibernate and HikariCP we went back to C3P0 to check the root cause, and can confirm that the new version of Hibernate has nothing to do. The change was developed in its own branch so no other change seems to affect (anyway, when returning to C3P0 it works).
I've been doing some tracing in Hikari's and Logback's code but I'm not able to see anything. I'm stuck, no idea of what to look.
Plan B is insert in each war its own logback.xml but I would like to avoid it and understand the problem as it may affect other parts of the application.
Both wars are deployed together in an Apache Tomcat/8.0.38 server. Tried also 8.5.12. It also happens if only one of the wars is deployed alone.
Although I found no solution, #brettw identified the problem (see https://github.com/brettwooldridge/HikariCP/issues/873), and got a workaround.
It seems that because HikariCP depends on slf4j, and HikariCP is also being initialized and registered into JNDI, is that causing Logback to initialize before the <env-entry> entries have registered.
The test made was initalize Hikari datasource with "org.apache.naming.factory.BeanFactory" factory instead of "com.zaxxer.hikari.HikariJNDIFactory". This way it works correctly.
I have an SSRS report. The report runs fine both in BIDS and when I upload to the SSRS Server. When I click to export to PDF or Tiff in BIDS, it just says Exporting Please Wait... If I try to export to any format using the SSRS Server/Reports, it takes like 10 minutes, then comes back and says:
Server Error in '/Reports' Application.
--------------------------------------------------------------------------------
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".
<!-- Web.Config Configuration File -->
<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.
<!-- Web.Config Configuration File -->
<configuration>
<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
</system.web>
</configuration>
Note: Runtime errors are enabled so this is the only error message I can get. I went into the server logs on the SSRS server and this is what I can see that has errors:
library!ReportServer_0-2!804!07/01/2014-10:08:02:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerStorageException: , An error occurred within the report server database. This may be due to a connection failure, timeout or low disk condition within the database.;
I have tried making a new report and copying over the items and it is still giving me the same problem so I really have no idea what to try next. Please help!
I've only seen this issue on timeouts really, this might not be helpful but have you tried running & accessing the report locally from your reporting services machine and seeing if it's someform of network issue. You shouldn't need any external PDF or Tiffing services installed on the PC for this to work. It may be that it'S more difficult to render PDF/Tiff than straight text to a file.
Sorry for the delay, but I did find the problem. It seems the report was like 8.51 inches wide and didn't fit on a sheet. For whatever reason, when I got it down to 8.5 including the margins, it seems to work now. Stupid microsoft couldn't just give a reasonable error message. Anyways, thanks for all your help.
Hi I have copied my Solr config from a working windows server to a new one, and it can't seem to run an import.
They're both using win server 2008 and SQL 2008R2. This is the data import config:
<dataConfig>
<dataSource type="JdbcDataSource" name="ds1"
driver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
url="jdbc:sqlserver://localhost;databaseName=DB"
user="Solr"
password="pwd"/>
<document name="datas">
<entity name="data" dataSource="ds1" pk="key"
query="EXEC SOLR_COMPANY_SEARCH_DATA"
deltaImportQuery="SELECT * FROM Company_Search_Data WHERE [key]='${dataimporter.delta.key}'"
deltaQuery="SELECT [key] FROM Company_Search_Data WHERE modify_dt > '${dataimporter.last_index_time}'">
<field column="WorkDesc_Comments" name="WorkDesc_Comments_Split" />
<field column="WorkDesc_Comments" name="WorkDesc_Comments_Edge" />
</entity>
</document>
</dataConfig>
I can use MS SQL Profiler to watch the Solr user log in successfully, but then nothing. It doesn't seem to even try and execute the stored procedure. Any ideas why this would be working one server and not on another?
FTR the only thing in the tomcat catalina log is:
org.apache.solr.handler.dataimport.JdbcDataSource$1 call
INFO: Creating a connection for entity data with URL: jdbc:sqlserver://localhost;databaseName=CATLive
UPDATE:
Me and Yavar Husain from the Solr Mailing list both came up with the solution of replacing the MS JDBC Driver with an open source one - this seems to work, and means this must be a compatibility problem between the latest versions of Java, the DIH and the MS JDBC driver.
UPDATE 2:
Issues have been reported with Java 1.6.0_29 - which I am running!
http://blogs.msdn.com/b/jdbcteam/archive/2011/11/07/supported-java-versions-november-2011.aspx
This looks to have been caused by a release of Java 1.6.0_29 - which I was running:
http://blogs.msdn.com/b/jdbcteam/archive/2011/11/07/supported-java-versions-november-2011.aspx
Seeing as the problem could only be with the JDBC drivers or their config, I have worked around this issue by replacing them with the jTDS Open Source JDBC driver. My config ended up like this when I got it working with that:
<dataConfig>
<dataSource type="JdbcDataSource"
driver="net.sourceforge.jtds.jdbc.Driver"
url="jdbc:jtds:sqlserver://localhost;databaseName=DBName"
user="Solr"
password="password" name="ds1"/>
<document>
<entity dataSource="ds1" name="sometext"
query="SELECT * FROM mytable">
</entity>
</document>
</dataConfig>
HTH someone - but I'm not marking this as the answer because I can't see why I can't use the MS drivers...
I guess you are missing this
url="jdbc:mysql://localhost/dbname"
dbname -> \SQL2008
I presume when you copied your Solr config to the new server you've taken the index file too. I suspect the problem is due to the fact that Solr has already indexed this data. Your query states that you only want to index files that have changes since the last index.
Does this make sense?
The issue appears to occur only on very specific releases of the java runtime, and affects applications beyond just solr. This leads me to believe that the root cause is an incompatibility or bug between the Java runtime and Microsoft SQL Server JDBC drivers rather than being a Solr issue.
In my particular case we had two groups consisting of 3 servers each. One group showed no symptoms of this problem, and the other group all exhibited issues. All servers were running Solr 3.4.0, and the same release of SQL Server JDBC drivers 3.0. All servers were also running JRE 1.6.0_20, but upon closer inspection it was identified that the problem servers were using a slightly newer package for 1.6.0_20 (a different RPM distributed via yum for CentOS).
By downgrading the problem servers to the exact version of java on the known-good servers the problem immediately went away.
Specifically,
working:
http://pkgs.org/centos-5-rhel-5/centos-rhel-x86_64/java-1.6.0-openjdk-1.6.0.0-1.22.1.9.8.el5_6.x86_64.rpm.html
non-working:
http://pkgs.org/centos-5-rhel-5/centos-rhel-updates-x86_64/java-1.6.0-openjdk-src-1.6.0.0-1.23.1.9.10.el5_7.x86_64.rpm.html