[JBoss JIRA] (ISPN-6073) Replace Set<Flag> by a bit set.
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-6073:
---------------------------------
Summary: Replace Set<Flag> by a bit set.
Key: ISPN-6073
URL: https://issues.jboss.org/browse/ISPN-6073
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 8.0.2.Final
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Removing Set<Flag> will allow us to reduce the allocation rates since we do a lot of copies/marshalling/unmarshalling.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 12 months
[JBoss JIRA] (ISPN-6072) Handle exceptions properly throughout the codebase
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-6072?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-6072:
--------------------------------
Attachment: remote-exception-empty-handler-java.txt
embedded-query-exception-empty-handler-java.txt
embedded-exception-empty-handler-java.txt
Attaching files with detailed results.
> Handle exceptions properly throughout the codebase
> --------------------------------------------------
>
> Key: ISPN-6072
> URL: https://issues.jboss.org/browse/ISPN-6072
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.0.2.Final
> Reporter: Martin Gencur
> Attachments: embedded-exception-empty-handler-java.txt, embedded-query-exception-empty-handler-java.txt, remote-exception-empty-handler-java.txt
>
>
> There are places in Infinispan code base where exceptions are not handled properly. There are 3 types of problems which have been tested:
> 1) the exception handler is empty
> 2) there's a terminating command in the exception handler (unexpected abort in exception overcatch)
> 3) TODO or FIXME in exception handlers
> I've run Aspirator (https://github.com/diy1/aspirator) for infinispan-embedded, infinispan-embedded-query and infinispan-remote uberjars. Detailed results are attached. The summary is following. No issues of type 2) and 3) were found in the code base. The issue type 1) is described below :
> * infinispan-embedded - 21 issues of type 1)
> * infinispan-embedded-query - 5 issues of type 1)
> * infinispan-remote - 1 issue of type 1) (the remaining 10 issues comes from infinispan-commons which is shared between infinispan-embedded and infinispan-remote)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (ISPN-6072) Handle exceptions properly throughout the codebase
by Martin Gencur (JIRA)
Martin Gencur created ISPN-6072:
-----------------------------------
Summary: Handle exceptions properly throughout the codebase
Key: ISPN-6072
URL: https://issues.jboss.org/browse/ISPN-6072
Project: Infinispan
Issue Type: Bug
Affects Versions: 8.0.2.Final
Reporter: Martin Gencur
There are places in Infinispan code base where exceptions are not handled properly. There are 3 types of problems which have been tested:
1) the exception handler is empty
2) there's a terminating command in the exception handler (unexpected abort in exception overcatch)
3) TODO or FIXME in exception handlers
I've run Aspirator (https://github.com/diy1/aspirator) for infinispan-embedded, infinispan-embedded-query and infinispan-remote uberjars. Detailed results are attached. The summary is following. No issues of type 2) and 3) were found in the code base. The issue type 1) is described below :
* infinispan-embedded - 21 issues of type 1)
* infinispan-embedded-query - 5 issues of type 1)
* infinispan-remote - 1 issue of type 1) (the remaining 10 issues comes from infinispan-commons which is shared between infinispan-embedded and infinispan-remote)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (ISPN-6066) HotRodServerConfigurationBuilder.build() mutates the builder
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6066?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6066:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 8.2.0.Alpha1
8.2.0.Final
Resolution: Done
> HotRodServerConfigurationBuilder.build() mutates the builder
> ------------------------------------------------------------
>
> Key: ISPN-6066
> URL: https://issues.jboss.org/browse/ISPN-6066
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.1.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 8.2.0.Alpha1, 8.2.0.Final
>
>
> When HotRodServerConfigurationBuilder.build() calls validate(), and proxyHost/proxyPort is not set, it sets its value. That causes problems if you call build() once, (throw away the configuration) and reset host/port to different value - proxyHost/proxyPort is already set, although the user thinks that it's at its defaults (the same as host/port).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (ISPN-6071) NullPointerException when executing RemoveExpiredCommand
by Jason Hoetger (JIRA)
Jason Hoetger created ISPN-6071:
-----------------------------------
Summary: NullPointerException when executing RemoveExpiredCommand
Key: ISPN-6071
URL: https://issues.jboss.org/browse/ISPN-6071
Project: Infinispan
Issue Type: Bug
Components: Expiration
Affects Versions: 8.0.2.Final
Reporter: Jason Hoetger
I'm running Infinispan 8.0.2 in a clustered environment with a replicated cache with a single file cache store. I'm seeing some NullPointerExceptions when Infinispan executes the RemoveExpiredCommand. Here's a snippet from the stack trace:
{{ISPN000136: Error executing command RemoveExpiredCommand, writing keys [...large key here...]
...
Caused by: java.lang.NullPointerException: null
at org.infinispan.commands.write.RemoveExpiredCommand.setParameters(RemoveExpiredCommand.java:142)}}
Here's RemoveExpiredCommand#setParameters(...):
{{ @Override
public void setParameters(int commandId, Object[] args) {
if (commandId != COMMAND_ID) throw new IllegalStateException("Invalid method id");
int i = 0;
commandInvocationId = (CommandInvocationId) args[i++];
key = args[i++];
value = args[i++];
lifespan = (long) args[i++];
}}}
Line 142 is the cast of assignment of args[3] to primitive type long, which is causing the NPE. lifespan is actually a Long, not a long, and the #perform() method seems to anticipate null lifespans at line 72:
{{ // If the provided lifespan is null, that means it is a store removal command, so we can't compare lifespan
if (lifespan == null) {}}
Could this be fixed by simply changing the cast at line 142 from (long) to (Long)?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years