I am new to lagom scala. Created a simple crud to learn the key concept of it. First I compiled my code using sbt clean compile and it successfully compiled the code.
After that I tried to run the project using sbt clean runAll command. Sometimes service started without any problem. But sometimes I found a message saying that
java.util.concurrent.TimeoutException: The first element has not yet passed through in 5000 milliseconds.
at akka.stream.impl.Timers$Initial$$anon$1.onTimer(Timers.scala:62)
at akka.stream.stage.TimerGraphStageLogic.onInternalTimer(GraphStage.scala:1601)
at akka.stream.stage.TimerGraphStageLogic.$anonfun$getTimerAsyncCallback$1(GraphStage.scala:1590)
at akka.stream.stage.TimerGraphStageLogic.$anonfun$getTimerAsyncCallback$1$adapted(GraphStage.scala:1590)
at akka.stream.impl.fusing.GraphInterpreter.runAsyncInput(GraphInterpreter.scala:466)
at akka.stream.impl.fusing.GraphInterpreterShell$AsyncInput.execute(ActorGraphInterpreter.scala:497)
at akka.stream.impl.fusing.GraphInterpreterShell.processEvent(ActorGraphInterpreter.scala:599)
at akka.stream.impl.fusing.ActorGraphInterpreter.akka$stream$impl$fusing$ActorGraphInterpreter$$processEvent(ActorGraphInterpreter.scala:768)
at akka.stream.impl.fusing.ActorGraphInterpreter$$anonfun$receive$1.applyOrElse(ActorGraphInterpreter.scala:783)
at akka.actor.Actor.aroundReceive(Actor.scala:534)
at akka.actor.Actor.aroundReceive$(Actor.scala:532)
at akka.stream.impl.fusing.ActorGraphInterpreter.aroundReceive(ActorGraphInterpreter.scala:690)
at akka.actor.ActorCell.receiveMessage(ActorCell.scala:573)
at akka.actor.ActorCell.invoke(ActorCell.scala:543)
at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:269)
at akka.dispatch.Mailbox.run(Mailbox.scala:230)
at akka.dispatch.Mailbox.exec(Mailbox.scala:242)
at java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(Unknown Source)
at java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
at java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
Can anyone please explain me the solution? Thanks in advance
I think that is one of the offset-timeouts, either for the read side or for the Kafka client.
If you are running everything on one machine and it is struggling, getting things running, setting up connections etc. could potentially take more time, so try tweaking those timeouts to higher values and see if it helps.
Related
I have been attempting to import a north-america-latest.osm.pbf (from Geofabrik) into a Postgres database for some time. After reviewing the wiki detailed usage page thoroughly, I set the database to include all necessary tables (pgSnapshot) via the included sql scripts. I also made sure that osmosis was functioning as intended by running a smaller file (Antarctica) through, and I got the results I expected. However, when I attempt to do the same process with the north america file, I get an error that is dissimilar to others that have been reported on the web. I am trying to get this data onto a server, uploads to my local seem to be fine.
Here's my code (via command prompt) :
C:\Users\eddie\Desktop>osmosis --read-pbf-fast north-america-latest.osm.pbf --log-progress interval=3000 --write-pgsql nodeLocationStoreType="TempFile" host=1*.8*.*.*0* database=osm postgresSchema=osm_updates user=eddie password=***
Here is the error message I get:
SEVERE: Thread for task 1-read-pbf-fast failed
org.springframework.dao.EmptyResultDataAccessException: Incorrect result
size: expected 1, actual 0
at org.springframework.dao.support.DataAccessUtils.requiredSingleResult(DataAccessUtils.java:71)
at org.springframework.jdbc.core.JdbcTemplate.queryForObject(JdbcTemplate.java:495)
at org.springframework.jdbc.core.JdbcTemplate.queryForObject(JdbcTemplate.java:500)
at org.openstreetmap.osmosis.pgsnapshot.common.SchemaVersionValidator.validateDBVersion(SchemaVersionValidator.java:64)
at org.openstreetmap.osmosis.pgsnapshot.common.SchemaVersionValidator.validateVersion(SchemaVersionValidator.java:47)
at org.openstreetmap.osmosis.pgsnapshot.v0_6.impl.CopyFilesetLoader.run(CopyFilesetLoader.java:77)
at org.openstreetmap.osmosis.pgsnapshot.v0_6.PostgreSqlCopyWriter.complete(PostgreSqlCopyWriter.java:117)
at org.openstreetmap.osmosis.core.progress.v0_6.EntityProgressLogger.complete(EntityProgressLogger.java:82)
at org.openstreetmap.osmosis.pbf2.v0_6.PbfReader.run(PbfReader.java:96)
at java.lang.Thread.run(Unknown Source)
Jul 19, 2018 8:28:24 AM org.openstreetmap.osmosis.core.Osmosis main
SEVERE: Execution aborted.
org.openstreetmap.osmosis.core.OsmosisRuntimeException: One or more tasks failed.
at org.openstreetmap.osmosis.core.pipeline.common.Pipeline.waitForCompletion(Pipeline.java:146)
at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:92)
at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
I am running osmosis .46, Postgres/PostGis 10/2.4 on Windows 10 with 12GB of RAM and 2 Intel 2.4GHz processors.
UPDATE: the error now occurs even when I run smaller files. Additionally, osmosis behaves as if it is processing a larger file (reaches node 4614331685 for Antarctica) as seen through the progress logger messages. An upload of OSM data for Canada to my local went through without any issues, so the problem probably has to do with the server I am trying to connect to. If anyone has any clues as to how to decipher the error message though, I'd like to hear them!
I got osmosis to work by taking #mmd 's advice of turning off the schema validation. Even though I ran the pgsnapshot scripts and had been successful putting data there before, something about doing all of north america seemed to throw it off. I'll update this answer after subsequent database updates.
I'm having Spring Batch job that is also dataflow task. When I run this job everything seems OK, In Tasks > Executions I can see that tasks finished successfully. On the other hand when I go to Jobs tabs I'm getting this error (in command line):
java.lang.NullPointerException: null
at org.springframework.cloud.dataflow.server.service.impl.DefaultTaskJobService.getTaskJobExecution(DefaultTaskJobService.java:240) ~[spring-cloud-dataflow-server-core-1.2.2.RELEASE.jar!/:1.2.2.RELEASE]
at org.springframework.cloud.dataflow.server.service.impl.DefaultTaskJobService.getTaskJobExecutionsForList(DefaultTaskJobService.java:233) ~[spring-cloud-dataflow-server-core-1.2.2.RELEASE.jar!/:1.2.2.RELEASE]
at org.springframework.cloud.dataflow.server.service.impl.DefaultTaskJobService.listJobExecutions(DefaultTaskJobService.java:103) ~[spring-cloud-dataflow-server-core-1.2.2.RELEASE.jar!/:1.2.2.RELEASE]
at org.springframework.cloud.dataflow.server.controller.JobExecutionController.list(JobExecutionController.java:91) ~[spring-cloud-dataflow-server-core-1.2.2.RELEASE.jar!/:1.2.2.RELEASE]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_112]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_112]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_112]
Spring Dataflow version = 1.2.2
I just ran into this issue a couple of days ago. The reason you get a null pointer exception is because when you ran your task, it's execution got inserted into the batch and task tables, except for the TASK_TASK_BATCH table. When you try to access the Jobs tab in DataFlow it reads from this table and cannot find the record so it throws the null pointer.
For me the root cause was because I removed the spring-boot-starter-parent from my spring boot application (since I needed to provide my own). In the process of doing so, I removed the spring-cloud-starter-task dependency, in exchange for the spring-cloud-task-core, thinking this was all I needed seeing as it compiled and the task ran just fine. What I eventually found out was that the spring-cloud-starter-task not only contains the spring-cloud-task-core, but also the spring-cloud-task-batch and the spring-cloud-task-stream. In my case, I was missing spring-cloud-task-batch which is what inserts the records into the TASK_TASK_BATCH table. So I simply removed the spring-cloud-task-core, and re-added spring-cloud-starter-task which solved the issue.
It's worth mentioning that one will also have to go and fix the data, by either manually adding those missing records to the TASK_TASK_BATCH table, or resetting your batch/task tables/sequences. Hope this helps!
Background: I have a web app that utilizes AngularJS, spring-mvc, and spring-rest for delivering the UI. I have a requirement to load balance using an Elastic LB and it is not using sticky sessions; requests are round robin. I implemented session replication using spring-session with gemfire for session storage. This works well.
I need to integrate with an OAuth2 auth server (and eventually multiple OAuth2 servers) purely for authentication and the passing of userInfo. I attempted to use the spring cloud oauth2 #EnableOAuth2Sso on the web-app and hit some session serialization issues. The mere addition of the oauth2ClientContext to the session seemed to cause ClassCastException problems during session saving.
I attempted to pull down the following samples and they worked well out of the box, Particularly the UI and the Authserver.
https://github.com/spring-guides/tut-spring-security-and-angular-js
However, when I added spring session into the mix, trying to serialize to a gemfire server, I encountered the exact same issue.
Here is the stacktrace highlight:
java.lang.ClassCastException: cannot assign instance of org.springframework.beans.factory.support.StaticListableBeanFactory to field org.springframework.aop.scope.DefaultScopedObject.beanFactory of type org.springframework.beans.factory.config.ConfigurableBeanFactory in instance of org.springframework.aop.scope.DefaultScopedObject
Below is abbreviated stacktrace:
ERROR o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception
org.springframework.dao.DataAccessResourceFailureException: remote server on machine(gemfire:21800:loner):57660:9d1f3438:gemfire: : While performing a remote put; nested exception is com.gemstone.gemfire.cache.client.ServerOperationException: remote server on machine(gemfire:21800:loner):57660:9d1f3438:gemfire: : While performing a remote put
at org.springframework.data.gemfire.GemfireCacheUtils.convertGemfireAccessException(GemfireCacheUtils.java:238) ~[spring-data-gemfire-1.7.4.RELEASE.jar:1.7.4.RELEASE]
at org.springframework.data.gemfire.GemfireAccessor.convertGemFireAccessException(GemfireAccessor.java:91) ~[spring-data-gemfire-1.7.4.RELEASE.jar:1.7.4.RELEASE]
at org.springframework.data.gemfire.GemfireTemplate.put(GemfireTemplate.java:190) ~[spring-data-gemfire-1.7.4.RELEASE.jar:1.7.4.RELEASE]
at org.springframework.session.data.gemfire.GemFireOperationsSessionRepository.save(GemFireOperationsSessionRepository.java:147) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.data.gemfire.GemFireOperationsSessionRepository.save(GemFireOperationsSessionRepository.java:35) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.commitSession(SessionRepositoryFilter.java:244) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.access$100(SessionRepositoryFilter.java:214) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.web.http.SessionRepositoryFilter.doFilterInternal(SessionRepositoryFilter.java:167) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.web.http.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:80) ~[spring-session-1.2.1.RELEASE.jar:na]
... tomcat filter chain and spring filter stuff
Caused by: com.gemstone.gemfire.cache.client.ServerOperationException: remote server on machine(gemfire:21800:loner):57660:9d1f3438:gemfire: : While performing a remote put
... gemfire internal stuff
at org.springframework.data.gemfire.GemfireTemplate.put(GemfireTemplate.java:187) ~[spring-data-gemfire-1.7.4.RELEASE.jar:1.7.4.RELEASE]
... 31 common frames omitted
Caused by: java.lang.ClassCastException: cannot assign instance of org.springframework.beans.factory.support.StaticListableBeanFactory to field org.springframework.aop.scope.DefaultScopedObject.beanFactory of type org.springframework.beans.factory.config.ConfigurableBeanFactory in instance of org.springframework.aop.scope.DefaultScopedObject
at java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2133) ~[na:1.7.0_80]
at java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1305) ~[na:1.7.0_80]
... java.io stuff
at org.springframework.aop.framework.AdvisedSupport.readObject(AdvisedSupport.java:557) ~[spring-aop-4.3.2.RELEASE.jar:4.3.2.RELEASE]
at sun.reflect.GeneratedMethodAccessor224.invoke(Unknown Source) ~[na:na]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_80]
at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.7.0_80]
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1058) ~[na:1.7.0_80]
... java.io stuff
at com.gemstone.gemfire.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2966) ~[gemfire-8.1.0.jar:na]
at com.gemstone.gemfire.DataSerializer.readObject(DataSerializer.java:3210) ~[gemfire-8.1.0.jar:na]
at org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSessionAttributes.readObject(AbstractGemFireOperationsSessionRepository.java:800) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSessionAttributes.fromDelta(AbstractGemFireOperationsSessionRepository.java:834) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.fromDelta(AbstractGemFireOperationsSessionRepository.java:589) ~[spring-session-1.2.1.RELEASE.jar:na]
at com.gemstone.gemfire.internal.cache.EntryEventImpl.processDeltaBytes(EntryEventImpl.java:1345) ~[gemfire-8.1.0.jar:na]
... gemfire internal stuff
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.7.0_80]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.7.0_80]
at com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:577) ~[gemfire-8.1.0.jar:na]
... 1 common frames omitted
I found the following, https://jira.spring.io/browse/SPR-14117, which encouraged me to update some of the jars to the newest versions, hoping the spring boot versions were simply behind, however it didn't seem to help.
Version info:
spring-cloud-starter-parent: Brixton.SR4
spring-cloud-security: 1.1.2.RELEASE
spring-core: 4.3.2.RELEASE
spring-security-oauth2: 2.0.10.RELEASE
spring-session: 1.2.1.RELEASE
I've considered a few options: rewiring the OAuth2 framework to no longer use ScopedProxyMode.INTERFACES (seems daunting), use Redis vs. Gemfire, write the entire client from scratch (I've done it before... wasn't fun).
FWIW I've already added the RequestContextFilter as recommended here: OAuth2ClientContext (spring-security-oauth2) not persisted in Redis when using spring-session and spring-cloud-security
Does anyone have any guidance?
I don't know if this speaks to your problem directly but I had/have a similar problem and I think I have all the same versions as you. Seems that there are so many Spring projects and they all try to keep up with each other so sometimes there seem to be compatibility issues. I found the steps outlined here by Rob Winch fixed my issue -https://github.com/spring-projects/spring-session/issues/395
I'm using JMeter with a load of 3-6 users. And I often get the exception below. Please, tell me what is the cause of this problem? Is this a trouble with JMeter or with server's application? thank you in advance.
Exception is next:
java.net.SocketException: Socket closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
at sun.security.ssl.AppInputStream.read(Unknown Source)
at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:90)
at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:281)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:92)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:61)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:481)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:298)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1105)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1094)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:429)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:257)
at java.lang.Thread.run(Unknown Source)
Okay i had this problem and the solution i tried and worked was to update Java version. From 1.8 to 1.12.
As it is a Jar (a Java program compiled) if you try to run it with a previous version of java it might result in this error.
This works for me:
Search "Update Java" on your computer menu and select it, after, on the Java Control Panel, select the option "Update". Now, select "Update Now". Wait for the installation and don't forget to select "Ok" to the end.
When Java is update, the POST works on JMeter. This is the same solution of AndiFB's answer.
Connection Reset since JMeter 2.10 ?
If you upgraded recently to JMeter 2.10 or 2.11, you may have noticed increased errors of this type:
Socket closed
Non HTTP response code: org.apache.http.NoHttpResponseException (the target server failed to respond)
Explanation
The increase of this type of errors can be explained by two settings changes:
retry of failing request (idempotent ones only) has been disabled in JMeter 2.10
stale check in HTTP Client 3 and 4 implementations has been disabled in JMeter 2.11
Why these changes?
Previous retry default settings led to increased number of Requests in certain type of failures.
Previous stale check was a bit expensive, as it applied to every sample. That is why the default was changed to disable it.
Retry or stale check can hide issues on Server configuration:
Server failing to send the (optional) Keep-Alive header
Overwhelmed server refusing connection, retrying would increase load
Changing configuration:
If you think this server behavior is OK, then configuration can be changed in two places:
Enabling retry
For HttpClient 4, in user.properties set :
httpclient4.retrycount=1
This will make JMeter retry once. For HttpClient 3, in user.properties set:
httpclient3.retrycount=1
This will make JMeter retry once.
Enabling stale check
For HC4 Implementation:
In user.properties:
hc.parameters.file=hc.parameters
In hc.parameters set:
http.connection.stalecheck$Boolean=true
For HC3 Implementation:
In user.properties:
httpclient.parameters.file=httpclient.parameters
In httpclient.parameters set:
http.connection.stalecheck$Boolean=true
New setting in JMeter 2.12
Upcoming version of JMeter adds a setting to add an idle connection timeout if the server does not send Keep-Alive headers.
This value is in milliseconds:
httpclient4.idletimeout=
I'm running a GWT app in a dev mode with a custom Jetty container. The app loads fine for the first time, however, if I refresh it, I get the following errors in the Development Mode window (paths changed):
00:16:44.854 [ERROR] Unable to create file 'C:\somePath\src\war\msjavaSnack\C4EA130FD0ED44BE513FEEDDE13614DA.cache.png'
java.io.FileNotFoundException: C:\somePath\src\war\msjavaSnack\C4EA130FD0ED44BE513FEEDDE13614DA.cache.png (The requested operation cannot be performed on a file with a user-mapped section open)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:194)
at java.io.FileOutputStream.<init>(FileOutputStream.java:145)
at com.google.gwt.core.ext.linker.impl.StandardLinkerContext.writeArtifactToFile(StandardLinkerContext.java:658)
at com.google.gwt.core.ext.linker.impl.StandardLinkerContext.produceOutputDirectory(StandardLinkerContext.java:595)
at com.google.gwt.dev.DevMode.produceOutput(DevMode.java:476)
at com.google.gwt.dev.DevModeBase.relink(DevModeBase.java:1131)
at com.google.gwt.dev.DevModeBase.access$000(DevModeBase.java:67)
at com.google.gwt.dev.DevModeBase$2.accept(DevModeBase.java:1076)
at com.google.gwt.dev.shell.ShellModuleSpaceHost$1.accept(ShellModuleSpaceHost.java:122)
at com.google.gwt.dev.shell.StandardRebindOracle$Rebinder.rebind(StandardRebindOracle.java:59)
at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:154)
at com.google.gwt.dev.shell.ShellModuleSpaceHost.rebind(ShellModuleSpaceHost.java:119)
at com.google.gwt.dev.shell.ModuleSpace.rebind(ModuleSpace.java:531)
at com.google.gwt.dev.shell.ModuleSpace.rebindAndCreate(ModuleSpace.java:414)
at com.google.gwt.dev.shell.GWTBridgeImpl.create(GWTBridgeImpl.java:39)
at com.google.gwt.core.client.GWT.create(GWT.java:98)
at com.extjs.gxt.ui.client.GXT.<clinit>(GXT.java:38)
at com.extjs.gxt.ui.client.widget.Component.<clinit>(Component.java:202)
at msjava.snack.gui.client.MSHeaderPanelViewport.<init>(MSHeaderPanelViewport.java:62)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.google.gwt.dev.shell.ModuleSpace.rebindAndCreate(ModuleSpace.java:422)
at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:361)
at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:185)
at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:380)
at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:222)
at java.lang.Thread.run(Thread.java:662)
UPDATE
In the ProcessExplorer I can see that the JVM process hosting Jetty has an open handle to the file so this is probably the reason why the other JVM (hosting the dev mode) can't write to it. Any way to work it around?
It seems that two (open/close) (open/close) rutines over the same file happening too soon one after another causes this... Some developers suggest to call the gc. Check for closing correctly every i/o operation. Not to perform complete (open,loop(writes),close) too soon. It seems that when one operation it is going to be finished while the second request arrives and that throws the problem.
I found the solution on this page:
http://docs.codehaus.org/display/JETTY/Files+locked+on+Windows
EDIT:
The above URL is dead now.
Now it's quite easy to find the solution in Jetty's wiki:
Jetty provides a configuration switch in the webdefault.xml file for
the DefaultServlet that enables or disables the use of memory-mapped
files. If you are running on Windows and are having file-locking
problems, you should set this switch to disable memory-mapped file
buffers.
The default webdefault.xml file is in the lib/jetty.jar at
org/eclipse/jetty/webapp/webdefault.xml. Extract it to a convenient
disk location and edit it to change useFileMappedBuffer to false.
https://wiki.eclipse.org/Jetty/Howto/Deal_with_Locked_Windows_Files