Does anyone know what improvements have been applied in version 2.8.0 over version 2.7.9 of hikariCP to manage database connection pools? I have a memory leak problem in my application and I am using Spring Data with the standard methods of JpaRepository, that is, I am not controlling the opening and closing of the connection manually.
It may also be a website with the improvements applied to each version.
Related
We have migrated a space from cloud instance to server instance,in cloud instance we were using "Plantuml diagrams for confluence" but in server we are using "Confluence PlantUML Plugin" .so macro name are different in both cloud and server ,so macro name for cloud is "plantumlcloud" but for server it is "plantuml".so ,in pages after migration it is showing "plantumlcloud" not a valid macro ,kindly help to resolve.
In general, migration of confluence spaces to another application which is not running the same plugins will cause any functionality of that plugin to break.
If you migrate hosting platforms, and have the equivalent version of the plugin for your new platform, created by the same developer, in most cases you will retain functionality, however there will often be differences between versions.
These differences are found especially when downgrading, and moving from cloud to server is a very definite example of a downgrade, as cloud will always run the latest version.
In general I would reccomend against a migration from cloud to server, and when it must be done, time should be spent to ensure compatability with all plugins, and migration guides and plans should be made and followed.
As commented by #tgdavies, there seems to be an equivelent version of the plugin you were using on cloud, so hopefully that can resolve your issue.
We have an application on JBoss 7.1.0 istance, usually running ok but sometime the performance degrading, in this case a restart of JBoss is useful.
I have configured an access.log to record the timing of the pages and when the performance are degrading, we have an increase in recorded time on it for some pages.
How can I better identify and troubleshoot the problem? I think can be a problem related to objects in memory of JBoss server.
I exclude can be a memory issue on client because the access.log record the slow time, is it right or can I be misinterpreting the access.log and the problem can be also on client?
The ram / cpu on server are not under load when there are slowness and the xmx is oversized.
The JBoss is on Windows with JDK 1.7.0_80.
Thanks
UPDATE: Our degrading performance problem was related to an APM configured to record too much data and solved by removing it (are needed to be better configured).
I don't think JBOSS server has a problem. By reading your statement, I think the your code is leaking connections. Login into JBOSS Console and see the stats of your connection pools (you need to enable stats if not enabled already). If the connection count grows linearly and never comes down then you need to fix the leakage at code level. You can also use JConsole to monitor JVM memory and detect problems.
Pardon if I can't give more pointers, but I'm really a noob at wildfly. I'm using version 9.0.2.
I have deployed jbpm-console, drools, and dashboard - no problems here. I restart wildfly using the jboss CLI, and when I login again, the repositories won't appear in the web interface or on disk (atleast nothing that grepping or find will show).
I'm using the H2 database. I'm not even sure where to look, does anyone have any idea?
Thanks in advance!
After enough reading through the docs, it would seem that it's necessary to configure jBPM to persist. From the docs:
"By default, the engine does not save runtime data persistently. This means you can use the engine completely without persistence (so not even requiring an in memory database) if necessary, for example for performance reasons, or when you would like to manage persistence yourself. It is, however, possible to configure the engine to do use persistence by configuring it to do so. This usually requires adding the necessary dependencies, configuring a datasource and creating the engine with persistence configured."
https://docs.jboss.org/jbpm/v5.3/userguide/ch.core-persistence.html
We are using SpringSource-TC-Server and we are considering upgrading to java7. (Currently using java6).
We have not seen any reports on SpringSource-TC-Server not working well with java7 but we do not know of any name worthy projects that have migrated to such an environment.
I'm looking for answer(s) about the following:
Are there any known issues?
Are there any projects who migrated and can report on how it went?
Java 7 is officially supported since vFabric tc Server 2.7.0:
http://www.vmware.com/support/vfabric-tcserver/doc/vfabric-tcserver-rn-2.7.0.html#whatsnew
Since you're using tc Server instead of plain Tomcat probably due to commercial support, it's reasonable only to migrate the underlying Java JDK to the latest version when it is officially supported by the employed version of tc Server. Otherwise, you'd be running it in an unsupported configuration, which isn't far from running a plain unsupported open source version of Tomcat.
Operating tc Server on Java 7 in an officially supported arrangement of versions gives you 2 advantages:
It would have been thoroughly tested by vmWare for any incompatibilities so that you wouldn't have to deal with testing by yourself.
If any problems do occur, you can always get support from vmWare in resolving them.
I know it doesn't directly address your questions, as we in my company also haven't upgraded yet and are only planning to do so.
I just had an impression that your approach makes no sense for a commercially supported product and wanted to outline the reasonable (IMO) approach that is in wide use.
As to any known issues, Java 7 is known for its backward incompatible changes to the XML stack, especially the migration to JAXB 2.2 which changes handling of java.lang.Boolean objects (see the other question - What are the pitfalls when upgrading to Java 7). This can spring up in many different places, I've seen it cause problems in Apache CXF's cxf-codegen-plugin that generates Java stubs from WSDL since the wsdl2java tool it launches makes use of JAXB - the generated method names for boolean elements were no longer in the form of java.lang.Boolean isSomeBooleanProperty() but in the form of java.lang.Boolean getSomeBooleanProperty() which broke code depending on those stubs.
So perform thorough testing if you deal with SOAP web services or XML in general.
I just installed rapidSQL 8.0.1 and tried connecting to a valid database. I'm fairly certain I have the right connection data (it was imported from another developer), but I'm getting the following error:
db2abind.dll Cannot be loaded! That will severely impact use of this application. Please restore the missing library.
I have created a ticket with Embarcadero, but I was wondering if anyone else has had this problem and have a solution.
According to the publib, db2abind.dll's functionality has been moved into db2app.dll since version 9 for Linux, Unix, Windows. It also mentions that at that time, stub DLLs were provided for convenience sake, but would be removed in a future version.
Since LUW is now on version 9.7, perhaps this removal has taken place.
Application libraries have changed
Operating systems affected
All supported operating systems are affected.
Change
The following changes have been made:
db2app.dll was extended. It includes its original information, plus
the information from the db2util.dll, db2abind.dll, and db2cli.dll
libraries. db2api.dll was extended. It includes its original
information, plus the information from the db2cli.dll library.
Explanation
The library information is being consolidated.
Resolution
Stubs for the db2util.dll, db2abind.dll, and db2cli.dll
libraries are still available for backwards compatibility. These stubs
will be removed in a future version or release of the product. You
should rebuild your application using the changed libraries.
So this was being caused by the fact that I didn't have a DB2 client installed on my machine. I chose a light db2 client from among the many(!) available at IBM, and it got me past this issue.
http://www.db2dean.com/Previous/DB2Client.html
The above link was a good resource on understanding what was going on with IBM clients and DB2 connectivity.