[JBoss JIRA] (ISPN-7335) Simple JS client tutorial fails
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-7335?page=com.atlassian.jira.plugin.... ]
Pedro Zapata Fernandez closed ISPN-7335.
----------------------------------------
Resolution: Out of Date
> Simple JS client tutorial fails
> -------------------------------
>
> Key: ISPN-7335
> URL: https://issues.jboss.org/browse/ISPN-7335
> Project: Infinispan
> Issue Type: Bug
> Components: Demos and Tutorials
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
> Priority: Major
>
> [Simple tutorial for JS client|http://infinispan.org/tutorials/simple/javascript/] fails with
> {noformat}
> /home/vjuranek/tmp/node/node_modules/infinispan/lib/utils.js:119
> if (f.existy(x)) throw new Error('Unknown server addresses: ' + x);
> ^
> Error: Unknown server addresses: 11222
> at Function.<anonymous> (/home/vjuranek/tmp/node/node_modules/infinispan/lib/utils.js:119:34)
> at /home/vjuranek/tmp/node/node_modules/infinispan/lib/functional.js:173:19
> at Object.normalizeAddresses (/home/vjuranek/tmp/node/node_modules/infinispan/lib/utils.js:122:12)
> at Object.client (/home/vjuranek/tmp/node/node_modules/infinispan/lib/infinispan.js:810:26)
> at Object.<anonymous> (/home/vjuranek/tmp/node/tut/index.js:3:28)
> at Module._compile (module.js:409:26)
> at Object.Module._extensions..js (module.js:416:10)
> at Module.load (module.js:343:32)
> at Function.Module._load (module.js:300:12)
> at Function.Module.runMain (module.js:441:10)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-7002) NPE in DelegatingQuery.java:42 when deployed in Wildfly 10.1.0.Final
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-7002?page=com.atlassian.jira.plugin.... ]
Pedro Zapata Fernandez closed ISPN-7002.
----------------------------------------
Resolution: Out of Date
> NPE in DelegatingQuery.java:42 when deployed in Wildfly 10.1.0.Final
> --------------------------------------------------------------------
>
> Key: ISPN-7002
> URL: https://issues.jboss.org/browse/ISPN-7002
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.2.4.Final
> Environment: Fedora 24
> openjdk version "1.8.0_102"
> OpenJDK Runtime Environment (build 1.8.0_102-b14)
> OpenJDK 64-Bit Server VM (build 25.102-b14, mixed mode)
> Reporter: Pavol Loffay
> Assignee: Nistor Adrian
> Priority: Blocker
>
> Null pointer exception in DelegatingQuery.java:42 when using infinispan-query in cache managed by EmbeddedCacheManager injected from Wildfly 10.1.0.Final.
> Query executed on cache created from DefaultCacheManager defaultCacheManager = new DefaultCacheManager(); works fine.
> https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
> When cache is created from EmbeddedCacheManager injected from Wildfly 10.1.0.Final it throws following exception:
> https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
> Note that similar NPE exception is thrown for Wildfly 10.0.0.Final (infinispan 8.2.0.Final).
> Application source code: https://github.com/pavolloffay/infinispan-wildfly10
> Error for infinispan 8.2.0.Final in Wildfly 10.0.0.Final:
> {code:java}
> 15:29:25,025 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /stringContainer: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76)
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
> Caused by: java.lang.NullPointerException
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.parse(QueryEngine.java:629)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.buildQuery(QueryEngine.java:93)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.createQuery(DelegatingQuery.java:38)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:45)
> at sk.loffay.cache.StringCacheContainer.query(StringCacheContainer.java:53)
> at sk.loffay.rest.ContainerHandler.getContainer(ContainerHandler.java:43)
> at sk.loffay.rest.ContainerHandler$Proxy$_$$_WeldClientProxy.getContainer(Unknown Source)
> 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.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
> ... 32 more
> {code}
> Exception when updated to 8.2.4.Final and deployed to Wildfly 10.1.0.Final
> {code:java}
> 15:51:14,692 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /stringContainer: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77)
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> 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)
> Caused by: java.lang.NullPointerException
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.createQuery(DelegatingQuery.java:42)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:49)
> at sk.loffay.cache.StringCacheContainer.query(StringCacheContainer.java:53)
> at sk.loffay.rest.ContainerHandler.getContainer(ContainerHandler.java:43)
> at sk.loffay.rest.ContainerHandler$Proxy$_$$_WeldClientProxy.getContainer(Unknown Source)
> 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.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)
> ... 42 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-6881) Error when accessing REST root path
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-6881?page=com.atlassian.jira.plugin.... ]
Pedro Zapata Fernandez closed ISPN-6881.
----------------------------------------
Resolution: Out of Date
> Error when accessing REST root path
> -----------------------------------
>
> Key: ISPN-6881
> URL: https://issues.jboss.org/browse/ISPN-6881
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
> Priority: Minor
>
> When accessing REST root path (http://localhost:8080/rest/), it results into server error (moreover followed by NPE):
> {noformat}
> ESC[0mESC[31m12:27:19,104 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (nioEventLoopGroup-7-1) RESTEASY002010: Failed to execute: javax.ws.rs.NotFoundException: RESTEASY003210: Could not find resource for full path: http://localhost:8080/rest
> at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:114)
> at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:43)
> at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48)
> at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:445)
> at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:257)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:194)
> at org.jboss.resteasy.plugins.server.netty.RequestDispatcher.service(RequestDispatcher.java:83)
> at org.jboss.resteasy.plugins.server.netty.RequestHandler.channelRead0(RequestHandler.java:53)
> at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83)
> at io.netty.channel.DefaultChannelHandlerInvoker$7.run(DefaultChannelHandlerInvoker.java:159)
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:339)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:373)
> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:145)
> at java.lang.Thread.run(Thread.java:745)
> ESC[0mESC[31m12:27:19,107 SEVERE [org.jboss.resteasy.plugins.server.netty.RequestHandler] (nioEventLoopGroup-7-1) Unexpected: org.jboss.resteasy.spi.UnhandledException: java.lang.NumberFormatException: null
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:180)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:199)
> at org.jboss.resteasy.plugins.server.netty.RequestDispatcher.service(RequestDispatcher.java:83)
> at org.jboss.resteasy.plugins.server.netty.RequestHandler.channelRead0(RequestHandler.java:53)
> at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83)
> at io.netty.channel.DefaultChannelHandlerInvoker$7.run(DefaultChannelHandlerInvoker.java:159)
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:339)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:373)
> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:145)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NumberFormatException: null
> at java.lang.Long.parseLong(Long.java:552)
> at java.lang.Long.parseLong(Long.java:631)
> at org.infinispan.rest.logging.RestAccessLoggingHandler.filter(RestAccessLoggingHandler.java:36)
> at org.jboss.resteasy.core.ServerResponseWriter.executeFilters(ServerResponseWriter.java:121)
> at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:48)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:176)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10748) Rest endpoint is not able to reach a preconfigured cache
by Diego Lovison (Jira)
Diego Lovison created ISPN-10748:
------------------------------------
Summary: Rest endpoint is not able to reach a preconfigured cache
Key: ISPN-10748
URL: https://issues.jboss.org/browse/ISPN-10748
Project: Infinispan
Issue Type: Bug
Affects Versions: 10.0.0.CR3
Reporter: Diego Lovison
infinispan.xml
{code:xml}
<cache-container name="default">
<transport cluster="${infinispan.cluster.name}" stack="${infinispan.cluster.stack:tcp}"/>
<distributed-cache name="rest"/>
</cache-container>
{code}
{code:java}
public static void main(String[] args) throws IOException {
String key = "k1";
String value = "v1";
OkHttpClient client = new OkHttpClient();
String url = "http://%s:%s/rest/v2/caches/%s/%s";
//String url = "http://%s:%s/rest/%s/%s";
Request request = new Request.Builder()
.url(String.format(url, "localhost", 11222, "rest", key))
.put(RequestBody.create(TEXT_PLAIN, value))
.build();
Response response = client.newCall(request).execute();
assertEquals(200, response.code());
}
{code}
A few notes:
* When created via rest, it works.
* When using the v2 rest endpoint, it works.
* It is only failing with the legacy endpoint.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-6062) Remove megamorphic calls when calling next method in interceptor stack
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-6062?page=com.atlassian.jira.plugin.... ]
Pedro Zapata Fernandez closed ISPN-6062.
----------------------------------------
Resolution: Out of Date
> Remove megamorphic calls when calling next method in interceptor stack
> ----------------------------------------------------------------------
>
> Key: ISPN-6062
> URL: https://issues.jboss.org/browse/ISPN-6062
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 8.1.0.Final
> Reporter: Radim Vansa
> Priority: Major
>
> With current acceptor-visitor architecture of interceptor stack, calls to next interceptor use megamorphic interface calls. This is suboptimal as it prohibits the JIT compiler from inlining the calls.
> Since the interceptor stack is not changed very often, we may adapt the code programmatically to call next interceptor directly.
> The solution should verify that interceptor stack is inlined as much as possible with 'common' JVM options - increasing -XX:MaxInlineLevel is viable, while we should not request users to mess with -XX:DesiredMethodLimit. Preferably, -XX:FreqInlineSize and -XX:MaxInlineSize should stay at defaults.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-6062) Remove megamorphic calls when calling next method in interceptor stack
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-6062?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6062:
----------------------------------
Status: Open (was: Pull Request Sent)
> Remove megamorphic calls when calling next method in interceptor stack
> ----------------------------------------------------------------------
>
> Key: ISPN-6062
> URL: https://issues.jboss.org/browse/ISPN-6062
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 8.1.0.Final
> Reporter: Radim Vansa
> Priority: Major
>
> With current acceptor-visitor architecture of interceptor stack, calls to next interceptor use megamorphic interface calls. This is suboptimal as it prohibits the JIT compiler from inlining the calls.
> Since the interceptor stack is not changed very often, we may adapt the code programmatically to call next interceptor directly.
> The solution should verify that interceptor stack is inlined as much as possible with 'common' JVM options - increasing -XX:MaxInlineLevel is viable, while we should not request users to mess with -XX:DesiredMethodLimit. Preferably, -XX:FreqInlineSize and -XX:MaxInlineSize should stay at defaults.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-9571) Clustered tutorials should bind to localhost by default
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9571?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9571:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.4.16.Final
Resolution: Done
> Clustered tutorials should bind to localhost by default
> -------------------------------------------------------
>
> Key: ISPN-9571
> URL: https://issues.jboss.org/browse/ISPN-9571
> Project: Infinispan
> Issue Type: Task
> Components: Demos and Tutorials
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Major
> Fix For: 9.4.16.Final
>
>
> Clusters not forming is a typical error for beginners. Most often people start by trying to create a cluster in their own environments, e.g. server or laptop. So it'd make sense to add a java option that binds JGroups to 127.0.0.1.
> Users can always modify the variable to their node's external interface when trying to create clusters across multiple machines.
> Without this option, users have to know or look up the documentation to figure out how to do it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-1790) Release script should not rip off comments from POM.XML files
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-1790?page=com.atlassian.jira.plugin.... ]
Pedro Zapata Fernandez closed ISPN-1790.
----------------------------------------
Resolution: Out of Date
> Release script should not rip off comments from POM.XML files
> -------------------------------------------------------------
>
> Key: ISPN-1790
> URL: https://issues.jboss.org/browse/ISPN-1790
> Project: Infinispan
> Issue Type: Enhancement
> Components: Build
> Affects Versions: 5.1.0.FINAL
> Reporter: Sanne GRINOVERO
> Priority: Minor
> Labels: release.py
>
> Comparing the git commit which was used to release 5.1.0.Final to the final tag of the released version, reveals some changes which are likely unintended:
> * All Copyright statements removed
> * All comments removed (useful and unuseful)
> * In some way changed the inlined scripts for Google analytics - not sure if it's still working
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-5076) Pessimistic transactions can lose their locks when the primary owner changes
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-5076?page=com.atlassian.jira.plugin.... ]
Pedro Zapata Fernandez closed ISPN-5076.
----------------------------------------
Resolution: Out of Date
> Pessimistic transactions can lose their locks when the primary owner changes
> ----------------------------------------------------------------------------
>
> Key: ISPN-5076
> URL: https://issues.jboss.org/browse/ISPN-5076
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 7.0
>
> In a pessimistic cache, if a transaction {{T1}} has a {{put(k, v)}} operation and the primary owner of the key is the originator, the lock is acquired on the originator but it is not replicated to on the backup(s).
> If one of the backup owners becomes the primary owner, it will allow another transaction {{T2}} to lock (and update) key {{k}} before it receives the one-phase prepare command from the originator of {{T1}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months