June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3190) Memcached server throwing NullPointerException if the mashaller is not explicitly set

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3190?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3190: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.3.0.CR2 (was: 5.3.0.Final) Resolution: Done > Memcached server throwing NullPointerException if the mashaller is not explicitly set > ------------------------------------------------------------------------------------- > > Key: ISPN-3190 > URL: https://issues.jboss.org/browse/ISPN-3190 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.CR1 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 5.3.0.CR2 > > > According to the tutorial at https://docs.jboss.org/author/display/ISPN/Interoperability+between+Embed... it is not necessary to specify a special marshaller under normal circumstances. However, the Memcached server seems to require it in any case and the Memcached client's "get" operation fails because we did not set any marshaller for the compatibility mode and it remained null. Note that I'm not using SpyMemcached. > My understanding is that even if I use SpyMemcached to retrieve the entry, it will be found and retrieved but without the marshaller I simply won't understand the returned value. But something will be returned. Is my assumption correct? > {code} > 2013-06-05 14:12:19,054 TRACE (MemcachedServerWorker-6) [org.infinispan.container.EntryFactoryImpl] Retrieved from container ImmortalCacheEntry{key=4, value=MetadataImmortalCacheValue {value=v1, metadata=EmbeddedMetadata{lifespan=-1, maxIdle=-1, version=ServerEntryVersion(1)}}} > 2013-06-05 14:12:19,054 TRACE (MemcachedServerWorker-6) [org.infinispan.interceptors.CallInterceptor] Executing command: GetKeyValueCommand {key=4, flags=[OPERATION_MEMCACHED]}. > 2013-06-05 14:12:19,054 TRACE (MemcachedServerWorker-6) [org.infinispan.commands.read.GetKeyValueCommand] Found entry ImmortalCacheEntry{key=4, value=MetadataImmortalCacheValue {value=v1, metadata=EmbeddedMetadata{lifespan=-1, maxIdle=-1, version=ServerEntryVersion(1)}}} > 2013-06-05 14:12:19,055 ERROR (MemcachedServerWorker-6) [org.infinispan.interceptors.InvocationContextInterceptor] ISPN000136: Execution error > java.lang.NullPointerException > at org.infinispan.server.memcached.MemcachedTypeConverter.marshall(MemcachedTypeConverter.scala:58) > at org.infinispan.server.memcached.MemcachedTypeConverter.unboxValue(MemcachedTypeConverter.scala:45) > at org.infinispan.server.memcached.MemcachedTypeConverter.unboxValue(MemcachedTypeConverter.scala:37) > at org.infinispan.interceptors.compat.TypeConverterInterceptor.visitGetKeyValueCommand(TypeConverterInterceptor.java:93) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:62) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:96) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:62) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343) > at org.infinispan.CacheImpl.getCacheEntry(CacheImpl.java:399) > at org.infinispan.DecoratedCache.getCacheEntry(DecoratedCache.java:514) > at org.infinispan.server.memcached.MemcachedDecoder.get(MemcachedDecoder.scala:122) > at org.infinispan.server.core.AbstractProtocolDecoder.decodeKey(AbstractProtocolDecoder.scala:121) > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:75) > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:49) > at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500) > at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) > at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:385) > at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) > at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107) > at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312) > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88) > at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) > at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) > at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3039) Add JCache quickstarts

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3039?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3039: ---------------------------------------- Things are still in-flux, as shown by ISPN-3213, so moving this forward. > Add JCache quickstarts > ---------------------- > > Key: ISPN-3039 > URL: https://issues.jboss.org/browse/ISPN-3039 > Project: Infinispan > Issue Type: Task > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > Quickstarts should be added to https://github.com/infinispan/infinispan-quickstart so that users can get started quickly with JCache API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3039) Add JCache quickstarts

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3039?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3039: ----------------------------------- Fix Version/s: 6.0.0.Final (was: 5.3.0.Final) > Add JCache quickstarts > ---------------------- > > Key: ISPN-3039 > URL: https://issues.jboss.org/browse/ISPN-3039 > Project: Infinispan > Issue Type: Task > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.0.0.Final > > > Quickstarts should be added to https://github.com/infinispan/infinispan-quickstart so that users can get started quickly with JCache API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2854) REST server discards Content Encoding information from client

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2854?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2854: ----------------------------------- Assignee: (was: Galder Zamarreño) > REST server discards Content Encoding information from client > ------------------------------------------------------------- > > Key: ISPN-2854 > URL: https://issues.jboss.org/browse/ISPN-2854 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.2.Final > Reporter: Tristan Tarrant > Fix For: 6.1.0.Final > > > The REST server discards the Content-Encoding header from the client and therefore does not serve it back when the content is being read, possibly causing misinterpretation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2820) POST request with multipart/form-data encoding stores wrong content type

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2820?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2820: ---------------------------------------- [~dan.berindei], not sure how this should be handled, and it'd argue that it might be a new feature... so moving it to 6.0. > POST request with multipart/form-data encoding stores wrong content type > ------------------------------------------------------------------------ > > Key: ISPN-2820 > URL: https://issues.jboss.org/browse/ISPN-2820 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.1.Final > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > The REST server uses the {{Content-Type}} header of the POST request to determine the content type of the stored entry. But with {{Content-Type: multipart/form-data}}, each parameter can have its own content type (and {{multipart/form-data}} is definitely not any parameter's content type). > This seems to be the way to do get the content type of each parameter: http://www.mkyong.com/webservices/jax-rs/file-upload-example-in-resteasy/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2854) REST server discards Content Encoding information from client

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2854?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2854: ----------------------------------- Fix Version/s: 6.1.0.Final (was: 5.3.0.Final) > REST server discards Content Encoding information from client > ------------------------------------------------------------- > > Key: ISPN-2854 > URL: https://issues.jboss.org/browse/ISPN-2854 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.2.Final > Reporter: Tristan Tarrant > Assignee: Galder Zamarreño > Fix For: 6.1.0.Final > > > The REST server discards the Content-Encoding header from the client and therefore does not serve it back when the content is being read, possibly causing misinterpretation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2820) POST request with multipart/form-data encoding stores wrong content type

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2820?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2820: ----------------------------------- Fix Version/s: 6.1.0.Final (was: 5.3.0.Final) > POST request with multipart/form-data encoding stores wrong content type > ------------------------------------------------------------------------ > > Key: ISPN-2820 > URL: https://issues.jboss.org/browse/ISPN-2820 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.1.Final > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Fix For: 6.1.0.Final > > > The REST server uses the {{Content-Type}} header of the POST request to determine the content type of the stored entry. But with {{Content-Type: multipart/form-data}}, each parameter can have its own content type (and {{multipart/form-data}} is definitely not any parameter's content type). > This seems to be the way to do get the content type of each parameter: http://www.mkyong.com/webservices/jax-rs/file-upload-example-in-resteasy/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2820) POST request with multipart/form-data encoding stores wrong content type

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2820?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2820: ----------------------------------- Assignee: (was: Galder Zamarreño) > POST request with multipart/form-data encoding stores wrong content type > ------------------------------------------------------------------------ > > Key: ISPN-2820 > URL: https://issues.jboss.org/browse/ISPN-2820 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.1.Final > Reporter: Dan Berindei > Fix For: 6.1.0.Final > > > The REST server uses the {{Content-Type}} header of the POST request to determine the content type of the stored entry. But with {{Content-Type: multipart/form-data}}, each parameter can have its own content type (and {{multipart/form-data}} is definitely not any parameter's content type). > This seems to be the way to do get the content type of each parameter: http://www.mkyong.com/webservices/jax-rs/file-upload-example-in-resteasy/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2854) REST server discards Content Encoding information from client

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2854?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2854: ---------------------------------------- [~NadirX], do you have a test for this? How critical is it really? Moving it to 6.0... > REST server discards Content Encoding information from client > ------------------------------------------------------------- > > Key: ISPN-2854 > URL: https://issues.jboss.org/browse/ISPN-2854 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.2.Final > Reporter: Tristan Tarrant > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > The REST server discards the Content-Encoding header from the client and therefore does not serve it back when the content is being read, possibly causing misinterpretation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3224) RemoteCacheManager of HotRod client is not able connect to server because of wrong parsing IPv6 address for pure IPv6 machines and gets wrong address on dual stack machines

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3224?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3224: ----------------------------------- Fix Version/s: 5.3.0.Final > RemoteCacheManager of HotRod client is not able connect to server because of wrong parsing IPv6 address for pure IPv6 machines and gets wrong address on dual stack machines > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3224 > URL: https://issues.jboss.org/browse/ISPN-3224 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.4.Final > Reporter: Vitalii Chepeliuk > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 5.3.0.Final > > > ########################Run hotrod client with pure IPv6############################################# > Hotrod client fails when want connect to server, below is exception from pure IPv6 machines it doesn't really undedstand IPv6 address it should connect."Could not connect to server: /0.0.10.60:52" Here should > be IPv6 address but it looks like some wrong IPv4 address it want to connect to and I use complicated address 2620:52:0:105f:0:0:ffff:32%2:11222 as host variable and it is not specified in /etc/hosts > public RemoteCacheManager(String host, int port, boolean start, ClassLoader classLoader) { > config = new ConfigurationProperties(host + ":" + port); <<< host=2620:52:0:105f:0:0:ffff:32%2 and port=11222 > this.classLoader = classLoader; > if (start) start(); > } > > then in start method > @Override > public void start() { > // Workaround for JDK6 NPE: http://bugs.sun.com/view_bug.do?bug_id=6427854 > SysPropertyActions.setProperty("sun.nio.ch.bugLevel", "\"\""); > forceReturnValueDefault = config.getForceReturnValues(); > codec = CodecFactory.getCodec(config.getProtocolVersion()); > String factory = config.getTransportFactory(); > transportFactory = (TransportFactory) getInstance(factory, classLoader); > Collection<SocketAddress> servers = config.getServerList(); <<< we get list of servers but getServerList() method should be improved see below! > > transportFactory.start(codec, config, servers, topologyId, classLoader); <<< and pass to transportFactory > if (marshaller == null) { > String marshallerName = config.getMarshaller(); > setMarshaller((Marshaller) getInstance(marshallerName, classLoader)); > } > if (asyncExecutorService == null) { > String asyncExecutorClass = config.getAsyncExecutorFactory(); > ExecutorFactory executorFactory = (ExecutorFactory) getInstance(asyncExecutorClass, classLoader); > asyncExecutorService = executorFactory.getExecutor(config.getProperties()); > } > synchronized (cacheName2RemoteCache) { > for (RemoteCacheHolder rcc : cacheName2RemoteCache.values()) { > startRemoteCache(rcc); > } > } > // Print version to help figure client version run > log.version(org.infinispan.Version.printVersion()); > started = true; > } > > and "servers" variable contain the same IP address 2620:52:0:105f:0:0:ffff:32%2:11222 > public Collection<SocketAddress> getServerList() { > Set<SocketAddress> addresses = new HashSet<SocketAddress>(); > String servers = props.getProperty(SERVER_LIST, "127.0.0.1:" + DEFAULT_HOTROD_PORT); <<< got 2620:52:0:105f:0:0:ffff:32%2:11222 > for (String server : servers.split(";")) { > String[] components = server.trim().split(":"); <<< just only here the splitting it wrong, we devide address into 9 chunks > String host = components[0]; <<< host name shoud be 1 chunk 2620 > int port = DEFAULT_HOTROD_PORT; > if (components.length > 1) port = Integer.parseInt(components[1]); <<< and port 52 > addresses.add(new InetSocketAddress(host, port)); <<< and again we pass wrong parameteres to this constructor with IntetSocketAddress(2620, 52) > } > if (addresses.isEmpty()) throw new IllegalStateException("No Hot Rod servers specified!"); > return addresses; << here we just get some strange IPv4 address as 0.0.10.60:52 > } > and exception is the following > Caused by: org.infinispan.client.hotrod.exceptions.TransportException:: Could not connect to server: /0.0.10.60:52 > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:88) > at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:57) > at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:38) > at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:271) > ########################Other issue is when hotrod client connects in dual stack mode################# > /etc/hosts file is--------------------------------------------------------- > 127.0.0.1 myhost localhost.localdomain localhost > ::1 myhost localhost6.localdomain6 localhost6 > --------------------------------------------------------------------------- > Then is the same problem in ConfigurationProperties.java getServerList() method we add address to addresses <<<addresses.add(new InetSocketAddress(host, port));>>> > so InetSocketAddress constructor is called > public InetSocketAddress(String hostname, int port) { > checkHost(hostname); > InetAddress addr = null; > String host = null; > try { > addr = InetAddress.getByName(hostname); <<< we should get InetAddress with hostname > } catch(UnknownHostException e) { > host = hostname; > } > holder = new InetSocketAddressHolder(host, addr, checkPort( > } > but we have 2! different inet addresses with the same hostname one is 127.0.0.1 and other ::1 and if i run it on IPv6 there should be ::1 and not 127.0.0.1! > And > public static InetAddress getByName(String host) > throws UnknownHostException { > return InetAddress.getAllByName(host)[0]; <<< but here we get only first address in array and got always 127.0.0.1 > } > and then other exception is thrown-------------------------------------- > Caused by: org.infinispan.client.hotrod.exceptions.TransportException:: Could not connect to server: vchepQA/127.0.0.1:11222 > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:88) > at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:57) > at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:38) > at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:271) > ... 97 more > --------------------------------------------------------------------------- > and i forget to add trace log just download it here http://dropmefiles.com/en/H5wvu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2013