Making -1 default for Hot Rod server idle timeout?
by Galder Zamarreno
Hi all,
I was reading this thread (http://community.jboss.org/message/543377#543377) and was wondering whether idle timeout for Hot Rod should by default be -1. As I explained in the past, this parameter is used to handle any misbehaving clients that might be sending incomplete requests. Without an idle timeout, we couldn't catch those rogue clients.
However, this shouldn't really be the norm. If there's any suspicion of such things going on, users could restart the server with a positive idle timeout and iron out any issues.
Besides, it's pretty clear that the majority of users will be using one of the existing Hot Rod clients and hence the likelihood of seeing such issues is low.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 4 months
Re: [infinispan-dev] ISPN-78 and Large Object Support/Streaming API
by galder＠jboss.org
----- "Manik Surtani" <manik(a)jboss.org> wrote:
> On 25 May 2010, at 07:30, Galder Zamarreno wrote:
>
> >
> > ----- "Manik Surtani" <manik(a)jboss.org> wrote:
> >
> >> On 20 May 2010, at 16:14, Galder Zamarreno wrote:
> >>
> >>> The following ties in a bit with my comment yesterday about
> return
> >> values:
> >>>
> >>> If these two methods would always return null, you'd never be
> able
> >> to find out whether a remove/replace worked on its own. Returning
> >> previous value would indeed not work, but you could still return a
> >> marker different to null.
> >>
> >> The problem with markers is typing. Returning a boolean, for
> example,
> >> would make a lot of sense. But returning anything else would in
> >> effect be used *as a boolean*. Using any other return type for
> this
> >> would be abuse of the type system.
> >
> > +1, a boolean would be enough.
>
> Right, but that in turn breaks the method signature of remove() and
> replace(), which return V. Hence my opting to return null and
> documenting as such.
Oh bugger, had forgotten of that and V is completely out of our control. Hmmm, that's a bummer.
>
> >
> >>
> >>
> >>>
> >>> V remove(K key); // except that this will always return a null
> >>> V replace(K key, V value); // except that this will always return
> a
> >> null
> >>>
> >>> So, if remove worked cos the key was present, a marker value
> would
> >> be returned, otherwise if the key was not present, null would be
> >> returned.
> >>>
> >>> Cheers,
> >>>
> >>> ----- "Manik Surtani" <manik(a)jboss.org> wrote:
> >>>
> >>>> I have put together a brief design for ISPN-78. Please take a
> >> look,
> >>>> it is on the wiki:
> >>>>
> >>>> https://community.jboss.org/wiki/LargeObjectSupport
> >>>>
> >>>> I have also deferred ISPN-78 to 5.0.0 rather than 4.1.0 as I'd
> >> rather
> >>>> not hold up 4.1.0 for new features at this stage.
> >>>>
> >>>> Please have a look at the designs and let me know what you think
> -
> >> or
> >>>> comment on the wiki page.
> >>>>
> >>>> Cheers
> >>>> Manik
> >>>> --
> >>>> Manik Surtani
> >>>> manik(a)jboss.org
> >>>> Lead, Infinispan
> >>>> Lead, JBoss Cache
> >>>> http://www.infinispan.org
> >>>> http://www.jbosscache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> infinispan-dev mailing list
> >>>> infinispan-dev(a)lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> infinispan-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >> --
> >> Manik Surtani
> >> manik(a)jboss.org
> >> Lead, Infinispan
> >> Lead, JBoss Cache
> >> http://www.infinispan.org
> >> http://www.jbosscache.org
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
15 years, 4 months
Regressions on trunk
by Vladimir Blagojevic
Hi,
I am running a clean svn checked out test suite run and I am getting about 8-10 failures consistently. Any ideas?
Failed tests:
testStartingUnknownCaches(org.infinispan.distribution.UnknownCacheStartTest)
testTransactional(org.infinispan.distribution.rehash.ConcurrentNonOverlappingLeaveTest)
testTransactional(org.infinispan.distribution.rehash.SingleLeaveTest)
testSequence2(org.infinispan.distribution.ConcurrentStartWithReplTest)
testReplicateToNonExistentCache(org.infinispan.replication.SyncReplTest)
testSTWithWritingTxThread(org.infinispan.statetransfer.StateTransferFunctionalTest)
testSTWithWritingTxThread(org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest)
testConcurrentStateTransfer(org.infinispan.statetransfer.StateTransferFileCacheLoaderFunctionalTest)
Tests run: 687, Failures: 8, Errors: 0, Skipped: 0
15 years, 4 months
Maven build problems with EC2 demo
by Noel OConnor
Hi,
I'm trying to fix the assembly stage of the EC2 demo and I'm hitting a brick
wall due to my limited maven knowledge.
The EC2 demo builds two artifacts, a JAR file containing the demo code and a
WAR file which is a basic UI.
Both compile fine but when it comes to assembly into the infinispan-all.zip
the jars that both of these depend on are not bundled in the modules/lib and
the war is just a renamed copy of the jar.
The correctly assembled war is present in the demo/ec2/target directory but
the war contained in infinispan-all.zip is just a renamed copy of the jar.
Has anybody got some time to take a look ?
cheers
Noel
15 years, 4 months
Infinispan GUI demo not building after maven repo changes
by galder＠redhat.com
Hi,
FAO jboss-dev list: Why wasn't apache-log4j/log4j group ported to new nexus repo? What are other projects depending on log4j 1.2.15 doing about this?
If you wipe your maven2 repo, you'll find that GUI demo does not build and this is related to the maven repo changes. Basically, the GUI demo depends on log4j 1.2.15 but we're not using the default one. Instead we're depending on http://repository.jboss.org/maven2/apache-log4j/log4j/1.2.15/
Now, the reason for that I suspect is the fact that if you depend on the standard log4j 1.2.15, you get dependency failures like this:
Missing:
----------
1) com.sun.jdmk:jmxtools:jar:1.2.1
Try downloading the file manually from:
http://java.sun.com/products/JavaManagement/download.html
Then, install it using the command:
mvn install:install-file -DgroupId=com.sun.jdmk -DartifactId=jmxtools -Dversion=1.2.1 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=com.sun.jdmk -DartifactId=jmxtools -Dversion=1.2.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.infinispan:infinispan-gui-demo:jar:4.1.0-SNAPSHOT
2) log4j:log4j:jar:1.2.15
3) com.sun.jdmk:jmxtools:jar:1.2.1
2) com.sun.jmx:jmxri:jar:1.2.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.sun.jmx -DartifactId=jmxri -Dversion=1.2.1 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=com.sun.jmx -DartifactId=jmxri -Dversion=1.2.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.infinispan:infinispan-gui-demo:jar:4.1.0-SNAPSHOT
2) log4j:log4j:jar:1.2.15
3) com.sun.jmx:jmxri:jar:1.2.1
----------
2 required artifacts are missing.
for artifact:
org.infinispan:infinispan-gui-demo:jar:4.1.0-SNAPSHOT
----------
As http://unitstep.net/blog/2009/05/18/resolving-log4j-1215-dependency-probl... explains, these appear to be optional dependencies that log4j should have set. Issues like this might explain why we ended up building and putting our own 1.2.15 version in the old repository.
The point is, what do we do about it? Any particular reason why the demo depends on version 1.2.15?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 4 months
Re: [infinispan-dev] REST server war deployment issues
by galder＠jboss.org
See below:
----- "Manik Surtani" <manik(a)jboss.org> wrote:
> On 21 May 2010, at 16:04, galder(a)redhat.com wrote:
>
> > Deploying rest server in Tomcat 6.0.26 throws the exception below.
> >
> > It seems like that it can't find slf4j-api jar. Michael, did you try
> the war with any particular tomcat versions?
> >
> > I managed to get around the issue by both removing the exclusion in
> the RESTEasy depends and adding slf4j-api and slf4j-simple
> dependencies.
>
> Ok - have you fixed the POM in trunk?
Not yet, I'll do that asap.
>
> > java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
> > at
> org.jboss.resteasy.plugins.server.servlet.ConfigurationBootstrap.<clinit>(ConfigurationBootstrap.java:27)
> > at
> org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap.contextInitialized(ResteasyBootstrap.java:26)
> > at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972)
> > at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4467)
> > at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
> > at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
> > at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:546)
> > at
> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:905)
> > at
> org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:740)
> > at
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:500)
> > at
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
> > at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
> > at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> > at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
> > at
> org.apache.catalina.core.StandardHost.start(StandardHost.java:785)
> > at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
> > at
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
> > at
> org.apache.catalina.core.StandardService.start(StandardService.java:519)
> > at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
> > at
> org.apache.catalina.startup.Catalina.start(Catalina.java:581)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> > at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:597)
> > at
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
> > at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
> > Caused by: java.lang.ClassNotFoundException:
> org.slf4j.LoggerFactory
> > at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1516)
> > at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1361)
> > at
> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398)
> > ... 26 more
> >
> > As a side note, deploying the original war I tried in a recent AS
> trunk fails with:
>
> Have you raised this on the AS mail list? Classloader isolation
> should take care of this.
No, I haven't. I'll do that asap.
>
> Also, should we be upgrading to RestEasy 2.0-beta-2?
No idea tbh. I'll try to upgrade and see what happens. Bill, should we be upgrading to 2.0-beta-2?
>
> >
> > 12:39:58,448 ERROR [[/infinispan-server-rest]] Exception starting
> filter Resteasy: java.lang.ClassCastException:
> org.jboss.resteasy.spi.ResteasyProviderFactory cannot be cast to
> org.jboss.resteasy.spi.ResteasyProviderFactory
> > at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:55)
> [:]
> > at
> org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.init(FilterDispatcher.java:39)
> [:]
> > at
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:462)
> [:]
> > at
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3286)
> [:]
> > at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:3887)
> [:]
> >
> > AS ships with a different version of RESTEasy library which would
> explain this issue (latest AS ships 2.0-beta-2 whereas the war
> includes 1.2.1.GA). However, AFAIR in the past WEB-INF/classes/lib was
> deployed under a different classloader and hence this shouldn't be a
> problem.
> >
> > I'll create a couple of JIRAs for these.
> >
> > Cheers,
> > --
> > Galder Zamarreño
> > Sr. Software Engineer
> > Infinispan, JBoss Cache
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
15 years, 4 months
R: Re: Removing dependencies from parent
by Sanne Grinovero
I'll be careful and propose a patch for review. I think it's worth to take
the risk better sooner than later ;) as I currently have to define several
exclusions in my app to prevent a jumbo package of unused jars.
Cheers,
Sanne
Il giorno 24/mag/2010 13:25, "Manik Surtani" <manik(a)jboss.org> ha scritto:
On 22 May 2010, at 09:40, Sanne Grinovero wrote:
> Hello,
> currently even to start a little Lucen...
Yeah I'm fine with this, but these deps are needed by core and all of the
other modules in turn depend on core.
>
> Regards,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
15 years, 4 months
thoughts on RemoteCacheStore
by Mircea Markus
Hi,
1. Do we want this to be a CacheStore or CacheLoader only? Looking at TcpDelegatingCacheLoader it also does puts, guess we want to preserve the same behaviour - or?
2. load/loadAll/loadAllKeys operations cannot be implemented (hotrod does not support getKeys, and even so that would potentially be too costly)
3. at chacheStore level we have InternalCacheEntry, whilst RemoteCache operates with the actual key/value operations. This means that (at least on get) the expiration information is lost.
cheers,
Mircea
15 years, 4 months
