[JBoss JIRA] (ISPN-10435) Support for serving the console
by Gustavo Fernandes (Jira)
[ https://issues.jboss.org/browse/ISPN-10435?page=com.atlassian.jira.plugin... ]
Gustavo Fernandes updated ISPN-10435:
-------------------------------------
Description: The REST endpoint should be able to serve the console from a static folder, respecting usual http headers sent by browsers to facilitate caching such as if-modified-since (was: The REST endpoint should be able to serve the console from a static folder)
> Support for serving the console
> -------------------------------
>
> Key: ISPN-10435
> URL: https://issues.jboss.org/browse/ISPN-10435
> Project: Infinispan
> Issue Type: Feature Request
> Components: REST
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
> Labels: console-ng
>
> The REST endpoint should be able to serve the console from a static folder, respecting usual http headers sent by browsers to facilitate caching such as if-modified-since
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 8 months
[JBoss JIRA] (ISPN-9425) HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation
by Pedro Ruivo (Jira)
[ https://issues.jboss.org/browse/ISPN-9425?page=com.atlassian.jira.plugin.... ]
Work on ISPN-9425 started by Pedro Ruivo.
-----------------------------------------
> HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-9425
> URL: https://issues.jboss.org/browse/ISPN-9425
> Project: Infinispan
> Issue Type: Bug
> Reporter: Diego Lovison
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 10.0.0.Final
>
>
> There are 3 scenarios and I believe that they are correlated. If it is not the case, a JIRA for each item should be open.
> All scenarios below are multiple clients and one server. The following steps should be executed does not matter what is the scenario.
> * Add one breakpoint at the first line of the method `acceptResponse` at the class PrepareTransactionOperation
> * Add one breakpoint at the first line of the method `executeOperation` at the class PrepareTransactionOperation
> *Scenario 1*
> * Execute the client code ( Program 1 )
> * Execute the client code ( Program 2 )
> * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`.
> * Program 2 -> Resume, Resume. It will stop at `executeOperation`.
> * Wait 5 minutes or any time greater than 60 seconds ( I was not able to identify the right period of time but greater than 60 seconds should work), Resume and Resume the "Program 2". It will fail.
> * The issue in scenario 1 is: Why doesn't matter the amount of time since it is greater than 60 seconds the request will fail? I am expecting something like a timeout in the "Program 1" and not expire when a call in that key was called for the first time.
> * Kill all clients and servers
> *Scenario 2*
> * Execute the client code ( Program 1 )
> * Execute the client code ( Program 2 )
> * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`.
> * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume.
> * Program 1 -> Resume.
> * The issue in scenario 2 is: Why the test fails due: expected value 'null' different from 'random-value-generated'
> * Kill all clients and servers
> *Scenario 3*
> * Execute the client code ( Program 1 )
> * Execute the client code ( Program 2 )
> * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`.
> * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume.
> * Wait 60 seconds
> * Re-run Program 2 -> Resume, Resume, Resume, Resume. It will work.
> * Program 1 -> Resume, it will fail due to an assertion error
> * The issue in scenario 3 is: When resuming the "Program 1" I am expecting an error during the commit phase and not an assertion error.
> * Kill all clients and servers
> Program 1 means that you should run the client code. It will create a separated JVM.
> Program 2 means that you should run the client code. It will create a separated JVM.
> It will be nice if we find out an way to automate this kind of tests.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 8 months
[JBoss JIRA] (ISPN-9425) HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation
by Pedro Ruivo (Jira)
[ https://issues.jboss.org/browse/ISPN-9425?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-9425:
------------------------------
Status: Open (was: New)
> HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-9425
> URL: https://issues.jboss.org/browse/ISPN-9425
> Project: Infinispan
> Issue Type: Bug
> Reporter: Diego Lovison
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 10.0.0.Final
>
>
> There are 3 scenarios and I believe that they are correlated. If it is not the case, a JIRA for each item should be open.
> All scenarios below are multiple clients and one server. The following steps should be executed does not matter what is the scenario.
> * Add one breakpoint at the first line of the method `acceptResponse` at the class PrepareTransactionOperation
> * Add one breakpoint at the first line of the method `executeOperation` at the class PrepareTransactionOperation
> *Scenario 1*
> * Execute the client code ( Program 1 )
> * Execute the client code ( Program 2 )
> * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`.
> * Program 2 -> Resume, Resume. It will stop at `executeOperation`.
> * Wait 5 minutes or any time greater than 60 seconds ( I was not able to identify the right period of time but greater than 60 seconds should work), Resume and Resume the "Program 2". It will fail.
> * The issue in scenario 1 is: Why doesn't matter the amount of time since it is greater than 60 seconds the request will fail? I am expecting something like a timeout in the "Program 1" and not expire when a call in that key was called for the first time.
> * Kill all clients and servers
> *Scenario 2*
> * Execute the client code ( Program 1 )
> * Execute the client code ( Program 2 )
> * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`.
> * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume.
> * Program 1 -> Resume.
> * The issue in scenario 2 is: Why the test fails due: expected value 'null' different from 'random-value-generated'
> * Kill all clients and servers
> *Scenario 3*
> * Execute the client code ( Program 1 )
> * Execute the client code ( Program 2 )
> * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`.
> * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume.
> * Wait 60 seconds
> * Re-run Program 2 -> Resume, Resume, Resume, Resume. It will work.
> * Program 1 -> Resume, it will fail due to an assertion error
> * The issue in scenario 3 is: When resuming the "Program 1" I am expecting an error during the commit phase and not an assertion error.
> * Kill all clients and servers
> Program 1 means that you should run the client code. It will create a separated JVM.
> Program 2 means that you should run the client code. It will create a separated JVM.
> It will be nice if we find out an way to automate this kind of tests.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 8 months
[JBoss JIRA] (ISPN-9425) HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation
by Pedro Ruivo (Jira)
[ https://issues.jboss.org/browse/ISPN-9425?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-9425:
------------------------------
Fix Version/s: 10.0.0.Final
> HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-9425
> URL: https://issues.jboss.org/browse/ISPN-9425
> Project: Infinispan
> Issue Type: Bug
> Reporter: Diego Lovison
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 10.0.0.Final
>
>
> There are 3 scenarios and I believe that they are correlated. If it is not the case, a JIRA for each item should be open.
> All scenarios below are multiple clients and one server. The following steps should be executed does not matter what is the scenario.
> * Add one breakpoint at the first line of the method `acceptResponse` at the class PrepareTransactionOperation
> * Add one breakpoint at the first line of the method `executeOperation` at the class PrepareTransactionOperation
> *Scenario 1*
> * Execute the client code ( Program 1 )
> * Execute the client code ( Program 2 )
> * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`.
> * Program 2 -> Resume, Resume. It will stop at `executeOperation`.
> * Wait 5 minutes or any time greater than 60 seconds ( I was not able to identify the right period of time but greater than 60 seconds should work), Resume and Resume the "Program 2". It will fail.
> * The issue in scenario 1 is: Why doesn't matter the amount of time since it is greater than 60 seconds the request will fail? I am expecting something like a timeout in the "Program 1" and not expire when a call in that key was called for the first time.
> * Kill all clients and servers
> *Scenario 2*
> * Execute the client code ( Program 1 )
> * Execute the client code ( Program 2 )
> * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`.
> * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume.
> * Program 1 -> Resume.
> * The issue in scenario 2 is: Why the test fails due: expected value 'null' different from 'random-value-generated'
> * Kill all clients and servers
> *Scenario 3*
> * Execute the client code ( Program 1 )
> * Execute the client code ( Program 2 )
> * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`.
> * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume.
> * Wait 60 seconds
> * Re-run Program 2 -> Resume, Resume, Resume, Resume. It will work.
> * Program 1 -> Resume, it will fail due to an assertion error
> * The issue in scenario 3 is: When resuming the "Program 1" I am expecting an error during the commit phase and not an assertion error.
> * Kill all clients and servers
> Program 1 means that you should run the client code. It will create a separated JVM.
> Program 2 means that you should run the client code. It will create a separated JVM.
> It will be nice if we find out an way to automate this kind of tests.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 8 months
[JBoss JIRA] (ISPN-10538) Caused by: org.infinispan.commons.CacheException: ISPN000332: Remote transaction GlobalTransaction:<InfinispanNode-2277>:5936:remote rolled back because originator is no longer in the cluster
by Zhang Lijia (Jira)
[ https://issues.jboss.org/browse/ISPN-10538?page=com.atlassian.jira.plugin... ]
Zhang Lijia commented on ISPN-10538:
------------------------------------
Could you let me know why this unlock is happening, while give the response
Unlocking lock instance for key operation-228.2710463008511921082.com.nsn.oss.mediation.south.ne3soapcm-228.2710463008511921082.com.nsn.oss.mediation.south.ne3soapcm
and cause
remote rolled back because originator is no longer in the cluster
> Caused by: org.infinispan.commons.CacheException: ISPN000332: Remote transaction GlobalTransaction:<InfinispanNode-2277>:5936:remote rolled back because originator is no longer in the cluster
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-10538
> URL: https://issues.jboss.org/browse/ISPN-10538
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Affects Versions: 7.2.5.Final
> Environment: Some times at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:256) ~[infinispan-core.jar:7.2.5.Final] is failed
> Caused by: org.infinispan.commons.CacheException: ISPN000332: Remote transaction GlobalTransaction:<InfinispanNode-2277>:5936:remote rolled back because originator is no longer in the cluster
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:181) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:125) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:123) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:123) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:123) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:123) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:123) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.commands.tx.PrepareCommand.perform(PrepareCommand.java:113) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:85) ~[infinispan-core.jar:7.2.5.Final]
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:32) ~[infinispan-core.jar:7.2.5.Final]
> Reporter: Zhang Lijia
> Priority: Major
> Attachments: oss_activity0_0.log_node14, oss_activity0_0.log_node15, oss_trace0_0.log_node14, oss_trace0_0.log_node15
>
>
> We have two node some times put is failed while some times put is successful. It happens occasionally.
> The response from other site
> 2019-08-29-T09:23:23.701+0300 | srnclab18node14 | | OOB-1,InfinispanNode-57675 | TRACE | org.jgroups.protocols.UDP | InfinispanNode-57675: received [dst: InfinispanNode-57675, src: InfinispanNode-2277 (2 headers), size=201 bytes, flags=OOB|DONT_BUNDLE|NO_TOTAL_ORDER], headers are RequestCorrelator: id=200, type=REQ, id=14874, rsp_expected=true, UDP: [cluster_name=InfinispanCluster-common_mediations]
> 2019-08-29-T09:23:23.702+0300 | srnclab18node14 | | OOB-1,InfinispanNode-57675 | TRACE | org.jgroups.blocks.RequestCorrelator | calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 14874
> 2019-08-29-T09:23:23.702+0300 | srnclab18node14 | | OOB-1,InfinispanNode-57675 | TRACE | org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl | Added a new task: 0 task(s) are waiting
> 2019-08-29-T09:23:23.702+0300 | srnclab18node14 | | remote-thread-InfinispanNode-p3-t1241 | TRACE | org.infinispan.interceptors.locking.PessimisticLockingInterceptor | Locking key operation-228.2710463008511921082.com.nsn.oss.mediation.south.ne3soapcm-228.2710463008511921082.com.nsn.oss.mediation.south.ne3soapcm, no need to check for pending locks.
> 2019-08-29-T09:23:23.702+0300 | srnclab18node14 | | remote-thread-InfinispanNode-p3-t1241 | TRACE | org.infinispan.util.concurrent.locks.containers.OwnableReentrantPerEntryLockContainer | Creating and acquiring new lock instance for key operation-228.2710463008511921082.com.nsn.oss.mediation.south.ne3soapcm-228.2710463008511921082.com.nsn.oss.mediation.south.ne3soapcm
> 2019-08-29-T09:23:23.702+0300 | srnclab18node14 | | remote-thread-InfinispanNode-p3-t1241 | TRACE | org.infinispan.util.concurrent.locks.containers.OwnableReentrantPerEntryLockContainer | Unlocking lock instance for key operation-228.2710463008511921082.com.nsn.oss.mediation.south.ne3soapcm-228.2710463008511921082.com.nsn.oss.mediation.south.ne3soapcm
> 2019-08-29-T09:23:23.703+0300 | srnclab18node14 | | remote-thread-InfinispanNode-p3-t1241 | TRACE | org.jgroups.blocks.RequestCorrelator | sending rsp for 14874 to InfinispanNode-2277
> while for the successful one
> 2019-08-29-T08:47:47.555+0300 | srnclab18node14 | | OOB-1,InfinispanNode-57675 | TRACE | org.jgroups.blocks.RequestCorrelator | calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 14777
> 2019-08-29-T08:47:47.691+0300 | srnclab18node14 | | remote-thread-InfinispanNode-p3-t1237 | TRACE | org.infinispan.interceptors.locking.PessimisticLockingInterceptor | Locking key operation-224.-8971956864618055540.com.nsn.oss.mediation.south.ne3soapcm-224.-8971956864618055540.com.nsn.oss.mediation.south.ne3soapcm, no need to check for pending locks.
> 2019-08-29-T08:47:47.691+0300 | srnclab18node14 | | remote-thread-InfinispanNode-p3-t1237 | TRACE | org.infinispan.util.concurrent.locks.containers.OwnableReentrantPerEntryLockContainer | Creating and acquiring new lock instance for key operation-224.-8971956864618055540.com.nsn.oss.mediation.south.ne3soapcm-224.-8971956864618055540.com.nsn.oss.mediation.south.ne3soapcm
> 2019-08-29-T08:47:47.691+0300 | srnclab18node14 | | remote-thread-InfinispanNode-p3-t1237 | TRACE | org.jgroups.blocks.RequestCorrelator | sending rsp for 14777 to InfinispanNode-2277
> 2019-08-29-T08:47:47.691+0300 | srnclab18node14 | | remote-thread-InfinispanNode-p3-t1237 | TRACE | org.jgroups.protocols.UDP | InfinispanNode-57675: sending msg to InfinispanNode-2277, src=InfinispanNode-57675, headers are RequestCorrelator: id=200, type=RSP, id=14777, rsp_expected=false, UDP: [cluster_name=InfinispanCluster-common_mediations]
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 8 months