Bellek sızıntısını önlemek için JDBC Sürücüsü zorla kayıt dışı bırakıldı


325

Web uygulamamı çalıştırdığımda bu mesajı alıyorum. İyi çalışıyor ama kapatma sırasında bu mesajı alıyorum.

SEVERE: Bir web uygulaması JBDC sürücüsünü [oracle.jdbc.driver.OracleDriver] kaydetti, ancak web uygulaması durdurulduğunda kaydı sildi. Bellek sızıntısını önlemek için JDBC Sürücüsü zorla kayıt dışı bırakıldı.

Herhangi bir yardım takdir.


Yanıtlar:


301

Sürümü 6.0.24 beri bir ile Tomcat gemileri bellek sızıntısı tespit web uygulamasının bir JDBC 4.0 uyumlu sürücü varken sırayla uyarı mesajları bu tür yol açabilir özelliği, /WEB-INF/libhangi oto kayıtları kendisi kullanarak web uygulamasının başlangıç sırasında ServiceLoaderAPI , ancak oto- vermedi Deregister web uygulamasının kapatma sırasında kendisi. Bu mesaj tamamen gayri resmi, Tomcat zaten bellek sızıntısını önleme eylemini buna göre gerçekleştirdi.

Ne yapabilirsin?

  1. Bu uyarıları dikkate almayın. Tomcat işini doğru yapıyor. Asıl hata sizinkinde değil, başkasının kodundadır (söz konusu JDBC sürücüsü). Tomcat'in işini düzgün yaptığı için mutlu olun ve JDBC sürücü satıcısının sabitlenmesini bekleyin, böylece sürücüyü yükseltebilirsiniz. Öte yandan, bir JDBC sürücüsünü web uygulamalarına /WEB-INF/libdeğil, yalnızca sunuculara bırakmanız gerekir /lib. Hala webapp'larda saklıyorsanız /WEB-INF/lib, a kullanarak manuel olarak kaydettirmeli ve kaydını silmelisiniz ServletContextListener.

  2. Tomcat 6.0.23 veya daha eski bir sürüme geçin, böylece bu uyarılar sizi rahatsız etmeyecektir. Ama sessizce bellek sızdıracak. Sonuçta bilmek iyi olup olmadığından emin değilim. Bu tür bellek sızıntıları Tomcat hotdeployments sırasında OutOfMemoryErrorsorunların arkasındaki ana nedenlerden biridir.

  3. JDBC sürücüsünü Tomcat'in /libklasörüne taşıyın ve sürücüyü yönetmek için bağlantı havuzlu veri kaynağına sahip olun. Tomcat'in yerleşik DBCP'sinin, sürücülerin kapatıldığında düzgün bir şekilde kaydını silmediğini unutmayın. Ayrıca bkz . WONTFIX olarak kapatılan hata DBCP-322 . DBCP yerine işini DBCP'den daha iyi yapan başka bir bağlantı havuzu ile değiştirmek istersiniz. Örneğin , HikariCP , BoneCP veya belki de Tomcat JDBC Havuzu .


25
Bu iyi bir tavsiye. Bir bellek sızıntısı uyarısı değil, Tomcat'in bir sızıntıyı önlemek için bazı zorlayıcı önlemler aldığı uyarısıdır
matt b

49
Seçenek (1) yol ise, Tomcat bunları neden SEVERE olarak kaydeder? SEVERE, "yoksay" değil "yönetici sayfası" anlamına gelir.
Peter Becker

7
Neden kendiniz yapmıyorsunuz - Tomcat'in yapmasını beklemek yerine. Kanımca, dağınık kodumuzu temizlemek Tomcat'in işi değil. Cevabımı aşağıda görebilirsiniz.
sparkyspider

2
@sproketboy: Ha? JDBC yapılarını, HTTP oturumunda depolanan bir sınıfın alanları olarak mı atadınız?
BalusC

2
Genellikle 3 nedeni (aksine war kütüphaneye sahip) sanırım lib.
lapo

160

