[JBoss JIRA] (ISPN-5444) Filter/converters in server can't unmarshall custom cached classes
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5444?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5444:
-----------------------------------
Workaround Description: Manually put them the custom classes in a module and get org.infinispan.commons module to depend on this module. It requires restarting the server.
Workaround: Workaround Exists
> Filter/converters in server can't unmarshall custom cached classes
> ------------------------------------------------------------------
>
> Key: ISPN-5444
> URL: https://issues.jboss.org/browse/ISPN-5444
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.2.0.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.2.1.Final
>
>
> If a user deploys a filter/converter into server, and the cache contains custom classes, the default behaviour of unmarshalling custom classes for the filter/converter will generate CNFEs, e.g.
> {code}
> Caused by: java.lang.ClassNotFoundException: ValueAddedEvent from [Module
> "org.infinispan.commons:main" from local module loader @4b7504fb
> (finder: local module finder @6f9a2170 (roots:
> /opt/infinispan/modules,/opt/infinispan/modules/system/layers/base))]
> [..]
> at
> org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
> [infinispan-commons-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
> at
> org.infinispan.server.hotrod.ClientListenerRegistry$UnmarshallConverter.convert(ClientListenerRegistry.scala:383)
> [infinispan-server-hotrod-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
> {code}
> Even if the classes are deployed along with the filter/converter, these won't be found. Currently, the only way to workaround it is to add those classes into a module and get the infinispan-commons module to depend on it to locate them.
> A better solution is needed here...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (ISPN-5444) Filter/converters in server can't unmarshall custom cached classes
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5444?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño reassigned ISPN-5444:
--------------------------------------
Assignee: Galder Zamarreño
> Filter/converters in server can't unmarshall custom cached classes
> ------------------------------------------------------------------
>
> Key: ISPN-5444
> URL: https://issues.jboss.org/browse/ISPN-5444
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.2.0.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.2.1.Final
>
>
> If a user deploys a filter/converter into server, and the cache contains custom classes, the default behaviour of unmarshalling custom classes for the filter/converter will generate CNFEs, e.g.
> {code}
> Caused by: java.lang.ClassNotFoundException: ValueAddedEvent from [Module
> "org.infinispan.commons:main" from local module loader @4b7504fb
> (finder: local module finder @6f9a2170 (roots:
> /opt/infinispan/modules,/opt/infinispan/modules/system/layers/base))]
> [..]
> at
> org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
> [infinispan-commons-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
> at
> org.infinispan.server.hotrod.ClientListenerRegistry$UnmarshallConverter.convert(ClientListenerRegistry.scala:383)
> [infinispan-server-hotrod-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
> {code}
> Even if the classes are deployed along with the filter/converter, these won't be found. Currently, the only way to workaround it is to add those classes into a module and get the infinispan-commons module to depend on it to locate them.
> A better solution is needed here...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (ISPN-5444) Filter/converters in server can't unmarshall custom cached classes
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5444?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5444:
-----------------------------------
Fix Version/s: 7.2.1.Final
> Filter/converters in server can't unmarshall custom cached classes
> ------------------------------------------------------------------
>
> Key: ISPN-5444
> URL: https://issues.jboss.org/browse/ISPN-5444
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.2.0.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.2.1.Final
>
>
> If a user deploys a filter/converter into server, and the cache contains custom classes, the default behaviour of unmarshalling custom classes for the filter/converter will generate CNFEs, e.g.
> {code}
> Caused by: java.lang.ClassNotFoundException: ValueAddedEvent from [Module
> "org.infinispan.commons:main" from local module loader @4b7504fb
> (finder: local module finder @6f9a2170 (roots:
> /opt/infinispan/modules,/opt/infinispan/modules/system/layers/base))]
> [..]
> at
> org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
> [infinispan-commons-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
> at
> org.infinispan.server.hotrod.ClientListenerRegistry$UnmarshallConverter.convert(ClientListenerRegistry.scala:383)
> [infinispan-server-hotrod-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
> {code}
> Even if the classes are deployed along with the filter/converter, these won't be found. Currently, the only way to workaround it is to add those classes into a module and get the infinispan-commons module to depend on it to locate them.
> A better solution is needed here...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (ISPN-5444) Filter/converters in server can't unmarshall custom cached classes
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5444?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5444:
-----------------------------------
Summary: Filter/converters in server can't unmarshall custom cached classes (was: Improve handling of custom classes with deployed filter/converters in server)
Issue Type: Bug (was: Enhancement)
> Filter/converters in server can't unmarshall custom cached classes
> ------------------------------------------------------------------
>
> Key: ISPN-5444
> URL: https://issues.jboss.org/browse/ISPN-5444
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.2.0.Final
> Reporter: Galder Zamarreño
> Fix For: 7.2.1.Final
>
>
> If a user deploys a filter/converter into server, and the cache contains custom classes, the default behaviour of unmarshalling custom classes for the filter/converter will generate CNFEs, e.g.
> {code}
> Caused by: java.lang.ClassNotFoundException: ValueAddedEvent from [Module
> "org.infinispan.commons:main" from local module loader @4b7504fb
> (finder: local module finder @6f9a2170 (roots:
> /opt/infinispan/modules,/opt/infinispan/modules/system/layers/base))]
> [..]
> at
> org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
> [infinispan-commons-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
> at
> org.infinispan.server.hotrod.ClientListenerRegistry$UnmarshallConverter.convert(ClientListenerRegistry.scala:383)
> [infinispan-server-hotrod-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
> {code}
> Even if the classes are deployed along with the filter/converter, these won't be found. Currently, the only way to workaround it is to add those classes into a module and get the infinispan-commons module to depend on it to locate them.
> A better solution is needed here...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (ISPN-5444) Filter/converters in server can't unmarshall custom cached classes
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5444?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5444:
-----------------------------------
Affects Version/s: 7.2.0.Final
> Filter/converters in server can't unmarshall custom cached classes
> ------------------------------------------------------------------
>
> Key: ISPN-5444
> URL: https://issues.jboss.org/browse/ISPN-5444
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.2.0.Final
> Reporter: Galder Zamarreño
> Fix For: 7.2.1.Final
>
>
> If a user deploys a filter/converter into server, and the cache contains custom classes, the default behaviour of unmarshalling custom classes for the filter/converter will generate CNFEs, e.g.
> {code}
> Caused by: java.lang.ClassNotFoundException: ValueAddedEvent from [Module
> "org.infinispan.commons:main" from local module loader @4b7504fb
> (finder: local module finder @6f9a2170 (roots:
> /opt/infinispan/modules,/opt/infinispan/modules/system/layers/base))]
> [..]
> at
> org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
> [infinispan-commons-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
> at
> org.infinispan.server.hotrod.ClientListenerRegistry$UnmarshallConverter.convert(ClientListenerRegistry.scala:383)
> [infinispan-server-hotrod-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
> {code}
> Even if the classes are deployed along with the filter/converter, these won't be found. Currently, the only way to workaround it is to add those classes into a module and get the infinispan-commons module to depend on it to locate them.
> A better solution is needed here...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (ISPN-5444) Improve handling of custom classes with deployed filter/converters in server
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5444?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-5444:
----------------------------------------
In theory, if ValueAddedEvent is included in the filter/converter jar, it should work but user reported that it does not.
Had a quick chat with [~pferraro] and he said that if we add the following, Infinispan should be able to find the class and unmarshall it succesfully:
{code}
GlobalConfigurationBuilder.serialization().classResolver(ModularClassResolver.getInstance(moduleLoader));
{code}
> Improve handling of custom classes with deployed filter/converters in server
> ----------------------------------------------------------------------------
>
> Key: ISPN-5444
> URL: https://issues.jboss.org/browse/ISPN-5444
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
>
> If a user deploys a filter/converter into server, and the cache contains custom classes, the default behaviour of unmarshalling custom classes for the filter/converter will generate CNFEs, e.g.
> {code}
> Caused by: java.lang.ClassNotFoundException: ValueAddedEvent from [Module
> "org.infinispan.commons:main" from local module loader @4b7504fb
> (finder: local module finder @6f9a2170 (roots:
> /opt/infinispan/modules,/opt/infinispan/modules/system/layers/base))]
> [..]
> at
> org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
> [infinispan-commons-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
> at
> org.infinispan.server.hotrod.ClientListenerRegistry$UnmarshallConverter.convert(ClientListenerRegistry.scala:383)
> [infinispan-server-hotrod-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
> {code}
> Even if the classes are deployed along with the filter/converter, these won't be found. Currently, the only way to workaround it is to add those classes into a module and get the infinispan-commons module to depend on it to locate them.
> A better solution is needed here...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (ISPN-5444) Improve handling of custom classes with deployed filter/converters in server
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-5444:
--------------------------------------
Summary: Improve handling of custom classes with deployed filter/converters in server
Key: ISPN-5444
URL: https://issues.jboss.org/browse/ISPN-5444
Project: Infinispan
Issue Type: Enhancement
Reporter: Galder Zamarreño
If a user deploys a filter/converter into server, and the cache contains custom classes, the default behaviour of unmarshalling custom classes for the filter/converter will generate CNFEs, e.g.
{code}
Caused by: java.lang.ClassNotFoundException: ValueAddedEvent from [Module
"org.infinispan.commons:main" from local module loader @4b7504fb
(finder: local module finder @6f9a2170 (roots:
/opt/infinispan/modules,/opt/infinispan/modules/system/layers/base))]
[..]
at
org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
[infinispan-commons-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
at
org.infinispan.server.hotrod.ClientListenerRegistry$UnmarshallConverter.convert(ClientListenerRegistry.scala:383)
[infinispan-server-hotrod-7.2.0-SNAPSHOT.jar:7.2.0-SNAPSHOT]
{code}
Even if the classes are deployed along with the filter/converter, these won't be found. Currently, the only way to workaround it is to add those classes into a module and get the infinispan-commons module to depend on it to locate them.
A better solution is needed here...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (ISPN-5317) BlockingTaskAwareExecutorService.cherkForReadyTasks() may block CacheTopologyControlCommand
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5317?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-5317:
------------------------------
Status: Resolved (was: Pull Request Sent)
Assignee: Dan Berindei (was: Pedro Ruivo)
Fix Version/s: 8.0.0.Alpha1
Resolution: Done
> BlockingTaskAwareExecutorService.cherkForReadyTasks() may block CacheTopologyControlCommand
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-5317
> URL: https://issues.jboss.org/browse/ISPN-5317
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.2.0.Beta1, 7.1.1.Final
> Reporter: Pedro Ruivo
> Assignee: Dan Berindei
> Fix For: 8.0.0.Alpha1
>
>
> Current implementation, checkForReadyTasks() is invoked in the StateConsumer after the topology is updated.
> If the remote-thread-pool is full (i.e. no more threads available), the checkForReadyTasks() will start processing commands in the invoker thread. If it happens, the CacheTopologyControlCommand has not done processing and the cache topology updated is delayed.
> It may cause some problems!
> The solution, it would be to invoke the checkForReadyTasks() in the StateTransferManager, after the StateConsumer and StateProvider had finished they work.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (ISPN-5420) Thread pools are depleted by ClusterTopologyManagerImpl.waitForView() and causing deadlock
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5420?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-5420:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Thread pools are depleted by ClusterTopologyManagerImpl.waitForView() and causing deadlock
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-5420
> URL: https://issues.jboss.org/browse/ISPN-5420
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final, 7.1.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 8.0.0.Final
>
>
> The join process was designed in the idea that a node would start its caches in sequential order, so {{ClusterTopologyManager.waitForView()}} would block at most once for each joining node. However, WildFly actually starts {{2 * Runtime.availableProcessors()}} caches in parallel, and this can be a problem when the machine has a lot of cores and multiple nodes.
> {{ClustertopologyManager.handleClusterView()}} only updates the {{viewId}} after it updated the cache topologies of each cache AND after it confirmed the availability of all the nodes with a {{POLICY_GET_STATUS}} RPC. This RPC can block, and it's very easy for the remote-executor thread pool on the coordinator to become overloades with threads like this:
> {noformat}
> "remote-thread-172" daemon prio=10 tid=0x00007f0cc48c0000 nid=0x28ca4 in Object.wait() [0x00007f0c5f25b000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at org.infinispan.topology.ClusterTopologyManagerImpl.waitForView(ClusterTopologyManagerImpl.java:357)
> - locked <0x00000000ff3bd900> (a java.lang.Object)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleJoin(ClusterTopologyManagerImpl.java:123)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:162)
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:144)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$4.run(CommandAwareRpcDispatcher.java:276)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (ISPN-5317) BlockingTaskAwareExecutorService.cherkForReadyTasks() may block CacheTopologyControlCommand
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5317?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-5317:
------------------------------
Status: Open (was: New)
> BlockingTaskAwareExecutorService.cherkForReadyTasks() may block CacheTopologyControlCommand
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-5317
> URL: https://issues.jboss.org/browse/ISPN-5317
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.2.0.Beta1, 7.1.1.Final
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
>
> Current implementation, checkForReadyTasks() is invoked in the StateConsumer after the topology is updated.
> If the remote-thread-pool is full (i.e. no more threads available), the checkForReadyTasks() will start processing commands in the invoker thread. If it happens, the CacheTopologyControlCommand has not done processing and the cache topology updated is delayed.
> It may cause some problems!
> The solution, it would be to invoke the checkForReadyTasks() in the StateTransferManager, after the StateConsumer and StateProvider had finished they work.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months