[JBoss JIRA] (ISPN-6908) Display available JDBC datasources as a dropdown menu
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-6908:
----------------------------------
Summary: Display available JDBC datasources as a dropdown menu
Key: ISPN-6908
URL: https://issues.jboss.org/browse/ISPN-6908
Project: Infinispan
Issue Type: Enhancement
Components: Console
Affects Versions: 9.0.0.Alpha3
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Currently the name of JDBC datasources are entered manually by the user, this should be replaced with a select option that consists of the configured datasources.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (ISPN-6890) Infinispan server can not start with Openshift
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6890?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-6890:
------------------------------------
Summary: Infinispan server can not start with Openshift (was: Infinispan server can not start with Kubernetes)
> Infinispan server can not start with Openshift
> ----------------------------------------------
>
> Key: ISPN-6890
> URL: https://issues.jboss.org/browse/ISPN-6890
> Project: Infinispan
> Issue Type: Bug
> Components: Cloud Integrations
> Affects Versions: 9.0.0.Alpha3, 8.2.3.Final
> Reporter: Sebastian Łaskawiec
> Assignee: Gustavo Fernandes
>
> Infinispan server can not start when deploying on Kubernetes.
> Error message:
> {code}
> $ oc logs pod/infinispan-server-1-t53ad
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /opt/jboss/infinispan-server
> JAVA: /usr/lib/jvm/java/bin/java
> JAVA_OPTS: -server -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> java.lang.IllegalArgumentException: Failed to instantiate class "org.jboss.logmanager.handlers.PeriodicRotatingFileHandler" for handler "FILE"
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$ConstructAction.validate(AbstractPropertyConfiguration.java:116)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:335)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:288)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.commit(LogContextConfigurationImpl.java:297)
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:546)
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:97)
> at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:514)
> at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:476)
> at java.util.logging.LogManager$3.run(LogManager.java:399)
> at java.util.logging.LogManager$3.run(LogManager.java:396)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.logging.LogManager.readPrimordialConfiguration(LogManager.java:396)
> at java.util.logging.LogManager.access$800(LogManager.java:145)
> at java.util.logging.LogManager$2.run(LogManager.java:345)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.logging.LogManager.ensureLogManagerInitialized(LogManager.java:338)
> at java.util.logging.LogManager.getLogManager(LogManager.java:378)
> at org.jboss.modules.Main.main(Main.java:482)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$ConstructAction.validate(AbstractPropertyConfiguration.java:114)
> ... 17 more
> Caused by: java.io.FileNotFoundException: /opt/jboss/infinispan-server/standalone/log/server.log (No such file or directory)
> at java.io.FileOutputStream.open0(Native Method)
> at java.io.FileOutputStream.open(FileOutputStream.java:270)
> at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
> at org.jboss.logmanager.handlers.FileHandler.setFile(FileHandler.java:151)
> at org.jboss.logmanager.handlers.PeriodicRotatingFileHandler.setFile(PeriodicRotatingFileHandler.java:102)
> at org.jboss.logmanager.handlers.FileHandler.setFileName(FileHandler.java:189)
> at org.jboss.logmanager.handlers.FileHandler.<init>(FileHandler.java:119)
> at org.jboss.logmanager.handlers.PeriodicRotatingFileHandler.<init>(PeriodicRotatingFileHandler.java:70)
> ... 22 more
> java.lang.IllegalStateException: WFLYSRV0124: Could not create server data directory: /opt/jboss/infinispan-server/standalone/data
> at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:473)
> at org.jboss.as.server.Main.determineEnvironment(Main.java:297)
> at org.jboss.as.server.Main.main(Main.java:94)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.modules.Module.run(Module.java:329)
> at org.jboss.modules.Main.main(Main.java:507)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (ISPN-6888) Enhance field undo/restart required behaviour
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-6888?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-6888:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Alpha4
Resolution: Done
> Enhance field undo/restart required behaviour
> ---------------------------------------------
>
> Key: ISPN-6888
> URL: https://issues.jboss.org/browse/ISPN-6888
> Project: Infinispan
> Issue Type: Enhancement
> Components: Console
> Affects Versions: 9.0.0.Alpha3
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Minor
> Fix For: 9.0.0.Alpha4
>
>
> Remove restart required and undo notifications for fields if they are manually reset to their original values by the user. It does not make sense for the undo options to exist if the value is the same in the console as on the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (ISPN-6907) Replicated cache with BATCH Transactions do not respect shared store semantics
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-6907?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-6907:
-------------------------------
Summary: Replicated cache with BATCH Transactions do not respect shared store semantics (was: Replicated cache with BATCH Transactions do not follow shared store semantics)
> Replicated cache with BATCH Transactions do not respect shared store semantics
> ------------------------------------------------------------------------------
>
> Key: ISPN-6907
> URL: https://issues.jboss.org/browse/ISPN-6907
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 8.2.3.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 8.2.4.Final
>
>
> When running a replicated cache with transaction mode=BATCH and a shared cache store, it is possible for more than one node to write the store. This does not occur on every batch write.
> So far I haven't been able to reproduce this issue on the master branch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (ISPN-6907) Replicated cache with BATCH Transactions do not follow shared store semantics
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-6907?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-6907:
-------------------------------
Description:
When running a replicated cache with transaction mode=BATCH and a shared cache store, it is possible for more than one node to write the store. This does not occur on every batch write.
So far I haven't been able to reproduce this issue on the master branch.
was:When running a replicated cache with transaction mode=BATCH and a shared cache store, it is possible for more than one node to write the store. This does not occur on every batch write.
> Replicated cache with BATCH Transactions do not follow shared store semantics
> -----------------------------------------------------------------------------
>
> Key: ISPN-6907
> URL: https://issues.jboss.org/browse/ISPN-6907
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 8.2.3.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 8.2.4.Final
>
>
> When running a replicated cache with transaction mode=BATCH and a shared cache store, it is possible for more than one node to write the store. This does not occur on every batch write.
> So far I haven't been able to reproduce this issue on the master branch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (ISPN-6907) Replicated cache with BATCH Transactions do not follow shared store semantics
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-6907:
----------------------------------
Summary: Replicated cache with BATCH Transactions do not follow shared store semantics
Key: ISPN-6907
URL: https://issues.jboss.org/browse/ISPN-6907
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 8.2.3.Final
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 8.2.4.Final
When running a replicated cache with transaction mode=BATCH and a shared cache store, it is possible for more than one node to write the store. This does not occur on every batch write.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (ISPN-6498) Marshalling enhancements
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6498?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-6498:
-----------------------------------
Description:
Marshalling enhancements to reduce complexity and cost:
- -Remove CacheMarshaller/GlobalMarshaller differentiation.- (see ISPN-6905)
- -Manually encode all known types within Infinispan.- (see ISPN-6906)
- -For potentially unknown types, e.g. keys, values, use JBoss Marshalling.- (see ISPN-6906)
- Make dealing with unknown types and Strings pluggable so that other marshalling frameworks can more easily be plugged and we can try alternative ways to encode Strings.
- -Avoid reentrancy of marshalling, e.g. marshall a command, then marshall a marshalled value...etc. With commands being encoded directly by us, no more need for reentrancy support.- (see ISPN-6906)
- -Avoid thread locals, e.g. those thread locals used to keep marshallers around.- (see ISPN-6906)
- -Get rid of VersionAwareMarshaller.- (see ISPN-6905)
- -Deprecate (then remove...) AdvancedCache.with(Classloader) method.- (see ISPN-6905)
was:
Marshalling enhancements to reduce complexity and cost:
- -Remove CacheMarshaller/GlobalMarshaller differentiation- (see ISPN-6905)
- Manually encode all known types within Infinispan.
- For potentially unknown types, e.g. keys, values, use JBoss Marshalling.
- Make dealing with unknown types and Strings pluggable so that other marshalling frameworks can more easily be plugged and we can try alternative ways to encode Strings.
- Avoid reentrancy of marshalling, e.g. marshall a command, then marshall a marshalled value...etc. With commands being encoded directly by us, no more need for reentrancy support.
- Avoid thread locals, e.g. those thread locals used to keep marshallers around.
- -Get rid of VersionAwareMarshaller- (see ISPN-6905)
- -Deprecate (then remove...) AdvancedCache.with(Classloader) method- (see ISPN-6905)
> Marshalling enhancements
> ------------------------
>
> Key: ISPN-6498
> URL: https://issues.jboss.org/browse/ISPN-6498
> Project: Infinispan
> Issue Type: Enhancement
> Components: Marshalling
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
>
> Marshalling enhancements to reduce complexity and cost:
> - -Remove CacheMarshaller/GlobalMarshaller differentiation.- (see ISPN-6905)
> - -Manually encode all known types within Infinispan.- (see ISPN-6906)
> - -For potentially unknown types, e.g. keys, values, use JBoss Marshalling.- (see ISPN-6906)
> - Make dealing with unknown types and Strings pluggable so that other marshalling frameworks can more easily be plugged and we can try alternative ways to encode Strings.
> - -Avoid reentrancy of marshalling, e.g. marshall a command, then marshall a marshalled value...etc. With commands being encoded directly by us, no more need for reentrancy support.- (see ISPN-6906)
> - -Avoid thread locals, e.g. those thread locals used to keep marshallers around.- (see ISPN-6906)
> - -Get rid of VersionAwareMarshaller.- (see ISPN-6905)
> - -Deprecate (then remove...) AdvancedCache.with(Classloader) method.- (see ISPN-6905)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (ISPN-6906) Reduce dependency on JBoss Marshalling
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-6906:
--------------------------------------
Summary: Reduce dependency on JBoss Marshalling
Key: ISPN-6906
URL: https://issues.jboss.org/browse/ISPN-6906
Project: Infinispan
Issue Type: Sub-task
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 9.0.0.Final
Since its inception Infinispan has been using JBoss Marshalling to deal with all the marshalling needs. With some tweaking (e.g. hooking a custom ObjectTable instance), the JBoss Marshalling based Infinispan externalizer layer is able to produce tiny binary payloads but it has some problems partly due to JBoss Marshalling itself and partly due to our own implementation details:
JBoss Marshalling's objective has always been to try to produce a binary format that passes Java specification, but this is not a requirement for Infinispan. In fact, to reduce the payload size, Infinispan hooks at the ObjectTable level to produce minimal payload sizes.
On top of the mismatch problems mentioned above, JBoss Marshalling’s programming model is based around creating a marshaller, writing to it, and then finishing using it by discarding its context (same applies to unmarshalling). The problem here is two-fold:
* Both marshaller and unmarshaller are quite heavy objects, keeping context information such as references to instances appearing multiple times...etc, so constantly creating them is costly. So, to avoid wasting resources, we ended up adding thread locals that keep a number of marshaller/unmarshaller instances per thread (see ISPN-1815). These thread locals can potentially affect memory space (see user dev post).
* The second problem is the need to support reentrant marshalling calls when storing data in binary format. The need for reentrancy appears in situations like this: Imagine you have to marshall a PutKV command, so you start a marshaller and write some stuff. Then, you have store the key and value, but these are binary so they have to be transformed into binary format, so again a marshaller needs to be created and key/value information written, finish with the marshaller and then write the bytes in the command itself. So, there needs to be a way to start two marshallers without having finished the first one. This is the reason why the changes added in ISPN-1815 resulted in the thread local keeping a number of marshaller/unmarshaller instances rather than a single one.
Finally, for inter-node cluster communication and storing data in persistence layer, Infinispan is using JBoss Marshalling for both marshalling the types it knows about, e.g. internal data types, and types it does not know about, e.g. key and value types. This means that even if the marshaller is configurable, it’s not easy to switch to a different marshaller (see here for an example where we try to use a different marshaller). This problem is not present in Hot Rod Java clients since there JBoss Marshalling is purely used to marshall keys and values, so it’s very easy to test out a different marshaller.
With all this in mind, the following change recommendations can be made:
* For those types that we know about, marshall those manually in the most compact way possible. JBoss Marshalling codebase does a lot of these for encoding basic types (e.g. Strings, numbers)...etc, so we should be able to reuse them.
* Only rely on 3rd party marshalling libraries for types we don’t know about, e.g. key and value types (If these key/value types happen to be primitives, or primitive derivations (e.g. arrays), we should be able to optimise those too. So, you only rely on 3rd party marshalling libraries for custom unknown types.). The benefit here is the we decouple Infinispan from using JBoss Marshalling all over the place, making it easier to try different marshalling mechanisms.
* With JBoss Marshalling only used for unknown custom types, if the JBoss Marshalling marshaller implementation wants to use thread locals, that's fine, but then we effectively get rid of them except for custom types when JBoss Marshalling marshaller is used, plus we can switch/try different 3rd party marshallers which might be better suited.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (ISPN-6903) SingleFileStoreStressTest.testFileTruncation fails
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6903?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-6903:
-------------------------------------------
I though you are the most knowledgeable in this area. If I'm wrong - please
reassign it further.
On Thu, Jul 28, 2016 at 10:17 AM, Radim Vansa (JIRA) <issues(a)jboss.org>
> SingleFileStoreStressTest.testFileTruncation fails
> --------------------------------------------------
>
> Key: ISPN-6903
> URL: https://issues.jboss.org/browse/ISPN-6903
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Reporter: Sebastian Łaskawiec
> Assignee: Radim Vansa
> Priority: Critical
>
> http://ci.infinispan.org/viewLog.html?buildId=41261&tab=buildResultsDiv&b...
> {code}
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:33)
> at org.infinispan.persistence.file.SingleFileStoreStressTest.testFileTruncation(SingleFileStoreStressTest.java:272)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (ISPN-6903) SingleFileStoreStressTest.testFileTruncation fails
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-6903?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-6903:
-----------------------------------
[~sebastian.laskawiec] Any specific reason to set me as assignee?
> SingleFileStoreStressTest.testFileTruncation fails
> --------------------------------------------------
>
> Key: ISPN-6903
> URL: https://issues.jboss.org/browse/ISPN-6903
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Reporter: Sebastian Łaskawiec
> Assignee: Radim Vansa
> Priority: Critical
>
> http://ci.infinispan.org/viewLog.html?buildId=41261&tab=buildResultsDiv&b...
> {code}
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:33)
> at org.infinispan.persistence.file.SingleFileStoreStressTest.testFileTruncation(SingleFileStoreStressTest.java:272)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months