Servlet bağlam dinleyicisi contextDestroyed () yönteminizde, sürücülerin kaydını el ile kaldırın:

// This manually deregisters JDBC driver, which prevents Tomcat 7 from complaining about memory leaks wrto this class
Enumeration<Driver> drivers = DriverManager.getDrivers();
while (drivers.hasMoreElements()) {
    Driver driver = drivers.nextElement();
    try {
        DriverManager.deregisterDriver(driver);
        LOG.log(Level.INFO, String.format("deregistering jdbc driver: %s", driver));
    } catch (SQLException e) {
        LOG.log(Level.SEVERE, String.format("Error deregistering driver %s", driver), e);
    }
}

3
İşe yarıyor! javabeat.net/servletcontextlistener-example , sunucu uygulaması dinleyicisinin uygulanmasına yardımcı olabilir
Vadim Zin4uk

17
Bu, kullanılabilir tüm JDBC sürücülerinin kaydını silmek istemeyebileceğiniz için paylaşılan bir ortamda güvenli olmayabilir . Daha güvenli bir yaklaşım için cevabımı görün .
daiscog

85

Tomcat, JDBC sürücüsünü sizin için zorla kayıttan çıkarmasına rağmen, Tomcat'in yaptığı bellek sızıntısı önleme kontrollerini yapmayan başka bir sunucu uygulaması konteynerine taşınmanız durumunda, webapp tarafından içerik imhası üzerinde oluşturulan tüm kaynakları temizlemek iyi bir uygulamadır.

Ancak, battaniye sürücüsünün kaydının silinmesi metodolojisi tehlikelidir. DriverManager.getDrivers()Yöntem tarafından döndürülen bazı sürücüler webapp içeriğinin ClassLoader'ını değil, üst ClassLoader (yani sunucu uygulamasının kapsayıcının yükleyicisi) tarafından yüklenmiş olabilir (örneğin, webapp'larda değil, kabın lib klasöründe olabilir ve bu nedenle tüm kapsayıcıda paylaşılmış olabilirler) ). Bunların kaydının silinmesi, onları (hatta kabın kendisini) kullanabilecek diğer webapps'leri de etkileyecektir.

Bu nedenle, her sürücü için ClassLoader'ın kayıttan kaldırılmadan önce web uygulamasının ClassLoader'ı olup olmadığı kontrol edilmelidir. Yani, ContextListener'ın contextDestroyed () yönteminizde:

public final void contextDestroyed(ServletContextEvent sce) {
    // ... First close any background tasks which may be using the DB ...
    // ... Then close any DB connection pools ...

    // Now deregister JDBC drivers in this context's ClassLoader:
    // Get the webapp's ClassLoader
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    // Loop through all drivers
    Enumeration<Driver> drivers = DriverManager.getDrivers();
    while (drivers.hasMoreElements()) {
        Driver driver = drivers.nextElement();
        if (driver.getClass().getClassLoader() == cl) {
            // This driver was registered by the webapp's ClassLoader, so deregister it:
            try {
                log.info("Deregistering JDBC driver {}", driver);
                DriverManager.deregisterDriver(driver);
            } catch (SQLException ex) {
                log.error("Error deregistering JDBC driver {}", driver, ex);
            }
        } else {
            // driver was not registered by the webapp's ClassLoader and may be in use elsewhere
            log.trace("Not deregistering JDBC driver {} as it does not belong to this webapp's ClassLoader", driver);
        }
    }
}

