[VISUALVM-590] Remove the -J-Xmx256m default option in <path>/etc/visualvm.conf Created: 15/May/14  Updated: 15/May/14

Status: Open
Project: VisualVM
Component/s: code
Affects Version/s: 1.3.6
Fix Version/s: None

Type: Improvement Priority: Trivial
Reporter: drach Assignee: thurka
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS/X 10.9.2


Tags: config

 Description   

VisualVM starts with a very small maximum heap size, at least for modern architectures. It gets an OOME too often. The HotSpot JVM will create a maximum heap size of about 25% of physical memory, so any machine with over 1Gb of physical memory is assigned a smaller heap size than necessary. Remove the command line argument and let HotSpot take care of it.






[MVC_SPEC-57] View engine configuration mechanism in spec Created: 14/Oct/15  Updated: 14/Oct/15

Status: Open
Project: mvc-spec
Component/s: None
Affects Version/s: 1.0-edr2
Fix Version/s: 1.0-pr

Type: Task Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Santiago Pericas-Geertsen
Resolution: Unresolved Votes: 0
Labels: config, engine
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: config, engine

 Description   

The mechanism by which view engine are configured (using produces, etc.) needs to be better described in the specification.






[MQ-339] In TransactionLogManager class, DEFAULT_TXNLOG_FILE_SIZE value has an incorrect size unit Created: 13/Aug/13  Updated: 15/Aug/13  Resolved: 14/Aug/13

Status: Resolved
Project: mq
Component/s: broker-core
Affects Version/s: 5.0
Fix Version/s: 5.1 (RI-Bug-Fix)

Type: Bug Priority: Major
Reporter: Andrew_Scully Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OpenMQ version 5.0 (Build 14-e) running on Windows 8.


Tags: broker, config, default, embedded, jms, log, transaction

 Description   

When starting up an embedded broker, the initialization of the transaction log file fails if the default file size is being used (i.e. not set explicitly in the configuration.properties file). This causes the broker startup to fail (for version 5.0, version 4.5.2 logged an exception but started anyway).

This seems to be because of a bug in com.sun.messaging.jmq.jmsserver.persist.file.TransactionLogManager, within the method initTransactionLogOnStartUp().

When the line...

SizeString filesize = config.getSizeProperty(TXNLOG_FILE_SIZE_PROP, DEFAULT_TXNLOG_FILE_SIZE);

...fails to read a value from the properties file, it uses DEFAULT_TXNLOG_FILE_SIZE. This constant is 10MB, expressed as bytes (10 * 1024 * 1024). The property is interpreted as KB, however, so an attempt is made to set the length of the transaction log file to 10 GB.

Adding a line like this to the config.properties file proved to be an acceptable workaround:
imq.persist.file.txnLog.file.size=1024

A stack trace like is is thrown, presumably because the value being passed to RandomAccessFile.setLength is too big:

[#|2013-08-13T09:56:25.288+0100|SEVERE|5.0|imq.log.Logger|_ThreadID=1;_ThreadName=main;|ERROR [B3101]: Error retrieving persisted data:
com.sun.messaging.jmq.jmsserver.util.BrokerException: [B2096]: Unable to load transaction information.
at com.sun.messaging.jmq.jmsserver.data.TransactionList.<init>(TransactionList.java:235)
at com.sun.messaging.jmq.jmsserver.core.DestinationList.init(DestinationList.java:2714)
at com.sun.messaging.jmq.jmsserver.core.CoreLifecycleImpl.initDestinations(CoreLifecycleImpl.java:110)
at com.sun.messaging.jmq.jmsserver.Broker._start(Broker.java:1233)
at com.sun.messaging.jmq.jmsserver.Broker.start(Broker.java:447)
at com.sun.messaging.jmq.jmsserver.BrokerProcess.start(BrokerProcess.java:164)
at com.sun.messaging.jmq.jmsserver.DirectBrokerProcess.start(DirectBrokerProcess.java:92)
at com.sun.messaging.jmq.jmsclient.runtime.impl.BrokerInstanceImpl.start(BrokerInstanceImpl.java:207)
at com.saaconsultants.jms.test.JmsTestEnvironment.startOpenMQ(JmsTestEnvironment.java:195)
at com.saaconsultants.jms.test.JmsTestEnvironment.start(JmsTestEnvironment.java:101)
at com.saaconsultants.jms.test.JmsTestHelper.startJmsTestEnvironment(JmsTestHelper.java:95)
at com.saaconsultants.jms.test.JmsTestHelper.startJmsTestEnvironment(JmsTestHelper.java:35)
at com.saaconsultants.jms.test.management.ManagementTestsOpenMQ.setUpClass(ManagementTestsOpenMQ.java:31)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: com.sun.messaging.jmq.jmsserver.util.BrokerException: Failed to create transaction log file txnlog
at com.sun.messaging.jmq.jmsserver.persist.file.TransactionLogManager.initTransactionLogOnStartUp(TransactionLogManager.java:567)
at com.sun.messaging.jmq.jmsserver.persist.file.TransactionLogManager.startup(TransactionLogManager.java:256)
at com.sun.messaging.jmq.jmsserver.persist.file.FileStore.init(FileStore.java:478)
at com.sun.messaging.jmq.jmsserver.data.TransactionList.<init>(TransactionList.java:210)
... 28 more
Caused by: java.io.IOException: An attempt was made to move the file pointer before the beginning of the file
at java.io.RandomAccessFile.setLength(Native Method)
at com.sun.messaging.jmq.io.txnlog.file.FileTransactionLogWriter.initNewFile(FileTransactionLogWriter.java:349)
at com.sun.messaging.jmq.io.txnlog.file.FileTransactionLogWriter.init(FileTransactionLogWriter.java:340)
at com.sun.messaging.jmq.io.txnlog.file.FileTransactionLogWriter.<init>(FileTransactionLogWriter.java:283)
at com.sun.messaging.jmq.jmsserver.persist.file.TransactionLogManager.initTransactionLogOnStartUp(TransactionLogManager.java:534)
... 31 more



 Comments   
Comment by amyk [ 14/Aug/13 ]

The broker property imq.persist.file.txnLog.file.size is set in default.properties. It appears that your application didn't configure for the embedded broker to find the default.properties at startup, e.g. -imqhome or -libhome

The size unit in the code for DEFAULT_TXNLOG_FILE_SIZE is now fixed in 5.0.1

Comment by Andrew_Scully [ 14/Aug/13 ]

Just thought I would provide a little background on the scenario I was working on when I ran into this.

I was creating a "standalone" broker instance, that could be run anywhere with no external dependencies. This was so that we could easily test our integration with OpenMQ as part of our automated tests (e.g. in a JUNIT test).

This meant that I couldn't depend on an external OpenMQ installation existing somewhere on the file system. All of the jars came in via Maven, so all I needed to worry about was creating the directory structure (imqhome and varhome) and the configuration files.

I found that, in 4.5.2, just creating empty .properties files worked fine. With 5.0, I found that I had to set the property mentioned above, but no others.

After that, the embedded broker worked fine!

Comment by amyk [ 14/Aug/13 ]

The broker has a set of fallback properties hard-coded. However these fallback properties do not include all properties in default.properties (for this reason, the broker should be configured to locate the default.properties which is under 'IMQ_HOME/lib', as documented in the Java Developer's Guide http://docs.oracle.com/cd/E18930_01/html/821-2440/gjmtr.html#scrolltoc). imq.persist.file.txnLog.file.size default setting is set in TransactionLogManager and 5.0 has a size unit bug, this bug, for that default value.

test case
tonga/jmsclient/direct/direct_bugMQ339





[JAVAMONEY-4] Scrap Dependency to joda-convert from pom.xml Created: 01/Aug/12  Updated: 01/Dec/12  Resolved: 01/Aug/12

Status: Closed
Project: javamoney
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Tags: config, maven

 Description   

The main pom.xml contains a dependency
<dependency>
<groupId>org.joda</groupId>
<artifactId>joda-convert</artifactId>
<version>1.1</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>

This should go away, the JSR must not rely on external libraries.






[GRIZZLY-1795] Encoding mapping key search error Created: 06/Aug/15  Updated: 07/Aug/15  Resolved: 07/Aug/15

Status: Resolved
Project: grizzly
Component/s: configuration, framework, http
Affects Version/s: 2.3.15
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mahairod Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Fedora 22, jdk8, glassfish-4.1, LC_NAME="ru_RU.UTF-8"


Tags: config, encoding

 Description   

Method getCharset of class CharsetMapper does mot recognise locale string if it consists of parts separated by "-". As a result <locale-encoding-mapping-list> setting of web.xml is not working properly.



 Comments   
Comment by mahairod [ 06/Aug/15 ]

I mean class org.apache.catalina.util.CharsetMapper under CharsetMapper.

Comment by oleksiys [ 07/Aug/15 ]

Hi, this class is not part of Grizzly, but Glassfish.
Please file the bug here [1]

Thanks.

[1] https://java.net/jira/browse/GLASSFISH/





[GLASSFISH-21409] Encoding mapping key search error Created: 07/Aug/15  Updated: 21/Feb/17

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mahairod Assignee: Kokil_Jain
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Fedora 22, jdk8, glassfish-4.1, LC_NAME="ru_RU.UTF-8"


Tags: config, encoding, wait

 Description   

Method getCharset of class org.apache.catalina.util.CharsetMapper does mot recognise locale string if it consists of parts separated by "-". As a result <locale-encoding-mapping-list> setting of web.xml is not working properly.



 Comments   
Comment by Kokil_Jain [ 17/Feb/17 ]

I am unable to reproduce the bug.
Can you please provide with the exact steps to reproduce the bug and also the sample application ?

Comment by mahairod [ 17/Feb/17 ]

it;s enough to place encoding mappings tio web.xml of any webapp and deploy it





Generated at Sat Feb 25 06:24:27 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.