Olmamalı mı if (cl.equals(driver.getClass().getClassLoader())) {?
user11153

6
@ user11153 Hayır, değerin eşit olan iki ayrı örneği olup olmadığını tam olarak aynı ClassLoader örneğinin olup olmadığını kontrol ediyoruz.
daiscog

4
Diğerleri söz konusu sorunu doğru bir şekilde ele alıyor gibi görünse de, savaş dosyası silindikten ve değiştirildikten sonra sorunlara neden oluyorlar. Bu durumda sürücülerin kaydı silinir ve hiçbir zaman geri dönmez - yalnızca bir Tomcat yeniden başlatması sizi bu delikten çıkarabilir. Bu çözüm cehennemden kaçınır.
OldCurmudgeon

Burada çoğunlukla aynı ama ek MySQL / MariaDB kullanım kodu ile github.com/spring-projects/spring-boot/issues/2612
gavenkoa

2
H2 veya PostgreSQL kullanırsanız, sürücünün yeniden yüklendikten sonra tekrar kaydedilmemesine neden olur. Her iki sürücü de sürücünün kaydının silinmesi durumunda silinmeyen bir iç kayıt durumu sağlar DriverManager. Github.com/spring-projects/spring-boot/issues/…
Marcel Stör

26

Görüyorum ki bu sorun çok ortaya çıkıyor. Evet, Tomcat 7 otomatik olarak kaydını siliyor, ancak kodunuzu ve iyi bir kodlama uygulamasını GERÇEKTEN kontrol ediyor mu? Elbette tüm nesnelerinizi kapatmak, veritabanı bağlantı havuzu iş parçacıklarını kapatmak ve tüm uyarılardan kurtulmak için tüm doğru kodlara sahip olduğunuzu bilmek istersiniz. Kesinlikle yaparım.

Ben böyle yaparım.

Adım 1: Dinleyiciyi Kaydettirin

web.xml

<listener>
    <listener-class>com.mysite.MySpecialListener</listener-class>
</listener>

2. Adım: Dinleyiciyi uygulayın

com.mysite.MySpecialListener.java

public class MySpecialListener implements ServletContextListener {

    @Override
    public void contextInitialized(ServletContextEvent sce) {
        // On Application Startup, please…

        // Usually I'll make a singleton in here, set up my pool, etc.
    }

    @Override
    public void contextDestroyed(ServletContextEvent sce) {
        // On Application Shutdown, please…

        // 1. Go fetch that DataSource
        Context initContext = new InitialContext();
        Context envContext  = (Context)initContext.lookup("java:/comp/env");
        DataSource datasource = (DataSource)envContext.lookup("jdbc/database");

        // 2. Deregister Driver
        try {
            java.sql.Driver mySqlDriver = DriverManager.getDriver("jdbc:mysql://localhost:3306/");
            DriverManager.deregisterDriver(mySqlDriver);
        } catch (SQLException ex) {
            logger.info("Could not deregister driver:".concat(ex.getMessage()));
        } 

        // 3. For added safety, remove the reference to dataSource for GC to enjoy.
        dataSource = null;
    }

}

Lütfen yorum yapmak ve / veya eklemek için çekinmeyin ...


4
Ama DataSourcebir closeyöntemi DEĞİL
Jim

9
javax.servlet.ServletContextListener uygular, ApplicationContextListener genişletmez?
egaga

2
Yöntemdeki bu işlemlerin sırasının bir nedeni var mı contextDestroyed? Neden adımı 2. yapmadan önce adım 1. yapacağız initContext, envContextve datasourcehiç başvurulan değildir? Soruyorum çünkü 3. adımı anlamıyorum
matthaeus

4
@matthaeus Sanırım Adım 1. gerekli değil, lookupsadece ihtiyacınız olmayan bazı nesneleri alıyor gibi görünüyor. 3. Adım tamamen işe yaramaz. Kesinlikle bir güvenlik katmıyor ve GC'nin nasıl çalıştığını anlamayan yeni başlayanların yapacakları bir şey gibi görünüyor. Sadece stackoverflow.com/a/5315467/897024 ile gider ve tüm sürücüleri kaldırırım.
kapex

4
@kapep Bazı sürücüler kapsayıcıda paylaşılabileceği için tüm sürücülerin kaldırılması tehlikelidir. Sadece web uygulamanızın ClassLoader tarafından yüklenen sürücüleri kaldıran bir yaklaşım için cevabımı görün .
daiscog

14

Bu tamamen mysql`in sürücüsünde sürücü kaydı / kayıt silme veya webapp-classloader tomcats. Mysql sürücüsünü tomcats lib klasörüne kopyalayın (böylece tomcat tarafından değil, jvm tarafından yüklenir) ve mesaj gitmiş olacaktır. Bu, mysql jdbc sürücüsünün yalnızca JVM kapatma sırasında kaldırılmasını sağlar ve kimse o zaman bellek sızıntılarını umursamaz.


2
işe yaramaz ... Jdbc sürücüsünü kopyalamaya çalıştım: TOMCAT_HOME / lib / postgresql-9.0-801.jdbc4.jar - Tomcat 7.0 \ lib \ postgresql-9.0-801.jdbc4.jar sonuçsuz ...
FAjir

5
@Florito - web uygulamalarınızdan WEB-INF / lib'den de kaldırmanız gerekiyor
Collin Peters

8

Bu mesajı Maven yapımı bir savaştan alıyorsanız verilen JDBC sürücüsünün kapsamını değiştirin ve lib kopyasına bir kopyasını koyun. Bunun gibi:

<dependency>
  <groupId>mysql</groupId>
  <artifactId>mysql-connector-java</artifactId>
  <version>5.1.18</version>
  <!-- put a copy in /usr/share/tomcat7/lib -->
  <scope>provided</scope>
</dependency>

8

Uygulama başına dağıtımlar için çözüm

Bu, sorunu çözmek için yazdığım bir dinleyici: sürücünün kendisini kaydettirip kaydetmediğini otomatik olarak algılar ve buna göre hareket eder.

Önemli: SADECE sürücü kavanozu Tomcat / lib'de değil, WEB-INF / lib'de konuşlandırıldığında , birçok uygulamanın önerdiği gibi kullanılmalıdır, böylece her uygulama kendi sürücüsüyle ilgilenebilir ve dokunulmamış bir Tomcat üzerinde çalışabilir . IMHO böyle olmalı.

Web.xml dosyasındaki dinleyiciyi daha önce yapılandırın ve keyfini çıkarın.

web.xml dosyasının üst kısmına ekleyin :

<listener>
    <listener-class>utils.db.OjdbcDriverRegistrationListener</listener-class>    
</listener>

olarak kaydetmek utils / db / OjdbcDriverRegistrationListener.java :

package utils.db;

import java.sql.Driver;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Enumeration;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

import oracle.jdbc.OracleDriver;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
 * Registers and unregisters the Oracle JDBC driver.
 * 
 * Use only when the ojdbc jar is deployed inside the webapp (not as an
 * appserver lib)
 */
public class OjdbcDriverRegistrationListener implements ServletContextListener {

    private static final Logger LOG = LoggerFactory
            .getLogger(OjdbcDriverRegistrationListener.class);

    private Driver driver = null;

    /**
     * Registers the Oracle JDBC driver
     */
    @Override
    public void contextInitialized(ServletContextEvent servletContextEvent) {
        this.driver = new OracleDriver(); // load and instantiate the class
        boolean skipRegistration = false;
        Enumeration<Driver> drivers = DriverManager.getDrivers();
        while (drivers.hasMoreElements()) {
            Driver driver = drivers.nextElement();
            if (driver instanceof OracleDriver) {
                OracleDriver alreadyRegistered = (OracleDriver) driver;
                if (alreadyRegistered.getClass() == this.driver.getClass()) {
                    // same class in the VM already registered itself
                    skipRegistration = true;
                    this.driver = alreadyRegistered;
                    break;
                }
            }
        }

        try {
            if (!skipRegistration) {
                DriverManager.registerDriver(driver);
            } else {
                LOG.debug("driver was registered automatically");
            }
            LOG.info(String.format("registered jdbc driver: %s v%d.%d", driver,
                    driver.getMajorVersion(), driver.getMinorVersion()));
        } catch (SQLException e) {
            LOG.error(
                    "Error registering oracle driver: " + 
                            "database connectivity might be unavailable!",
                    e);
            throw new RuntimeException(e);
        }
    }

    /**
     * Deregisters JDBC driver
     * 
     * Prevents Tomcat 7 from complaining about memory leaks.
     */
    @Override
    public void contextDestroyed(ServletContextEvent servletContextEvent) {
        if (this.driver != null) {
            try {
                DriverManager.deregisterDriver(driver);
                LOG.info(String.format("deregistering jdbc driver: %s", driver));
            } catch (SQLException e) {
                LOG.warn(
                        String.format("Error deregistering driver %s", driver),
                        e);
            }
            this.driver = null;
        } else {
            LOG.warn("No driver to deregister");
        }

    }

}

İpucu: Servlet 3.0'dan itibaren, sınıfınıza ek açıklama ekleyebilir @WebListenerve web.xmlyapılandırmayı atlayabilirsiniz .
Basil Bourque

Doğru, sadece yeterince yüksek bir önceliğe sahip olduğundan emin olun, böylece hiç kimsenin sürücüyü önce veya sonra kullanmasına gerek kalmaz.
Andrea Ratto

6

Buna Bahar forumlarında bulduğum bir şeyi ekleyeceğim. JDBC sürücü kavanozunuzu web uygulamanızla dağıtmak yerine tomcat lib klasörüne taşırsanız uyarı kayboluyor gibi görünür. Bunun benim için çalıştığını doğrulayabilirim

http://forum.springsource.org/showthread.php?87335-Failure-to-unregister-the-MySQL-JDBC-Driver&p=334883#post334883


1
Bence bu daha iyi bir çözüm sunuyor - sadece DatasourceManager'ınızı alt sınıftan ayırın ve kayıt silme eklemek için kapatma yöntemini geçersiz kılın. Daha sonra Spring, içeriğini yok ettiğinde bunu halledecek ve Tomcat size SEVERE günlüğünü vermeyecek ve JDBC sürücünüzü lib dizinine taşımak zorunda değilsiniz. İşte eski bahar forumundan orignal msg
Adam

6

Herhangi bir JDBC sürücülerinin kaydını silmek için basit bir destroy () yönteminin uygulanmasının iyi çalıştığını gördüm.

/**
 * Destroys the servlet cleanly by unloading JDBC drivers.
 * 
 * @see javax.servlet.GenericServlet#destroy()
 */
public void destroy() {
    String prefix = getClass().getSimpleName() +" destroy() ";
    ServletContext ctx = getServletContext();
    try {
        Enumeration<Driver> drivers = DriverManager.getDrivers();
        while(drivers.hasMoreElements()) {
            DriverManager.deregisterDriver(drivers.nextElement());
        }
    } catch(Exception e) {
        ctx.log(prefix + "Exception caught while deregistering JDBC drivers", e);
    }
    ctx.log(prefix + "complete");
}

5
Bu, kullanılabilir tüm JDBC sürücülerinin kaydını silmek istemeyebileceğiniz için paylaşılan bir ortamda güvenli olmayabilir . Daha güvenli bir yaklaşım için cevabımı görün . Ayrıca, JDBC sürücünüz web uygulamanızdaki tüm sunucu uygulamalarınızda paylaşıldığından, bu durum sunucu başına değil bir ServletContextListener içinde yapılmalıdır.
daiscog

3

Bu bellek sızıntısını önlemek için, sürücüyü bağlam kapatma sırasında kaydının silinmesi yeterlidir.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.mywebsite</groupId>
    <artifactId>emusicstore</artifactId>
    <version>1.0-SNAPSHOT</version>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.7.0</version>
                <configuration>
                    <source>1.9</source>
                    <target>1.9</target>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <dependencies>
        <!-- ... -->

        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-core</artifactId>
            <version>4.0.1.Final</version>
        </dependency>

        <dependency>
            <groupId>org.hibernate.javax.persistence</groupId>
            <artifactId>hibernate-jpa-2.0-api</artifactId>
            <version>1.0.1.Final</version>
        </dependency>

        <!-- https://mvnrepository.com/artifact/mysql/mysql-connector-java -->
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>8.0.11</version>
        </dependency>

        <!-- https://mvnrepository.com/artifact/javax.servlet/servlet-api -->
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
            <version>2.5</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

</project>

MyWebAppContextListener.java

package com.emusicstore.utils;

import com.mysql.cj.jdbc.AbandonedConnectionCleanupThread;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import java.sql.Driver;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Enumeration;

public class MyWebAppContextListener implements ServletContextListener {

    @Override
    public void contextInitialized(ServletContextEvent servletContextEvent) {
        System.out.println("************** Starting up! **************");
    }

    @Override
    public void contextDestroyed(ServletContextEvent servletContextEvent) {
        System.out.println("************** Shutting down! **************");
        System.out.println("Destroying Context...");
        System.out.println("Calling MySQL AbandonedConnectionCleanupThread checkedShutdown");
        AbandonedConnectionCleanupThread.checkedShutdown();

        ClassLoader cl = Thread.currentThread().getContextClassLoader();

        Enumeration<Driver> drivers = DriverManager.getDrivers();
        while (drivers.hasMoreElements()) {
            Driver driver = drivers.nextElement();

            if (driver.getClass().getClassLoader() == cl) {
                try {
                    System.out.println("Deregistering JDBC driver {}");
                    DriverManager.deregisterDriver(driver);

                } catch (SQLException ex) {
                    System.out.println("Error deregistering JDBC driver {}");
                    ex.printStackTrace();
                }
            } else {
                System.out.println("Not deregistering JDBC driver {} as it does not belong to this webapp's ClassLoader");
            }
        }
    }

}

web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                             http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
         version="4.0">

    <listener>
        <listener-class>com.emusicstore.utils.MyWebAppContextListener</listener-class>
    </listener>

<!-- ... -->

</web-app>

Bu hata düzeltmesi için bana ilham veren kaynak .


2

Benzer bir sorun yaşıyordum, ancak ek olarak Tomcat sunucusu çalışırken JSP sayfalarını değiştirdiğim / kaydettiğimde Java Heap Space hatası alıyordum, bu nedenle bağlam tamamen şarj edilmedi.

Sürümlerim Apache Tomcat 6.0.29 ve JDK 6u12 idi.

Http://wiki.apache.org/tomcat/MemoryLeakProtection URL'sinin Başvurular bölümünde önerildiği gibi JDK'yı 6u21'e yükseltmek , JDBC Sürücüsü hatası hala görünmesine rağmen Java Yığın Alanı sorununu (bağlam şimdi yeniden yükleniyor) çözdü.


0

Aynı sorunu Tomcat 6.026 sürümünde de buldum.

Mysql JDBC.jar WebAPP Kitaplığı ve yanı sıra TOMCAT Lib kullandım.

Jar TOMCAT lib klasöründen kaldırarak yukarıdaki düzeltmek için.

Anladığım kadarıyla TOMCAT JDBC bellek sızıntısını düzgün bir şekilde ele alıyor. Ancak MYSQL Jdbc kavanoz WebApp ve Tomcat Lib'te çoğaltılırsa, Tomcat yalnızca Tomcat Lib klasöründe bulunan kavanozla başa çıkabilir.


0

Grails uygulamamı AWS'ye dağıtırken bu sorunla karşılaştım. Bu JDBC varsayılan sürücüsü org.h2 sürücüsüdür. Bunu, yapılandırma klasörünüzün içindeki Datasource.groovy'de görebileceğiniz gibi. Aşağıda görebileceğiniz gibi:

dataSource {
    pooled = true
    jmxExport = true
    driverClassName = "org.h2.Driver"   // make this one comment
    username = "sa"
    password = ""
}

Veritabanını kullanmıyorsanız , datasource.groovy dosyasında org.h2.Driver'ın bulunduğu her yere bu satırları yorumlayın . Aksi takdirde bu veritabanı jar dosyasını indirmeniz gerekir.

Teşekkürler .


0

Bu hata JTDS Driver 1.3.0 (SQL Server) ile Grails uygulamasında başıma geldi. Sorun, SQL Server'da yanlış bir giriş oldu. Bu sorunu (SQL Server'da) çözdükten sonra uygulamam Tomcat'te doğru bir şekilde dağıtıldı. İpucu: Stacktrace.log hata gördüm

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.